7.4 KiB
| layout | slug | status | sitemap | title | description | categories | tags | |
|---|---|---|---|---|---|---|---|---|
| post | h5ai-cve-postmortem | draft | false | Faille dans h5ai, mon postmortem | Et maintenant l'attaque à l'indonésienne. |
|
J'ai eu la "chance" de pouvoir vivre pleinement une intrusion sur mon serveur causée par une faille de sécurité. Histoire de mettre à profit cet heureux moment, je vous propose un retour sur mon investigation suite à cette intrusion.
Les failles de sécurité viennent toujours de là ou on s'y attend le moins. Dans mon cas, le responsale est h5ai, un petit logiciel qui permet d'avoir un index apache/nginx plus joli. Rien de bien méchant, sauf que, rien n'est jamais simple...
Découverte de la faille
J'ai découvert l'intrusion dans les règles de l'art : en me rendant sur l'index habituellement géré par h5ai. Et surprise, surprise quand j'aperçois cette page en lieu et place de mon index :
Je me connecte donc rapidement en SSH sur mon serveur, pour voir l'étendu des dégats. Nous sommes alors le vendredi 9 octobre. Les fichiers sont là depuis 24 septembre, soit 15 jours. Mazette, ça fait un bout de temps que personne n'est venu ici. Je désactive PHP (sudo service php5-fpm stop), m'empresse de regarder les logs nginx, de copier tout les fichiers incriminés dans un dossier ailleurs et de mettre à jour h5ai.
Voilà les fichiers et dossiers que j'ai identifié comme malicieux :
drwxr-xr-x 2 www-data www-data 4,0K sept. 24 04:31 dm
drwxr-xr-x 2 www-data www-data 80K sept. 24 04:31 DM
-rw-r--r-- 1 www-data www-data 2,1K sept. 24 04:53 index.html
-rw-r--r-- 1 www-data www-data 105K sept. 24 04:54 pro_mailer.php
-rw-r--r-- 1 www-data www-data 122K sept. 24 04:31 we.php
Dans dm et DM se trouvent des liens symboliques cassés. Il serait intéressant d'étudier le fonctionnement de we.php pour comprendre leur utilité. index.html est la page de revendication, we.php est une interface web (non protégée) pour controler le serveur, et pro_mailer.php est utilisé pour envoyer facilement du spam.
Informations sur la CVE
La faille de sécurité a été identifiée sous le nom CVE-2015-3203 le 28 septembre 2015. Soit 4 jours après mon attaque. C'est un peu comme un Early Access sur Steam, mais en plus c'est gratuit...
Par la même occasion on en apprend plus sur la faille de sécurité :
Unrestricted file upload vulnerability in h5ai before 0.25.0 allows remote attackers to execute arbitrary code by uploading a file with an executable extension, then accessing it via a direct request to the file in the directory specified by the href parameter.
TL;DR : Sur certaines versions de h5ai il est possible d'envoyer des fichiers sur le serveur sans restriction. Fichiers qui seront ensuite interprétés par PHP.
Une faille basique, complètement bête. A aucun moment la fonction d'envoie est mentionnée sur h5ai.
Après cet épisode, on peut trouver un message bien discret sur le site de h5ai :
There was a securtiy flaw in versions 0.22.0 - 0.24.1 that was fixed in 0.25.0. If you are still using one of this versions you are advised to upgrade.
Pour ceux qui seraient intéressé par l'exploit, vous pouvez en trouver un sur Exploit-DB. (Bien évidemment il est a utiliser uniquement pour tester votre installation...)
Le fichier we.php
Le fichier we.php contient une interface, permettant de prendre le contrôle du serveur, et de nombreux outils. On citera, entre autres, la possibilité de naviguer dans les fichiers du serveur, d'executer des commandes, d'automatiser l'ajout d'un compte dans un Wordpress ou un Joomla, etc.
On notera que le code n'est pas directement en clair dans le fichier, il est compressé en gzip puis converti en base 64. L'ensemble est ensuite décodé puis passé dans un eval qui va interpréter le code.
On remarquera que la "team" qui a réalisé ce logiciel est indonésienne et se nomme "D'MASTERPIECE".
Le fichier pro_mailer.php
Le fichier pro_mailer.php quant à lui n'est pas obfusqué. Il est d'ailleurs écrit dans un PHP plus propre (en utilisant des classes). On remarquera le soin apporté au design...
Son seul objectif est d'utiliser le serveur email de la cible pour envoyer des emails.
Retour sur l'attaque
Afin d'accéder au serveur, nos pirates revendiquant le nom de "Dragon Net" ont exploité la faille de sécurité dans h5ai pour envoyé trois fichiers : index.html (leur revendication), we.php et pro_mailer.php.
Ils ont ensuite utilisé we.php pour fouiller dans les fichiers du site et uploadé différents fichiers, entre autre un .ssh/known_hosts (mais c'est tout côté SSH).
Ils se targuent de se contenter de publier leurs revendications. Et en effet, ils semblent n'avoir rien fait d'autre. Cependant, on peut supposer que leur intentions ne sont pas aussi louables qu'ils le prétendent : pourquoi ne pas avoir directement envoyé leur fichier index.html ? we.php et pro_mailer.php sont inutiles dans notre cas...
On notera d'ailleurs que la team ayant réalisé l'attaque n'est pas la même que celle qui a créé le fichier we.php ou encore pro_mailer.php. Il y a un marché pour tout...
Faute d'informations supplémentaires je suppose qu'ils ont prévu ces fichiers "au cas où" ils aient besoin d'un serveur.
Exploitation et possibilités
La faille de h5ai, par chance, n'a été exploitée que pour des revendications politiques/religieuses. Mais on peut imaginer bien pire...
Tout d'abord, actuellement tous mes sites web en PHP sur cette machine utilisent le même utilisateur. On peut donc supposer qu'il aurait pu défacer ces sites webs, et la base de données qui va avec. Il était aussi possible de lancer des attaques DDoS depuis la machine, executer des programmes, etc.
Cependant, notre pirate n'avait pas d'accès root, il n'avait donc pas accès au reste du système... heureusement !
Les mesures de sécurité
Cet épisode amène à des réflexions. Tout d'abord sur le choix de h5ai : comment une telle faille est arrivée dans ce logiciel. Son objectif n'a jamais été l'envoi de données ! Peut-on encore lui faire confiance ? Peu d'annonce à ce sujet, une description laconique sur le site officiel, pas grand chose sur git...
Deuxièmement, je me suis intéressé aux mises à jours des différents applications web de ma machine. Quelles sont les applications installées ? Sont-elles à jour ?
Enfin, le problème de PHP se pose : comment compartimenter les sites en plusieurs utilisateurs distincts afin qu'un site compromis ne puisse pas atteindre les autres ? Comment prévenir l'execution de scripts PHP indésirable ? SELinux n'aurait pas forcément été d'une grande aide dans mon cas, même s'il peut être un rempart de plus, pour détecter ce genre d'actions frauduleuses.
Aujourd'hui les containers sont à la mode (LXC, Docker, ...). L'utilisation de ces derniers pourraient être un gage de sécurité supplémentaire. En effet, le pirate resterait coincé dans le conteneur. De plus ces derniers sont censés être plus simple à mettre à jour. Mais leur sécurité n'est pas encore parfaite.
En tout cas, en terme de sécurité, il ne faut pas se reposer sur un rempart, car une faille de sécurité peut facilement le casser, mais sur plusieurs (container, utilisateurs distincts, SELinux et mises à jour fréquentes).