Mitigación de Log4J-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

Por favor, mantén un ojo en esta página ya que el equipo de Apache Log4j está divulgando muchos más CVEs y solucionando problemas de seguridad muy rápidamente.

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:

jndiarch

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

 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.

Versiones afectadas: todas las versiones de log4j-core >=2.0-beta9 y <=2.14.1 Apache Log4j <=2.14.1 Las características JNDI utilizadas en la configuración, mensajes de registro y parámetros no protegen contra endpoints LDAP y otros relacionados con JNDI controlados por el atacante. Un atacante que pueda controlar los mensajes de registro o los parámetros de los mensajes de registro puede ejecutar código arbitrario cargado desde servidores LDAP cuando la sustitución de búsqueda de mensajes (message lookup substitution) está habilitada. A partir de log4j 2.15.0, este comportamiento está deshabilitado por defecto.

En versiones >=2.10**, este comportamiento se puede mitigar estableciendo la propiedad del sistema log4j2.formatMsgNoLookups o la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS a true. Para versiones >=2.7 y <=2.14.1, todos los patrones de PatternLayout se pueden modificar para especificar el convertidor de mensajes como %m{nolookups} en lugar de solo %m.

Para versiones >=2.0-beta9 y <=2.10.0, la mitigación es eliminar la clase JndiLookup del classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

2. Corrección en pom.xml:

Actualice la dependencia en pom.xml y cámbiela por la versión más reciente disponible en la sección de dependencias: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom

<dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.14.1</version>
<!-- Cambie por lo siguiente para demostrar que está corregido -->            
<!--         <version>2.17.0</version>-->
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.14.1</version>
<!-- Cambie por lo siguiente para demostrar que está corregido -->       
<!--         <version>2.17.0</version>-->
        </dependency>
    </dependencies>

Referencia: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18

3. Azure App Service (Windows y Linux):

Si es posible, los clientes deben actualizar Log4j a la versión v2.15.0 y volver a implementar las aplicaciones. Esta es la mitigación principal recomendada. Si no puede volver a implementar su aplicación, en las versiones de Log4j 2.10 y superiores, puede mitigar este comportamiento estableciendo la propiedad del sistema “-Dlog4j2.formatMsgNoLookups=true”. En App Service, puede establecer esta propiedad creando una configuración de aplicación (app setting) llamada JAVA_OPTS con un valor de “-Dlog4j2.formatMsgNoLookups=true”. La configuración de aplicación JAVA_OPTS se pasa a su aplicación Java al iniciarse. Si ya tiene la configuración de aplicación JAVA_OPTS establecida, simplemente agregue “-Dlog4j2.formatMsgNoLookups=true” al valor existente. Si está utilizando Log4J versión 2.9 o inferior, esta mitigación de propiedad del sistema no funcionará y debe actualizar a v2.15.0.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"

4. Cualquier aplicación containerizada

Para aplicaciones containerizadas, si la versión de Log4j 2 que está utilizando es 2.10.0 o posterior, hay una variable de entorno o una opción de línea de comandos de Java que puede usar para deshabilitar el comportamiento de sustitución inseguro. Puede agregar la línea:
```
 ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
```
Referencia de Dockerfile: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
A su Dockerfile, o puede agregar el indicador equivalente "-Dlog4j.formatMsgNoLookups=true" al comando que ejecuta en su contenedor, por ejemplo:
```
 CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
```
También puede configurar la variable de entorno en tiempo de ejecución, lo que puede ser más fácil, por ejemplo, para Kubernetes podría agregar estas líneas en su configuración.
```
 spec:
   containers:
   - name: ...
     image: ...
     env:
     - name: LOG4J_FORMAT_MSG_NO_LOOKUPS
       value: "true"
```

5. Azure Functions:

Configurar la propiedad del sistema dependerá de su elección de opción de hospedaje: dedicada, premium o consumo. Como recordatorio, la mitigación principal recomendada es actualizar Log4J a 2.15.0 y volver a implementar su aplicación. Si no puede hacer eso por cualquier motivo, entonces puede aplicar la propiedad del sistema.

- Funciones Dedicadas y Premium:

Cree una configuración de aplicación (app setting) llamada JAVA_OPTS con un valor de “-Dlog4j2.formatMsgNoLookups=true”. Si ya tiene la configuración de aplicación JAVA_OPTS establecida, simplemente agregue “-Dlog4j2.formatMsgNoLookups=true” al valor existente.

- Funciones de Consumo:

Linux: Cree una configuración de aplicación llamada “languageWorkers__java__arguments” con un valor de “-Dlog4j2.formatMsgNoLookups=true”. Windows: Cree una configuración de aplicación llamada “languageWorkers:java:arguments” con un valor de “-Dlog4j2.formatMsgNoLookups=true”. **Tenga en cuenta que actualizar la configuración de aplicación reiniciará sus aplicaciones Web y de Functions, lo que podría afectar el rendimiento de arranque en frío. Si está utilizando Log4J versión 2.9 o inferior, esta mitigación de propiedad del sistema no funcionará y debe actualizar a v2.15.0.

6. Hotpatch para Apache Log4j

¿Cómo funciona? Esta herramienta inyecta un agente Java en un proceso JVM en ejecución. El agente intenta parchear el método lookup() de todas las instancias cargadas de org.apache.logging.log4j.core.lookup.JndiLookup para que devuelvan incondicionalmente la cadena “Patched JndiLookup::lookup()”. Esto está diseñado para abordar la vulnerabilidad de ejecución remota de código CVE-2021-44228 en Log4j sin reiniciar el proceso Java.

Si tiene la posibilidad de volver a implementar sus procesos Java, también puede usarlo como un agente estático, lo que significa que puede incluir este parche en su tiempo de ejecución sin iniciar sesión directamente en sus servidores.

Github : https://github.com/corretto/hotpatch-for-apache-log4j2

7. Cómo Defender for Cloud encuentra máquinas afectadas por vulnerabilidades de Log4j

Usando el inventario, tiene dos formas poderosas de determinar su exposición:

Inventario de software

Hallazgos de evaluación de vulnerabilidades

https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/how-defender-for-cloud-finds-machines-affected-by-log4j/ba-p/3037271

8. Detección en Azure Sentinel y registros de WAF:

Azure WAF Log4j CVE-2021-44228 hunting

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/WAF_log4j_vulnerability.yaml

Azure WAF matching para Log4j vuln(CVE-2021-44228)

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AzureDiagnostics/AzureWAFmatching_log4j_vuln.yaml

9. Configuración del plug-in de Maven para prohibir versiones vulnerables de log4j2 en compilaciones futuras:

Configuración del plug-in de Maven para poner en su POM padre para evitar cualquier uso de versiones obsoletas de log4j2, algunas de las cuales están sujetas a la RCE CVE-2021-44228

("Log4Shell"), CVE-2021-45046 y CVE-2021-45105).

Referencia: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d

 <!-- Configuración del plug-in para poner en su POM padre para evitar cualquier uso de
     versiones obsoletas de log4j2, algunas de las cuales están sujetas a la RCE CVE-2021-44228
     ("Log4Shell"), CVE-2021-45046 y CVE-2021-45105. Asegúrese de verificar la
     última versión de log4j2 en
     https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>ban-bad-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
...

Contribuciones:

Me encantaría recibir contribuciones de la comunidad. Pautas para contribuciones:

-->Por favor, haga un PR.

-->Por favor, asegúrese de incluir una fuente de referencia para más contexto.

Puede haber varios entornos diferentes y otras formas de solucionarlo, siéntase libre de abrir un pull request:

Referencias:

https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

https://github.com/justincormack/log4jpoc

https://www.rumble.run/blog/finding-log4j/

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay