
Log4J CVE-2021-44228 : Hoja de referencia de mitigación
Actualización - 28-Dic-2021
CVE-2021-44832: Apache Log4j2 vulnerable a RCE a través de JDBC Appender cuando el atacante controla la configuración.
Solucionado en Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) y 2.3.2 (Java 6)
Actualización - 17-Dic-2021
Durante la noche, fue divulgado por Apache que la versión de Log4j 2.16 también es vulnerable mediante un ataque de Denegación de Servicio cuyo impacto es un bloqueo completo de la aplicación, la gravedad se clasifica como Alta (7.5). Se ha emitido CVE-2021-45105, y Apache ha publicado una nueva versión corregida (2.17), se recomienda actualizar.
Antecedentes:
El debate en Internet estaba alborotado por una vulnerabilidad de día cero (que puede producir ejecución remota de código) en la popular biblioteca de registro Log4J de Apache para Java. Esta vulnerabilidad en particular—rastreada como CVE-2021-44228 con la puntuación máxima “crítica” de CVSS de 10—reside en la capacidad de búsqueda (lookup) de Log4J, combinada con JNDI (Java Naming and Directory Interface). Este problema es generalizado porque muchos desarrolladores desconocían que Log4J era peligroso de usar con entrada sin filtrar.
El impacto más significativo es que un atacante puede hacer que una cadena llegue al registrador (logger), la cual, al ser procesada por Log4J, ejecuta código arbitrario. Los primeros ejemplos de esto utilizaron la ruta ${jndi:ldap}, lo que podría conducir a la carga de código arbitrario desde una URL remota. Esta ruta está parcialmente mitigada por el uso de nuevas versiones de Java que bloquean el cargador de clases basado en URL por defecto. Desafortunadamente, una versión moderna de Java puede no ser suficiente para prevenir la explotación, ya que la propia aplicación puede exponer clases que pueden ser utilizadas para ejecutar código arbitrario.
La arquitectura JNDI:

Mitigaciones para diferentes entornos:
Actualización - 17-Dic-2021
Vulnerabilidad de seguridad CVE-2021-45105
Detalles:
Apache Log4j2 versiones 2.0-alpha1 hasta 2.16.0 no protegían contra la recursión no controlada proveniente de búsquedas auto-referenciales. Cuando la configuración de registro utiliza un Pattern Layout no predeterminado con una búsqueda de contexto (por ejemplo, $${ctx:loginId}), los atacantes con control sobre los datos de entrada del Thread Context Map (MDC) pueden crear datos de entrada maliciosos que contengan una búsqueda recursiva, lo que resulta en un StackOverflowError que terminará el proceso. Esto también se conoce como un ataque DOS (Denegación de Servicio).
Mitigación:
A partir de la versión 2.17.0 (para Java 8), solo las cadenas de búsqueda en la configuración se expanden recursivamente; en cualquier otro uso, solo se resuelve la búsqueda de nivel superior, y las búsquedas anidadas no se resuelven.
En versiones anteriores, este problema se puede mitigar asegurando que su configuración de registro haga lo siguiente:
En PatternLayout en la configuración de registro, reemplace las búsquedas de contexto como ${ctx:loginId} o $${ctx:loginId} con patrones de Thread Context Map (%X, %mdc o %MDC).
De lo contrario, en la configuración, elimine las referencias a búsquedas de contexto como ${ctx:loginId} o $${ctx:loginId} donde se originen de fuentes externas a la aplicación, como encabezados HTTP o entrada de usuario.
Actualización - 13-Dic-2021
Log4j (Versión 2.16.0 – 2021-12-13) tiene dos características mejoradas:
---------------¡¡Altamente recomendado actualizar a la versión más reciente disponible ya que las búsquedas de mensajes están deshabilitadas por defecto!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
Deshabilitar JNDI por defecto. Se requiere establecer log4j2.enableJndi a true para permitir JNDI.
Eliminar completamente el soporte para Message Lookups
Nueva actualización:
------------------CVE-2021-45046-----------------
Apache Log4j2 Thread Context Message Pattern y Context Lookup Pattern vulnerables a un ataque de denegación de servicio.
Mitigación:
Mitigación para Log4j 1.x: Log4j 1.x no se ve afectado por esta vulnerabilidad.
Mitigación para Log4j 2.x: Implemente una de las técnicas de mitigación a continuación.
Los usuarios de Java 8 (o posterior) deben actualizar a la versión 2.16.0. Los usuarios que requieran Java 7 deben actualizar a la versión 2.12.2 cuando esté disponible (trabajo en progreso, se espera que esté disponible pronto).
De lo contrario, elimine la clase JndiLookup del classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Tenga en cuenta que solo el archivo JAR log4j-core se ve afectado por esta vulnerabilidad. Las aplicaciones que usan solo el archivo JAR log4j-api sin el archivo JAR log4j-core no se ven afectadas por esta vulnerabilidad.
------------------CVE-2021-44228-------------------
Mitigación
Mitigación para Log4j 1.x: Log4j 1.x no tiene Lookups, por lo que el riesgo es menor. Las aplicaciones que usan Log4j 1.x solo son vulnerables a este ataque cuando usan JNDI en su configuración. Se ha presentado un CVE separado (CVE-2021-4104) para esta vulnerabilidad. Para mitigar: audite su configuración de registro para asegurarse de que no tenga ningún JMSAppender configurado.
Las configuraciones de Log4j 1.x sin JMSAppender no se ven afectadas por esta vulnerabilidad.
Mitigación para Log4j 2.x: Implemente una de las técnicas de mitigación a continuación.
Los usuarios de Java 8 (o posterior) deben actualizar a la versión 2.16.0.
Los usuarios que requieran Java 7 deben actualizar a la versión 2.12.2 cuando esté disponible (trabajo en progreso, se espera que esté disponible pronto).
De lo contrario, elimine la clase JndiLookup del classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Tenga en cuenta que solo el archivo JAR log4j-core se ve afectado por esta vulnerabilidad. Las aplicaciones que usan solo el archivo JAR log4j-api sin el archivo JAR log4j-core no se ven afectadas por esta vulnerabilidad.
1. Apache Log4j:
En versiones >=2.10** y
Para versiones >=2.0-beta9 y <=2.10.0
2. Corrección en pom.xml:
3. Azure App Service (Windows y Linux):
4. Cualquier aplicación containerizada:
5. Azure Functions:
6. Hotpatch para Apache Log4j
7. Cómo Defender for Cloud encuentra máquinas afectadas por vulnerabilidades de Log4j
8. Detección en Azure Sentinel y registros de Azure WAF
9. Configuración del plug-in de Maven para prohibir versiones vulnerables de log4j2 en compilaciones futuras
1. Apache Log4j:
CVE-2021-44228: Las características JNDI de Apache Log4j2 no protegen contra endpoints LDAP y otros relacionados con JNDI controlados por el atacante.