Detectar y mitigar la vulnerabilidad Log4Shell que afecta a la librería de Java Log4j (CVE-2021-44228)

El pasado 9 de diciembre fue divulgada una vulnerabilidad crítica que afecta a la librería Log4j, que es muy utilizada en el mundo Java. Esta vulnerabilidad fue registrada como CVE-2021-44228 y catalogada como crítica ya que permite ejecución de código remoto (RCE) [1]. Las versiones afectadas van desde 2.0-beta-9 hasta 2.14.1. En la versión 2.15.0 ya está corregida.

Actualización importante (14/12/2021): La versión 2.15.0, publicada inicialmente para corregir este problema, no lo hace completamente por lo que se registró una nueva vulnerabilidad (CVE-2021-45046) que afecta a esta versión específica [6]. Por este motivo no alcanza con actualizar a la versión 2.15.0 sino que hay pasar a la 2.16.0.

Actualización importante (18/12/2021): La versión 2.16.0 tampoco corrige el problema en forma completa ya que permite a un atacante causar una denegación de servicio. Se generó una nueva vulnerabilidad (CVE-2021-45105) que afecta a esta versión específica [8]. Por este motivo no alcanza con actualizar a la versión 2.15.0 ó 2.16.0 sino que hay pasar a la 2.17.0.

Actualización importante (28/12/2021): La versión 2.17.0 tampoco corrige el problema en forma completa ya que permite ejecución de código remoto (RCE). Se generó una nueva vulnerabilidad (CVE-2021-44832) que afecta a esta versión específica [9]. Por este motivo no alcanza con actualizar a la versión 2.15.0, 2.16.0 o 2.17.0 sino que hay pasar a la 2.17.1, la cual sí corrige completamente los problemas detectados en las versiones anteriores.

Métodos de detección:

Una manera de detectar si hay alguna aplicación web vulnerable es buscar la librería log4j-core en el servidor o contenedor donde se ejecuta la aplicación. Esto se puede hacer en una plataforma GNU/Linux con los comandos find o locate. En el siguiente ejemplo se puede ver que hay cuatro aplicaciones alojadas en un servidor Tomcat que incluyen la librería log4j-core-2.13.3.jar (que es vulnerable).

Otra manera de verificar si una aplicación es afectada por esta vulnerabilidad es utilizar la siguiente aplicación web [2]: https://log4shell.huntress.com/ 

Esta herramienta genera un identificador único que puede ser utilizado como payload en los distintos campos de la aplicación (por ejemplo los campos de texto que pueden ser introducidos por el usuario, o incluso también modificando las cabeceras HTTP como User-Agent o X-Forwarded-For). Si la aplicación es vulnerable, se registra un intento de conexión en la sección de resultados de la aplicación web.

Adicionalmente, en caso de tener una aplicación que utiliza una versión vulnerable de Log4j, conviene verificar los archivos de registros para detectar intentos de explotación de la vulnerabilidad. Una herramienta útil para esto es el script log4shell-detector [5], la cual se encarga de buscar en forma recursiva (dentro de un directorio especificado) cualquier registro que contenga una cadena compatible con un intento de explotación. En el siguiente ejemplo se puede apreciar que dentro del directorio /logs de un servidor Tomcat hay registros compatibles con intentos de explotación de la vulnerabilidad:

Otro recurso interesante es el listado de aplicaciones vulnerables constantemente actualizado por el Nationaal Cyber Security Centrum [7]. En este listado se recopila una gran cantidad de aplicaciones con su respectivo estado en relación a log4j (vulnerable, no vulnerable, corregida, en investigación, etc). Se puede consultar ese listado para analizar si alguna aplicación vulnerable está en uso en su organización y si hay alguna medida de mitigación asociada.

Medidas de mitigación: [3] [4]

1. Actualizar la librería Log4j a la versión 2.17.1 o posterior. Las versiones 2.15.0, 2.16.0 y 2.17.0 también tienen importantes vulnerabilidades asociadas [6] [8] [9].
   
   
2. Si no es posible actualizar a la versión 2.17.1 pero se está utilizando la versión 2.10 o superior, definir la siguiente propiedad para desactivar la funcionalidad vulnerable:
   

    log4j2.formatMsgNoLookups=true

   
   
3. Otra opción posible si se está utilizando la versión 2.10 o superior es definir la siguiente variable de entorno para desactivar la funcionalidad vulnerable:
   

    LOG4J_FORMAT_MSG_NO_LOOKUPS=true

   Los administradores de Kubernetes pueden utilizar el comando kubectl set env para definir la variable de entorno mencionada en todos los clusters donde la aplicación vulnerable esté en ejecución. De esta forma el cambio impactará automáticamente en todos los pods automáticamente. 
   
   
4. Otra alternativa que funciona para todas las versiones vulnerables es directamente eliminar la clase JndiLookup del archivo log4j-core con el siguiente comando:

    # zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

   
   En el siguiente ejemplo se puede ver como hacer esto para una de las aplicaciones vulnerables visualizadas en la captura de pantalla anterior:
   
   
   
   Cualquiera sea la medida seleccionada para mitigar la vulnerabilidad, no hay que olvidarse de reiniciar los servicios involucrados luego de modificar las configuraciones y de realizar las pruebas correspondientes para verificar que los cambios surtieron el efecto deseado.

Esperamos que esta info les haya sido útil. Hasta la próxima!

Referencias:
[1] https://nvd.nist.gov/vuln/detail/CVE-2021-44228
[2] https://log4shell.huntress.com/
[3] https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
[4] https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

[5] https://github.com/Neo23x0/log4shell-detector

[6] https://nvd.nist.gov/vuln/detail/CVE-2021-45046

[7] https://github.com/NCSC-NL/log4shell/tree/main/software

[8] https://nvd.nist.gov/vuln/detail/CVE-2021-45105

[9] https://nvd.nist.gov/vuln/detail/CVE-2021-44832