dungsocool/cve-2018-7600Guide de laboratoire pas à pas pour l'exploitation de CVE-2018-7600 (Drupalgeddon2) RCE dans Drupal 8.5.0, couvrant l'analyse de la surface d'attaque, l'identification de version, et l'exploitation via Form API injection.
Commencez par lister les conteneurs en cours d'exécution :
docker ps
D'après les résultats de docker ps, le conteneur pour ce Lab est :
p1/lab09:latest
Ce conteneur expose le port :
0.0.0.0:8011->80/tcp
Cela indique que le service à l'intérieur du conteneur écoute sur le port 80/tcp, et est mappé sur le port 8011 de l'hôte.
Le port 80/tcp est le port standard pour HTTP. Par conséquent, ce laboratoire cible est très probablement une application web HTTP. Pour confirmer le service web, j'envoie une requête HTTP en utilisant curl combiné avec l'accès à l'interface graphique de la page web.
curl -i http://192.168.3.137:8011/
Évaluation de la surface d'attaque
À partir de la réponse HTTP et de l'interface web, les informations suivantes ont été identifiées :
Web server: Apache/2.4.25 (Debian) Backend: PHP/7.2.3 CMS: Drupal Drupal version: 8.5.0 Install path: /core/install.php Public port: 8011 -> 80/tcp
Ces informations constituent des empreintes cruciales pour corréler avec les CVE. Plus précisément, Drupal 8.5.0 est la version directement liée à CVE-2018-7600, également connue sous le nom de Drupalgeddon2.
Selon l'avis officiel de Drupal, SA-CORE-2018-002 / CVE-2018-7600 affecte les versions suivantes :
>= 8.5.0 < 8.5.1
La cible actuelle exécute :
Drupal 8.5.0
se situant donc dans la plage de versions affectées.
⇒ Réflexion :
À ce stade, la version Drupal 8.5.0 est une preuve solide pour identifier la CVE suspectée. Je raisonne comme suit :
docker ps montre que le Lab expose le service HTTP via le port 8011.curl -i retourne une réponse HTTP valide depuis Apache/PHP./core/install.php.Drupal >=8.5.0 <8.5.1 est affecté par CVE-2018-7600.Drupal 8.5.0, ce qui la rend éligible selon les critères de version pour tester CVE-2018-7600.La cible est Drupal 8.5.0 fonctionnant sur Apache/PHP. Cette version se situe dans la plage affectée par CVE-2018-7600 selon l'avis officiel de Drupal. La prochaine étape consiste à vérifier les conditions d'exploitation réelles pour confirmer si la cible peut être soumise à une RCE.
À partir de l'étape précédente de prise d'empreintes, la cible affiche clairement : Drupal 8.5.0. Selon l'avis officiel de Drupal, la vulnérabilité SA-CORE-2018-002 / CVE-2018-7600 affecte les versions du noyau Drupal :
>= 8.5.0 < 8.5.1. La cible actuelle exécute exactement Drupal 8.5.0, la plaçant dans la plage de versions affectées. Selon l'avis Drupal, il s'agit d'une vulnérabilité d'exécution de code à distance dans le noyau Drupal, qui pourrait permettre à un attaquant d'exploiter plusieurs vecteurs d'attaque et de compromettre l'ensemble du site.
Cependant, vous pouvez voir que la cible redirige vers /core/install.php et l'interface graphique affiche l'écran d'installation de Drupal. Cela suggère que Drupal pourrait être dans un état d'installation incomplet. Si la configuration du site n'a pas été terminée, les points de terminaison courants utilisés pour déclencher Drupalgeddon2 comme /user/register, /user/password et /user/login pourraient ne pas fonctionner correctement. Par conséquent, il est nécessaire de vérifier ces points de terminaison.
curl -i http://192.168.3.137:8011/user/register curl -i http://192.168.3.137:8011/user/password curl -i http://192.168.3.137:8011/user/login
On peut voir que les points de terminaison sont toujours redirigés vers /core/install.php
Conclusion :
La cible exécute Drupal 8.5.0, se situant dans la plage de versions affectées par CVE-2018-7600 selon l'avis officiel de Drupal. Cependant, au moment du test, l'application est dans un état d'installation et redirige en continu les routes telles que /user/register, /user/password et /user/login vers /core/install.php.
Cela montre que les points de terminaison couramment utilisés pour vérifier Drupalgeddon2 ne fonctionnent pas encore comme ils le feraient sur un site Drupal entièrement installé. Par conséquent, la cible ne satisfait actuellement que la condition de version mais ne remplit pas encore les conditions d'exécution pour démontrer une exécution de code à distance.
=> Réflexion :
Nous devons prouver davantage que Drupal dans son état d'exécution peut traiter les routes/formulaires vulnérables, qu'un attaquant peut accéder aux points de terminaison sans authentification, et que des charges utiles de vérification comme id peuvent s'exécuter avec succès.
Sur la cible actuelle, les points de terminaison redirigent vers l'installateur, donc la prochaine étape est d'évaluer si l'écran d'installation de Drupal crée sa propre surface d'attaque, au lieu de conclure immédiatement à une RCE Drupalgeddon2.
Après avoir vérifié que les points de terminaison d'exécution de Drupal comme /user/register, /user/password et /user/login sont tous redirigés vers /core/install.php, j'ai procédé à l'analyse de l'écran d'installation.
Vérification du service de base de données supportant l'installateur
Étant donné que l'installateur Drupal est actuellement arrêté à l'étape de configuration de la base de données, j'ai vérifié si des services de base de données courants sont exposés extérieurement :
nmap -sV -p 3306,5432,33060 192.168.3.137
La cible expose actuellement l'installateur Drupal extérieurement, mais aucun service de base de données accessible directement depuis la machine de l'attaquant n'a été détecté.
Conclusion : Le laboratoire expose l'installateur Drupal 8.5.0 et présente une divulgation d'informations concernant la version vulnérable. CVE-2018-7600 est un vecteur suspecté valide, mais une exploitation réussie n'a pas encore été prouvée.
CVE-2018-7600 exploite une vulnérabilité dans l'API Form de Drupal - le système de rendu de formulaires qui utilise la structure Render Array. Lors du traitement d'une requête AJAX, Drupal utilise le paramètre element_parents pour localiser des éléments dans l'arborescence du formulaire sans vérifier (assainir) les clés commençant par le caractère #. Les attaquants injectent des propriétés comme #post_render, #markup et #type via des données POST pour forcer le moteur de rendu à exécuter des fonctions PHP arbitraires (par exemple, exec, passthru, system).
Condition préalable : Au moins un point de terminaison utilisant l'API Form doit retourner une réponse valide (non redirigée, non bloquée par le contrôle d'accès) afin que l'attaquant puisse envoyer une requête AJAX contenant la charge utile.