Variante d’exploitation d’un Apache Tomcat : host manager app vulnérable ?
Dans le cadre d’une mission d’audit interne, j’ai été amené à exploiter un Apache Tomcat sur un Windows. Habituellement l’exploitation d’un Tomcat passe par l’accès au « manager » et l’exploitation est très simple (compte admin/admin).
Dans le cas qui nous intéresse, le manager n’était pas accessible (code HTTP 403) mais le host-manager l’était.
Contexte :
Cible -> serveur Windows 2012R2 (192.168.56.31)
Attaquant -> serveur linux Ubuntu 16.04 (192.168.56.1)
Version Apache Tomcat -> dernière release 8.5.37
Reconnaissance de reconnaissance
Un classique scan avec l’outil Nmap sur l’hôte qui nous intéresse permet de constater un Tomcat installé sur le port 8080.
Ce genre de cible est idéale lors d’un audit car Tomcat est exécuté en règle générale avec les droits « nt authority\system » sur Windows et donc permet d’avoir le contrôle total du serveur et ainsi obtenir des mots de passe et des hash qui permettront par la suite d’élever nos privilèges sur le système d’information.
Authentification
Lors de la découverte d’un Tomcat le 1er réflexe en tant qu’auditeur est de tenter de s’authentifier sur le manager. Généralement on tente un admin/admin ou un tomcat/tomcat.
Dans le cadre de l’audit, j’ai tenté directement les identifiants « tomcat/tomcat » et j’ai pu constater que l’accès au manager m’était refusé (code HTTP 403). J’ai alors tenté d’accéder au /host-manager ( host manager app ) de la même manière, et la boom « code HTTP 200 ».
Plusieurs techniques sont possibles pour automatiser la phase de bruteforce :
Module Metasploit : auxiliary/scanner/http/tomcat_mgr_login
Hydra
Nikto (intègre un test avec les identifiants « tomcat/tomcat »)
Différents scripts dédiés à Tomcat
Exploitation du « host-manager »
Ok on a accès au host manager app mais qu’est-ce qu’on fait maintenant ?
L’application n’a pas de formulaire d’upload et a priori en lisant la documentation, il faut contrôler et connaitre le chemin de l’application à déployer ainsi qu’un vhost valide.
L’exploitation est née à ce moment précis, j’ai eu l’idée de tenter de mettre un chemin UNC vers un serveur SMB (smbserver.py de impacket) que je contrôlais :
Tomcat se connecte bien à mon partage :
Donc le server Apache Tomcat interprète le chemin UNC et cherche à installer une application depuis le répertoire « datatest ». On va donc créer un répertoire et ajouter un fichier War dans lequel nous mettrons une backdoor qui permettra de prendre le contrôle à distance du serveur.
1- Créer un war
La création d’un WAR est très simple, c’est un fichier ZIP qu’on renomme avec l’extension .war. A l’intérieur on va mettre un fichier JSP qui permet d’exécuter des commandes système depuis le navigateur.
On peut créer nous même un fichier ZIP avec notre backdoor et le renommer en .war :
Pour les scripts kiddies, on peut créer un fichier War avec msfvenom et ainsi exécuter « meterpreter » directement :
2- Deploy and pwn
Pour accéder au fichier war et le déployer à distance, on va utiliser le smbserver.py fourni par le package « impacket » pour partager le dossier suivant :
Le déploiement se fait à distance et les fichiers sont bien stockés sur notre pc. Pour accéder à notre backdoor, Tomcat se base sur l’alias. Il peut donc être nécessaire d’ajouter l’IP du serveur dans le fichier /etc/hosts avec le vhost qu’on a utilisé pour le déploiement.
Configuration de l’application avant déploiement :
Déploiement réussi :
Connexion de Tomcat sur mon serveur Samba lors du déploiement :
Un petit tour dans le navigateur confirme que notre backdoor est bien déployée et que nous pouvons exécuter des commandes sur le serveur Windows.
Contenu du répertoire de l’application sur mon PC une fois déployée :
Cette technique d’exploitation d’un tomcat par le host-manager a été testée sur les versions Tomcat <=7.0.92 et <=8.5.37 hébergée sur un serveur Windows.
Article rédigé par le pôle audit de Certilience