A un año de Log4Sheel

En diciembre del año pasado, la vulnerabilidad Log4Shell (CVE-2021-44228) en la biblioteca Apache Log4j causó sensación. Y, aunque en primavera ya había desaparecido de los titulares de los medios TI, en noviembre del 2022 reapareció cuando se descubrió que los cibercriminales habían explotado esta vulnerabilidad para atacar una agencia federal de Estados Unidos e instalar un minero de criptomonedas en sus sistemas. Consideramos por tanto que es una buena oportunidad para explicar qué es realmente Log4Shell, por qué es demasiado pronto para darla por muerta y cómo proteger tu infraestructura.

¿Qué es la biblioteca Apache Log4j?

Dado que Java SDK no admitía de primeras la escritura de mensajes de registro, los desarrolladores tuvieron que escribir sus propias soluciones, por lo que cuando el Java Logging API oficial apareció, ya se habían desarrollado algunas de estas soluciones. Una de ellas es Apache Log4j, una famosa biblioteca de Java de código abierto en desarrollo desde el 2001. No es la única solución de escritura de mensajes de registro, pero sin duda sí que es una de las más populares, de hecho, muchas de las soluciones de este tipo son básicamente filiales de Log4j que han aparecido en diferentes etapas del desarrollo de la biblioteca.

¿Qué es la vulnerabilidad Log4Shell?

La biblioteca Log4j permite registrar todos los eventos del sistema de forma automática. Utiliza un conjunto estándar de interfaces para acceder a los datos de la Interfaz de Nombrado y Directorio Java (JNDI, por sus siglas en inglés). En noviembre del 2021, resultó que durante el registro era capaz de ejecutar comandos JNDI pasados por un evento, por ejemplo, en el campo de Encabezado de una solicitud, en un chat o en la descripción de un error 404 de una página web.

La vulnerabilidad permite a los cibercriminales, al menos en teoría, hacer lo que quieran en el sistema de la víctima (a no ser que entren en juego las medidas de seguridad). En la práctica, la mayoría de los atacantes utilizaban Log4Shell para instalar mineros ilegales y desplegar ataques de ransomware. Pero ha habido otros usos más exóticos también, incluidos los ataques dirigidos, el botnet Mirai e incluso la referencias al famoso meme de internet, RickRolling, reproduciendo el (irritante, aunque adictivo) éxito de los 80 “Never Gonna Give You Up” del cantante Rick Astley.

¿Por qué es tan peligroso y sigue siendo una amenaza?

Java es uno de los lenguajes de programación más importantes, usado por muchos sistemas de backend, desde servidores de pequeñas corporaciones hasta sistemas de automatización industriales y dispositivos del IdC. La mayoría de estos sistemas implementan los registros de una forma u otra y durante años la forma más sencilla de hacerlo ha sido con la biblioteca Log4j. Por ello, cuando se informó en diciembre del 2021 que contenía una vulnerabilidad, los expertos manifestaron la magnitud de un problema que permanecería durante años. Te contamos el por qué:

• Dado que Log4j se utiliza en una gran variedad de aplicaciones Java, cuando se dio a conocer la vulnerabilidad, ya estaba en más de 35000 paquetes en Maven Central (el repositorio de paquetes Java más importante), lo que representa el 8 % de la cifra total. De acuerdo con los expertos, aproximadamente el 40 % de las redes de todo el mundo estaban en riesgo de infección con Log4Shell.
• Además de los ordenadores y servidores convencionales, Java también se utiliza en equipos industriales, médicos y demás sectores especializados. Y estos equipos también utilizan la biblioteca Log4j.
• Si los usuarios finales de soluciones que utilizan Log4j desconocen que el software contiene una vulnerabilidad, pueden postergar su actualización.
• Los desarrolladores de soluciones que utilizan la biblioteca Log4j podrían haber quebrado hace tiempo, abandonado el mercado o cancelado el soporte de sus programas. Por ello, aunque los usuarios hubieran querido actualizar el programa, podrían encontrarse con alguna de estas situaciones que lo impiden y cambiar a otro software no es nada fácil.
• Log4j es una biblioteca de código abierto, lo que quiere decir que los programadores pueden copiarla, modificarla y utilizarla en sus proyectos. Y, por desgracia, no todos los desarrolladores siguen las normas de licencia y no siempre indican la autoría del código. Por tanto, en teoría, la misma vulnerabilidad podría encontrarse en un proyecto de terceros donde no se especifique oficialmente el uso de Log4j.
• Log4Shell era una vulnerabilidad de día cero, lo que significa que los ciberdelincuentes la explotaron antes de que se publicara información sobre ella. Hay pruebas que sugieran que los atacantes la probaran primero durante nueve días antes de hacerla pública.
• Entre los programas afectados estaban los productos de VMware, en concreto la popular solución de infraestructura de escritorio virtual VMware Horizon. Muchos ataques registrados penetraron en el sistema mediante este software.
• Las actualizaciones del programa tendrán muy poco efecto si los intrusos ya están dentro del sistema. No todos los ataques comienzan inmediatamente después de la penetración y es muy posible que muchos sistemas contengan puertas traseras hoy en día.

Daños reales

Para ser justos, cabe destacar que hasta la fecha no se han registrado situaciones catastróficas a causa de la explotación de Log4Shell, o al menos no se ha hecho pública ninguna. Sin embargo, esta vulnerabilidad ha generado grandes quebraderos de cabeza a desarrolladores y expertos de seguridad, llegando incluso a arruinar la Navidad de miles de empleados del sector TI de todo el mundo. Las empresas comprometidas con la seguridad (tanto la suya como la de sus clientes) han tenido que gastar cantidades considerables de dinero para localizar la vulnerabilidad en sus sistemas y software y eliminarla.

Estos son algunos de los incidentes conocidos más notables que ha provocado Log4Shell:

• El 20 de diciembre del 2021, el Ministerio de Defensa belga confirmó un ataque hacia su infraestructura con esta vulnerabilidad. Como es comprensible, no se divulgó información sobre el ataque.
• El 29 de diciembre del 2021, los medios afirmaron que una institución científica de Estados Unidos había recibido un ataque mediante Log4Shell. De acuerdo con CrowdStrike, el grupo de APT, Aquatic Panda, explotó su plataforma VMware Horizon sin parchear. La actividad sospechosa se detuvo a tiempo, pero el incidente por sí mismo reveló que los grupos de cibercriminales importantes ya habían comenzado a explotar la vulnerabilidad.
• También en diciembre del 2021, saltó la noticia de la explotación de Log4Shell en los servidores de Minecraft: Java Edition, no alojada por la distribuidora del juego (Microsoft). La empresa confirmó la información y destacó la simplicidad de la implementación del ataque: los cibercriminales transmitieron código malicioso en un chat dentro del juego, esto les bastó para ejecutarlo tanto en el lado del servidor como en el del cliente. Este caso resulta menos interesante desde la perspectiva de la víctima y más en términos de la implementación técnica: bajo ciertas condiciones, el ataque puede implementarse simplemente a través de un chat interno. Esto resulta preocupante, ya que los chats van más allá del mundo gaming: para muchas empresas son el medio preferido de comunicación con los clientes. De hecho, muchas Fintech y otros tipos de aplicaciones utilizan los chats para la gestión de la atención al cliente.
• En junio de 2022, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) y el Comando Cibernético de la Guardia Costera de EE. UU. (CGCYBER) emitieron una alerta de que la vulnerabilidad aún se estaba explotando en activo. El aviso indicaba que los cibercriminales utilizaban una laguna en el mismo VMware Horizon para penetrar en las redes internas de dos agencias gubernamentales no identificadas. Además, afirmaron que los atacantes obtuvieron acceso a 130 GB de datos confidenciales relacionados con el cumplimiento de la ley.
• En noviembre del 2022, la CISA, junto con el FBI, emitió otro aviso sobre un ataque de Log4Shell a otra agencia gubernamental. Los atacantes penetraron en el sistema en febrero, fueron detectados en abril y permanecieron en activo entre junio y julio. Durante este periodo, crearon una cuenta con privilegios de administrador, cambiaron la contraseña de un gestor legítimo y cargaron el software de minería en el servidor. Se cree que el ataque es obra de un grupo de cibercriminales patrocinados por el gobierno, por lo que los expertos consideran que es solo una cortina de humo para ocultar sus verdaderos motivos.

Protege tu infraestructura

Cualquier empresa puede ser víctima de Log4Shell, a menudo simplemente debido al desconocimiento de la presencia de vulnerabilidades en sus sistemas y software. Si no estás seguro de si tus sistemas, herramientas, productos o servicios utilizan la biblioteca Log4j, podrías realizar una auditoría de seguridad. Aparte de eso, sigue los consejos de nuestros expertos para mantenerte a salvo:

• Si Log4j se encuentra en el software que creas, usa la última versión de la biblioteca disponible en la página del proyecto.
• Lee la guía oficial de Apache Logging Services y síguela siempre que sea necesario.
• Si Log4j se utiliza en productos de terceros, actualiza todo el software vulnerable.
• Utiliza soluciones de seguridad robustas capaces de detectar los intentos de explotación de vulnerabilidades en servidores y estaciones de trabajo.
• Supervisa la actividad sospechosa dentro del perímetro corporativo con soluciones de tipo EDR o servicios externos como los de detección y respuesta gestionada. Esto te permitirá encontrar y detener ataques en etapas tempranas.