A continuación, se muestran los CVE en el orden en que aparecieron así como las nuevas vulnerabilidades y actualizaciones.
- CVE-2021-44228 [Crítico, 10.0]: la vulnerabilidad Log4Shell original es una falla de deserialización. Tiene un puntaje de 10 en la escala CVSS y otorga capacidades de ejecución remota de código (RCE) a atacantes no autenticados, lo que permite la toma de control completa del sistema.
Informado por Chen Zhaojun del equipo de seguridad en la nube de Alibaba a Apache el 24 de noviembre, CVE-2021-44228 afecta las configuraciones predeterminadas de múltiples marcos de Apache, incluidos Apache Struts2, Apache Solr, Apache Druid, Apache Flink y otros.
Siendo la más peligrosa de todas, esta vulnerabilidad se esconde en el componente log4j-core, limitado a las versiones 2.x: desde la 2.0-beta9 hasta la 2.14.1 inclusive. Se implementó una solución para Log4Shell en la versión 2.15.0, pero se consideró incompleta.
El analista de inteligencia de amenazas Florian Roth (aka @cyb3rops) compartió las reglas Sigma que pueden emplearse como una de las defensas en los SIEMs. - CVE-2021-45046 [Crítico, anteriormente bajo, 9.0]: Este es un defecto de Denegación de Servicio (DoS) con un puntaje de 3.7 9.0. La falla surgió como resultado de una solución incompleta que entró en 2.15.0 para CVE-2021-44228. Si bien la corrección aplicada a 2.15.0 resolvió en gran medida la falla, ese no fue el caso para ciertas configuraciones no predeterminadas.
Log4j 2.16.0 soluciona este problema eliminando la compatibilidad con los patrones de búsqueda de mensajes y desactivando la funcionalidad JNDI de forma predeterminada. Para aquellos en la rama 2.12.1, una corrección fue retro-portada a 2.12.2 (para Java 7). - CVE-2021-4104 [Alto, 8.1]: Aunque anteriormente se pensaba que Log4j 1.x era seguro, ya no es así. Esencialmente, la configuración no predeterminada de las instancias de Log4j 1.x que utilizan la clase JMSAppender también se vuelve susceptible a la falla de deserialización que no es de confianza. Debido a que estas son versiones al final de su vida útil, no existe una solución para la rama 1.x en ninguna parte, y se debe actualizar a Log4j-core 2.16.0 o superior. Aquí hay más información de mitigación en v1.x. Aunque no es fácil, el ataque no es imposible en v1.x y, si no se puede actualizar, tiene sentido protegerse eliminando JMSAppender por completo de log4j-1.2.17.jar, con el siguiente comando:
zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class - CVE-2021-42550 [Moderado, 6.6]: esta es una vulnerabilidad en el framework Logback, un sucesor de la biblioteca Log4j 1.x.
Hasta la semana pasada, Logback también se jactaba de que «al no estar relacionado con Log4j 2.x, Logback no comparte sus vulnerabilidades». Esa suposición se desvaneció rápidamente cuando se descubrió que CVE-2021-4104 también afectaba a Log4j 1.x, y se evaluó la posibilidad de un impacto potencial en Logback. Se han lanzado versiones más recientes de Logback v1.3.0-alpha11 y v1.2.9 que abordan esta vulnerabilidad menos grave. - CVE-2021-45105 [Alto, 7.5]: Se descubrió que Log4j 2.16.0 era vulnerable a una falla DoS calificada como Alta. Desde entonces, Apache ha lanzado una versión log4j 2.17.0 que corrige el CVE.
- ¿Un CVE más…? Sigue leyendo.
Desde que comenzó la crítica saga de día cero de Log4j la semana pasada, los expertos en seguridad han recomendado una y otra vez la versión 2.16.0 como la versión más segura. Eso cambia hoy con la versión 2.17.0 que corrige una vulnerabilidad de denegación de servicio (DoS) de gravedad aparentemente menor, pero ‘alta’ que afecta a Log4j 2.16.0. Y, sí, este error DoS viene con otro identificador: CVE-2021-45105.
La sospecha de un error DoS que afecta a Log4j 2.16.0 surgió en el proyecto JIRA de Apache hace unos tres días, poco después de que se descubriera que 2.15.0 era vulnerable a una vulnerabilidad DoS menor (CVE-2021-45046).
Sin embargo, Apache aumentó la gravedad de CVE-2021-45046 de Baja (3.7) a Crítica (9.0), después de que las omisiones más nuevas permitieran la posibilidad de exfiltración de datos a través de este exploit.
«Si se intenta una sustitución de cadena por cualquier motivo en la siguiente cadena, se activará una recursividad infinita y la aplicación se bloqueará», indica el problema de JIRA, con una carga útil de PoC:
${${::-${::-$${::-j}}}}Hace unas horas, investigadores de seguridad, incluidos vx-underground y Hacker Fantastic, tuitearon sobre una posible falla de Denegación de Servicio que también afecta a la versión 2.16 de Log4j. Resulta que, después de debatir el problema durante los últimos tres días, Apache asignó un nuevo CVE y lanzó una nueva versión.
Log4j 2.17.0 disponible hoy, corrige DoS
Registrado como CVE-2021-45105, y calificado como ‘Alto’ (7.5) en la escala CVSS, el defecto DoS existe ya que «Log4j 2.16 no siempre protege de la recursividad infinita en la evaluación de búsqueda».
Aunque las búsquedas JNDI estaban completamente deshabilitadas en la versión 2.16, las búsquedas autorreferenciales seguían siendo una posibilidad en determinadas circunstancias.
Para corregir la vulnerabilidad, Log4j versión 2.17.0 (para Java 8) se lanzó hoy y solo permite que las «cadenas de búsqueda en la configuración» se expandan de forma recursiva. En cualquier otro uso, solo se resolvería la búsqueda de nivel superior y no las búsquedas anidadas.
Aunque Apache ha publicado oficialmente detalles sobre la próxima versión 2.17.0 hasta ahora, las confirmaciones de GitHub indican que una versión 2.12.3 también podría estar en camino para aquellos en las versiones de rama 2.12.x.
Google: más de 35.000 paquetes de Java tienen defectos de Log4j
El desarrollo se produce casi al mismo tiempo que el análisis de Google que revela que más de 35.000 paquetes de Java contienen vulnerabilidades Log4j. «Más de 35.000 paquetes de Java, que representan más del 8% del repositorio de Maven Central (el repositorio de paquetes de Java más importante), se han visto afectados por las vulnerabilidades Log4j reveladas recientemente», explican James Wetter y Nicky Ringland del Open Source Insights Team de Google en entrada del blog.
Según Google, la gran mayoría de los paquetes Java vulnerables en Maven Central toman prestado Log4j «indirectamente», es decir, Log4j es una dependencia de una dependencia utilizada por el paquete, un concepto también conocido como dependencias transitivas.
De los 35.863 paquetes identificados por Google, solo alrededor de 7.000 tomaron prestado Log4j directamente, lo que indica que no todos los desarrolladores pueden tener una visibilidad adecuada de su software.
«La falta de visibilidad del usuario sobre sus dependencias y las dependencias transitivas ha dificultado la aplicación de parches; también ha dificultado la determinación del radio de alcance completo de esta vulnerabilidad», explica Google.
Al observar el historial de vulnerabilidades críticas reveladas públicamente que afectan a los paquetes de Maven, y el hecho de que menos del 48% de estos paquetes tenían una solución para estos, los investigadores de Google predicen «una larga espera, probablemente años» antes de que las fallas de Log4j se eliminen por completo de todo Java. paquetes.
Según lo informado por BleepingComputer, los actores de amenazas están apuntando a servidores vulnerables con exploits Log4j para impulsar el malware, y la banda de ransomware Conti observa específicamente los servidores VMWare vCenter vulnerables.
Como tal, las organizaciones deben actualizar a las últimas versiones de Log4j y continuar monitoreando los avisos de Apache en busca de actualizaciones.
Actualización 20/12
Regular Expression para detectar ataques Log4Shell en los logs:
- https://github.com/Neo23x0/log4shell-detector
- https://github.com/back2root/log4shell-rex
Más información sobre vulnerabilidades de Log4shell (CVE-2021-44228 / CVE-2021-45046 / CVE-2021-4104 / CVE-2021-45105)
Este repositorio contiene información sobre la vulnerabilidad de Log4shell en la biblioteca de registro de Log4j, especialmente CVE-2021-44228 / CVE-2021-45046 / CVE-2021-4104 / CVE-2021-45105:
- NCSC-NL advisory
- MITRE
- CSIRT network members advisories
NCSC-NL herramientas
| Directorio | Propósito |
|---|---|
| NCSC-NL herramientas | Todas las herramientas |
| Hunting | Contiene información sobre datos con fines de explotación |
| IOCs | Contiene indicadores de compromiso, hashing, IPs, etc. |
| Más IOCs | Más IOCs, Threat Reports, Threat Profiling, Threat Groups |
| Detection & Mitigation | Contiene datos sobre detección y mitigación, tales como regexes para detectar y realizar scanning |
| Scanning | Contiene referencias, métodos y herramientas usadas para realizar scanning de la vulnerabilidad Log4Shell |
| Software | Contiene una lista de productos vulnerables y no vulnerables |
| Tools | Contiene una lista de herramientas que automáticamente busca productos vulnerables |
