Méthodologie d’un test intrusion d’un serveur web en pratique. Partie 3 – La recherche et exploitation de vulnérabilités : Intrusion via Drupal
Petit rappel : si vous désirez faire réaliser un audit, vous trouverez toutes les informations sur mon site : https://resistez-aux-hackeurs.com
Passons maintenant à l’exploitation d’un CMS Drupal vulnérable.
L’url d’accès à Drupal est http://<ip_du_serveur>/drupal (détecté par nessus)
En général, la surface d’attaque d’un CMS est concentrée sur 4 aspects :
- Les vulnérabilités liées au noyau du CMS
- Les vulnérabilités liées aux modules utilisés
- Les vulnérabilités liées aux utilisateurs (mots de passe faible, attaques par social engineering, etc.)
- Les faiblesses de configuration du serveur web (Apache, Nginx)
Nous allons tout d’abord exploiter une vulnérabilité liée au noyau Drupal.
Exploitation d’une vulnérabilité dans le noyau Drupal
Dans le cas de l’audit d’un CMS Drupal, même méthodologie que précédemment (scan de ports, test page web, etc.). Différents moyens permettent de déterminer quelle est la technologie utilisée par le site, avec par exemple l’outil whatweb[1].
Pour auditer Drupal, nous allons utiliser l’outil CMSmap[2], qui permet d’auditer les CMS de type WordPress, Joomla et Drupal :
Lors du scan, une vulnérabilité de type injection SQL a été détectée[3]. Cette injection SQL touche l’interface d’authentification Drupal et est accessible sans compte. Celle-ci a été surnommée le « Drupageddon », car de très nombreux sites web fonctionnant sous Drupal ont été pénétrés suite à la diffusion de cette vulnérabilité.
Pour plus d’information sur cette vulnérabilité, vous pouvez consulter le lien suivant : https://www.secpod.com/blog/drupalgeddon-2/
Les champs vulnérables sont ceux qui permettent à un utilisateur de rentrer son identifiant et son mot de passe :
De nombreux scripts (dont un sous metasploit -> exploit/multi/http/drupal_drupageddon) exploitent cette vulnérabilité. Un exemple de script python pour l’exploitation de cette vulnérabilité est disponible ici[4].
Il est intéressant d’analyser les requêtes envoyées par le script. Deux commandes sont envoyées par le script au serveur vulnérable :
curl --data "name[0;insert%20into%20users%20values%20(99999,'admin','%24S%24DIkdNZqdxqh7Tmufxs8l1vAu0wdzxF%2F%2FsmWKAcjCv45KWjK0YFBg','pwnd@pwnd.pwn','','',NULL,0,0,0,1,NULL,'',0,'',NULL);#%20%20]=test&name[0]=test&pass=test&form_id=user_login_block&op=Log+in" --header "Content-Type:application/x-www-form-urlencoded" http://192.168.56.101/drupal/?destination=node
La première requête créée un utilisateur, tandis que la seconde ajoute celui-ci au groupe administrateur.
Metasploit utilise le même principe mais permet d’uploader et d’exécuter un shell sur le serveur (en activant le module php-filter) :
Un très bon article sur les différentes façons qu’ont eu les attaquants d’exploiter cette vulnérabilité est disponible ici[6].
Exploitation d’une vulnérabilité dans un module Drupal
Il est par exemple tout à fait possible d’avoir un CMS parfaitement à jour mais d’utiliser un module vulnérable. Hors certains scanneurs de vulnérabilités se contentent uniquement de tester la version du CMS sans tester celles des modules.
Lors du scan de vulnérabilités avec l’outil cmsmap, celui-ci nous a bien détecté les vulnérabilités liées à la version de Drupal utilisée, mais n’a pas détecté les vulnérabilités liées aux composants utilisés :
Par contre, Nessus nous a détecté une vulnérabilité liée à des composants de Drupal utilisé mais pas celles liées à la version de Drupal (j’insiste : les outils sont complémentaires !)
La vulnérabilité détectée est liée au module Restful web services :
Plus d’informations sur cette vulnérabilité sont disponibles ici : https://www.drupal.org/forum/newsletters/security-advisories-for-contributed-projects/2016-07-13/restws-highly-critical
Il existe un module metasploit associé à cette vulnérabilité : exploit/unix/webapp/drupal_restws_exec qui permet d’obtenir un accès au serveur.
L’exploitation de cette vulnérabilité permet d’obtenir un accès au serveur.
Recommandations :
– mettre à jour le CMS ET les modules utilisés
– utiliser un logiciel de type WAF (par exemple modsecurity) pour détecter et bloquer les requêtes web malveillantes
– utiliser le module mod_evasive d’Apache pour empêcher les accès répétés au serveur web (et ainsi bloquer les scanneurs de vulnérabilités qui réalisent un nombre élevé de requêtes)
Les vulnérabilités exploitées nous ont permis d’obtenir un premier accès au serveur. Nous verrons au prochain chapitre comment continuer l’audit du serveur. Il nous reste encore 2 services à auditer : tomcat et ssh.
[1] https://www.morningstarsecurity.com/research/whatweb
[2] https://github.com/Dionach/CMSmap
[3] https://www.drupal.org/SA-CORE-2014-005
[4] https://www.exploit-db.com/exploits/34992/
[6] http://mattkorostoff.com/article/I-survived-drupalgeddon-how-hackers-took-over-my-site
Visits: 244