Segmentation fault

Exploitation de faille include avec les sessions PHP

16 septembre 2009 – 21:05

Il y a quelques jours, je suis tombé sur un challenge de hack PHP. J’arrive sur une page avec une URL du type www.site.com/index.php?page=main.php,  qui ressemble étrangement à la célèbre faille include. En effet, quelques tests le démontrent. Autre part sur le site, on trouve une page protégée par un .htaccess. Pour le bypasser, on utilise naturellement cette faille include (ou bien cette autre méthode). Mais ce n’est pas tout. Outre le fait qu’on ne puisse pas inclure de page distante (directive allow_url_include activée), l’administrateur n’a pas du tout protégé cette faille include. On peut donc inclure tous les fichiers locaux accessibles…

Il était une fois une include non protégée…

Je me lance donc dans l’exploration de l’arborescence en récupérant quelques fichiers intéressants. Commepar exemple /proc/version, qui indique que le serveur tourne sous une Ubuntu basée sur un kernel 2.6.25. Je regarde également une partie de la configuration Apache dans /etc/apache2/apache2.conf, la liste des utilisateurs dans /etc/passwd. /etc/shadow est bien évidemment non accessible car Apache n’est pas lancé par le root. Mais sachant qu’un exploit touchant les Linux non patchés a récemment été publié,  je me dis qu’il doit certainement être possible de rooter le serveur à partir de là. Si j’arrive à exécuter des commandes sur le serveur avec les droits d’Apache, devenir root ne devrait pas être dur en utilisant cet exploit…

Je cherche donc un moyen d’utiliser la faille include pour pouvoir exécuter du code. Je pense en particulier à l’injection de commandes dans les logs Apache. Seul problème : ils ne sont lisibles que par le root, donc pas par Apache (il suffit de tester pour s’en rendre compte rapidement). Où vais-je donc pouvoir injecter mes commandes… ? Quels sont les fichiers manipulés par Apache et PHP dans lesquels on peut écrire indirectement et lire ensuite ? Sur le coup, je sèche…

…un site utilisant les sessions…

Là, Heurs et Virtualabs me donnent la réponse : les sessions PHP. En effet, PHP stocke les variables de session dans des fichiers (elles sont sérialisées) qui se situent dans /var/lib/php5/. Leur nom suit le format sess_$PHPSESSID où $PHPSESSID est l’identifiant de session qui est envoyé dans le cookie, donc facilement récupérable. Et, coup de chance, il se trouve que le challenge en question utilise les sessions pour stocker l’utilisateur courant et son mot de passe. Champs qui ne sont sont bien pas vérifiés lors de la soumission du formulaire

C’est parti ! Je crée un compte bidon avec quelque chose comme <?php system($_GET['c']); ?> pour le login. Je soumet, récupère le cookie contenant l’identifiant de session, et inclus le fichier de session correspondant. Et là, j’obtiens une jolie backdoor PHP sur le serveur. Rudimentaire, certes, mais fonctionnelle ! A partir de là, j’en conçois une légèrement plus élaborée, que je place sur un de mes serveurs, et que je fais télécharger au serveur victime avec un wget (suivi d’un mv). Je peux maintenant exécuter des commandes PHP à volonté, lire des fichiers sources, etc. Je récupère une autre backdoor permettant d’obtenir un remote shell sur ma machine. J’ouvre un port avec Netcat sur ma machine, j’upload et lance la backdoor, et le tour est joué.

… et un kernel non patché.

Je peux maintenant exécuter des commandes de façon interactive, mais toujours avec les droits d’Apache. Je télécharge un des exploits sock_sendpage de Milw0rm, le compile sur le serveur (gcc y était installé, cool), je lance l’exécutable généré, et bing ! Root sur le serveur . Comme mon but n’est pas de planter le serveur, je m’arrête ici. Enfin je prends quand même soin de supprimer toute trace de l’intrusion dans les logs. Et je garde un petit screenshot, pour envoyer au propriétaire du site, l’histoire de le prévenir. Bien entendu, pour envoyer le mail j’ai pris soin de créer un mail anonyme et de passer par un proxy, au cas où le propriétaire serait furax et menacerait de porter plainte… Heureusement, celui-ci est sympa ; il me répond rapidement et me remercie de l’avoir prévenu. Et vous savez le comble de l’histoire ? Ce serveur ne lui appartenait pas, il ne disposait pas lui-même des droits root

Conclusion

Je crois que cette histoire (vraie, pour ceux qui douteraient) illustre plutôt bien et de façon concrète la marche à suivre employée par un attaquant afin de prendre la main sur un serveur : exploitation d’une faille distante pour récupérer des informations, exécution de commandes dans le contexte du processus vulnérable, élévation de privilèges en utilisant un local root, et nettoyage des logs. De plus, cet exemple démontre que ce n’est pas parce que l’on a interdit l’inclusion de fichiers distant que l’on a un appel à include() sécurisé.

J’insiste enfin sur le fait que ce que j’ai réalisé ici était à la portée d’un script kiddie pour peu qu’il connaisse la faille, sache utiliser une backdoor PHP et compiler un exploit. Administrateurs de challenges de hack PHP, méfiez-vous : reproduire des applications vulnérables c’est bien, mais pensez à vous protéger un minimum pour éviter le pire…