Jerry
Windows Easy sin escalada: un Apache Tomcat 7 con el panel Manager publicado y las credenciales de fábrica (tomcat/s3cret) permite desplegar una shell en .war, y como el servicio corre como SYSTEM se entra ya con el máximo privilegio.
Jerry
| Máquina | SO | Dificultad | IP |
|---|---|---|---|
| Jerry | Windows | Easy | 10.129.136.9 |
A tener en cuenta...
Resumen
Jerry es la máquina más corta que he hecho, y lo es por un motivo muy concreto: no hay escalada de privilegios. Ninguna. Se entra y ya se es SYSTEM.
Todo gira alrededor de un Apache Tomcat con el panel de administración abierto y las credenciales que trae de fábrica. Desde ese panel, Tomcat ofrece justo lo que necesito — desplegar una aplicación — así que subo una shell empaquetada como .war, la visito y tengo terminal.
El único momento en que la máquina se pone algo juguetona es al final, con las flags. Y no es una protección: es una broma del autor.
Vulnerabilidad
No hay ningún CVE. Son tres decisiones de configuración que, juntas, convierten un servidor de aplicaciones en una puerta abierta.
01 · Credenciales por defecto en el Tomcat Manager
El panel /manager/html conserva un usuario de los que vienen de ejemplo en la documentación de Tomcat: tomcat con contraseña s3cret. Están en todos los diccionarios desde hace años, así que no es ni fuerza bruta: es probar la primera entrada de la lista.
02 · El Manager permite desplegar aplicaciones
Esto no es un fallo de Tomcat, es su función. El panel existe para subir y arrancar aplicaciones .war, y un .war es código Java que el servidor ejecuta. Dicho de otro modo: quien entra al Manager tiene ejecución remota de código por diseño. Por eso ese panel no debería estar expuesto jamás.
03 · El servicio corre como SYSTEM
El golpe final. Tomcat está instalado como servicio de Windows bajo NT AUTHORITY\SYSTEM en lugar de con una cuenta de servicio limitada. Como el código desplegado hereda el usuario del proceso, la shell nace ya con el máximo privilegio del sistema. Ahí se acaba la máquina.
Reconocimiento
Barrido completo de puertos contra la víctima, con detección de sistema operativo
| Puerto | Servicio |
| 8080 | http-proxy |
Un único puerto abierto, el 8080, y los otros 65.534 filtrados — no cerrados. Eso delata un cortafuegos descartando el tráfico en silencio, lo que de paso explica que el escaneo tarde casi dos minutos.
La huella del sistema apunta a Windows Server 2012 R2, aunque nmap avisa de que la estimación es poco fiable: sin un puerto cerrado con el que comparar, el fingerprinting va a ciegas.
Enumeración
Con un solo puerto, todo el peso cae sobre él
Apache Tomcat 7.0.88. El 8080 es su puerto de siempre y el título de la página lo confirma sin disimulo. Lo corroboro con whatweb
Con Tomcat identificado, lo que interesa no es buscar un exploit de la versión sino ver qué hay publicado del propio servidor
Ahí está lo importante. Los 401 no son un portazo: son una invitación. Significan que /manager/html existe y pide credenciales, en vez de devolver un 404 como haría si estuviese desactivado.
Que el panel de administración de Tomcat esté publicado ya es medio camino. Falta entrar.
Explotación
Antes de pensar en diccionarios grandes, lo sensato con Tomcat es probar sus credenciales de fábrica — vienen comentadas en la documentación y mucha instalación se queda con ellas. Metasploit trae las listas ya preparadas
Dos combinaciones válidas en cuatro segundos, 260 intentos en total. Llamar a esto fuerza bruta es generoso: la contraseña estaba publicada en el manual.
Con tomcat / s3cret entro al Manager, y ahí está la sección que convierte el acceso en ejecución
Un .war (Web Application Archive) es el formato con el que se empaqueta una aplicación Java: un ZIP con el código compilado y su configuración. Tomcat lo descomprime y lo publica en una ruta. Si ese código es una shell, el servidor la ejecuta por mí.
Genero la mía con msfvenom, directamente en formato war
La subo desde el propio panel y pulso Desplegar
Antes de dispararla, el listener preparado
Tomcat ya la ha publicado: aparece /shell en la lista de aplicaciones desplegadas, arrancada y lista
El nombre de la ruta sale del nombre del fichero — shell.war se publica en /shell. Solo hay que visitarla para que el código se ejecute
http://jerry:8080/shell/
La página se queda en blanco, que es exactamente lo que se espera: no hay nada que mostrar, el trabajo está pasando al otro lado
El 6.3.9600 confirma el Windows Server 2012 R2 que nmap había aventurado. Y entonces llega la sorpresa
NT AUTHORITY\SYSTEM de entrada. No hay escalada de privilegios en esta máquina porque no hace falta: el servicio de Tomcat se instaló con la cuenta más privilegiada del sistema, y la shell hereda ese contexto.
Flags
Las dos banderas están juntas, en una carpeta del escritorio del administrador
Y aquí está la única pega de la máquina, que es más una broma del autor que un obstáculo: hay un solo fichero con las dos flags dentro, y su nombre lleva espacios. Un type a secas falla, porque el intérprete parte el nombre por los espacios y busca un fichero llamado 2.
Se resuelve entrecomillando el nombre
Cómo se arregla
Nada que parchear: todo se arregla con configuración, y cualquiera de las tres medidas por separado ya habría frenado el ataque.
- Cambiar las credenciales por defecto: tomcat/s3cret y admin/admin llevan años en todos los diccionarios. Las cuentas de ejemplo de tomcat-users.xml se borran, no se reutilizan.
- No publicar el Manager: el panel no debería ser accesible desde la red. Restringirlo a localhost con RemoteAddrValve, o directamente quitar las aplicaciones manager y host-manager de un servidor en producción.
- Ejecutar Tomcat con una cuenta sin privilegios: este es el que más daño evita. Con una cuenta de servicio limitada, la misma intrusión habría acabado en una shell sin permisos, y habría hecho falta una escalada de verdad para llegar a SYSTEM.
- Quitar lo que viene de ejemplo: /docs y /examples no pintan nada en producción y regalan la versión exacta del servidor.
- Filtrar el tráfico saliente: la reverse shell necesita salir de la máquina hacia el atacante. El cortafuegos ya filtraba bien la entrada; haciendo lo propio con la salida, la conexión no se habría establecido.
Conclusiones
Máquina de nivel muy principiante, y lo digo sin que suene a reproche: para un primer contacto es ideal. No hay explotación rara, ni versiones que investigar, ni nada que compilar. Se identifica el servicio, se prueban sus credenciales de fábrica, se usa una función legítima del panel y se acabó.
El único truco está al final, con las flags metidas en un fichero cuyo nombre lleva espacios, y se resuelve con unas comillas. Es un guiño, no una dificultad.
Lo que sí deja es una lección que vale para máquinas mucho más serias: el privilegio con el que corre un servicio importa tanto como la vulnerabilidad que lo compromete. Aquí el fallo no fue entrar al panel — fue que Tomcat estuviera corriendo como SYSTEM. Con una cuenta limitada esta máquina tendría media hora más de trabajo por delante.