tadash10/exploiting-cve-2021-44228-log4shell-in-a-banking-environmentObjetivo: Demostrar la explotación de la vulnerabilidad Log4Shell (CVE-2021-44228) dentro de un entorno simulado de aplicación bancaria.
Objetivo: Demostrar la explotación de la vulnerabilidad Log4Shell (CVE-2021-44228) dentro de un entorno simulado de aplicación bancaria.
Alcance:
1: Configurar una aplicación bancaria vulnerable usando Apache Log4j. 2:Crear un payload para explotar la vulnerabilidad, logrando ejecución remota de código. 3:Demostrar técnicas de post-explotación, como la exfiltración de datos y el movimiento lateral. 4:Implementar y documentar estrategias de detección y mitigación, incluyendo parcheo y monitoreo de red. 5:Recorrido detallado del proceso de explotación, incluyendo las herramientas utilizadas (p. ej., JNDI Exploit Kit, Burp Suite).
vamos a sumergirnos en la creación de un payload para explotar la vulnerabilidad Log4Shell (CVE-2021-44228) y lograr la ejecución remota de código dentro del escenario ficticio de ejercicio en la VM.
Para crear el payload, necesitamos entender la naturaleza de la vulnerabilidad. La vulnerabilidad Log4Shell permite a los atacantes inyectar código malicioso en el archivo de configuración de la librería Log4j, que luego es ejecutado por la aplicación afectada. El payload estará diseñado para activar esta vulnerabilidad y ejecutar código arbitrario en el sistema objetivo.
A continuación, se muestra un esquema básico de los pasos para crear el payload:
Identificar el archivo de configuración de Log4j: Determina la ubicación del archivo de configuración de Log4j dentro del entorno de la aplicación bancaria objetivo. Normalmente, este archivo se llama log4j2.xml o log4j.properties.
Crear el payload de explotación: Crea una configuración maliciosa de Log4j que incluya una búsqueda de Java Naming and Directory Interface (JNDI) para ejecutar código arbitrario. Este payload se puede incrustar dentro del archivo log4j2.xml.
xml
Reemplaza "your-attacker-server" con la dirección IP o el nombre de host de tu máquina atacante escuchando en el puerto 4444.
Alojar el payload: Configura un listener en tu máquina atacante para recibir la conexión y ejecutar el código arbitrario.
Declaración XML:
xml
Declaración XML estándar.
Elemento Configuration:
xml
El elemento raíz para la configuración de Log4j.
Appenders:
xml
Define un appender Socket llamado "evil".
El atributo host especifica el servidor del atacante.
El atributo port especifica el puerto en el servidor del atacante.
SerializedLayout indica que los eventos de registro se serializarán y se enviarán por la red, lo que puede ser un riesgo de seguridad ya que podría permitir la ejecución remota de código (RCE) mediante ataques de deserialización.
Loggers:
xml
<Loggers>
<Root level="all">
<AppenderRef ref="evil" />
</Root>
</Loggers>
Define el nivel de registro como all, lo que significa que todos los mensajes de registro (debug, info, warn, error, etc.) serán capturados.
El AppenderRef hace referencia al appender "evil" definido anteriormente, lo que significa que todos los mensajes de registro se enviarán al servidor del atacante.
Comentarios
Riesgos de seguridad:
Ejecución remota de código (RCE): Usar un SerializedLayout con un appender Socket remoto puede permitir a un atacante ejecutar código arbitrario en el sistema si controla el servidor y envía un payload malicioso. Esta es una vulnerabilidad de seguridad crítica.
Exfiltración de datos: Esta configuración puede llevar fácilmente a que datos sensibles se envíen a un servidor remoto no autorizado, lo que provoca fugas de datos.
Prácticas de registro inadecuadas:
Registrar en un servidor remoto no confiable es altamente inseguro y va contra las mejores prácticas para el registro seguro.
Registrar en el nivel all en un entorno de producción puede llevar a inundación de registros, problemas de rendimiento y posible exposición de información sensible.
Recomendaciones de mitigación:
Evita los layouts serializados: No uses SerializedLayout en ninguna configuración de registro a menos que sea absolutamente necesario y asegúrate de que el servidor receptor sea confiable y seguro.
Valida los endpoints de registro: Asegúrate de que todos los endpoints de registro estén dentro de entornos confiables y controlados.
Usa layouts seguros: Utiliza layouts más seguros como PatternLayout que no representan riesgos de serialización.
Restringe los niveles de registro: Usa niveles de registro apropiados (p. ej., info, warn, error) y evita usar all salvo para fines de depuración específicos en un entorno seguro.
Ejemplo de una configuración más segura
A continuación, un ejemplo de una configuración Log4j más segura:
xml
nc -nlvp 4444
Activar la vulnerabilidad: Implementa el archivo de configuración Log4j creado dentro del entorno objetivo, reemplazando el archivo de configuración original.
Ejecución del exploit: Una vez que la configuración maliciosa es cargada por la instancia vulnerable de Log4j, intentará establecer una conexión con el servidor del atacante, lo que lleva a la ejecución remota de código.
Verificar la ejecución: Revisa el listener en tu máquina atacante para confirmar que el payload se ha ejecutado con éxito.
Es crucial señalar que este payload es con fines educativos y de prueba dentro de un entorno controlado. En escenarios del mundo real, explotar vulnerabilidades como Log4Shell sin autorización es ilegal y poco ético. Asegúrate siempre de tener permiso y autorización explícitos antes de realizar cualquier actividad de pruebas de seguridad o pruebas de penetración.