Desde que el pasado 9 de diciembre de 2021 la Agencia de Ciberseguridad y Seguridad de Infraestructuras  (CISA) y la Agencia de Seguridad Nacional (NSA) de los Estados Unidos lanzaran una alerta sobre la vulnerabilidad informática Log4Shell, descubierta en noviembre por un ingeniero de seguridad chino del equipo de Alibaba y calificada de extrema gravedad por la propia directora de CISA, comenzó a desatarse una crisis global en los entornos ciber ante la posibilidad de que afecte a millones de dispositivos y aplicaciones de todo tipo.

En España el Equipo de Respuesta a Incidentes del Centro Criptológico Nacional (CCN CERT) publicó una alerta al día siguiente calificando su nivel de peligrosidad como crítico, el Instituto Nacional de Ciberseguridad (INCIBE) alertó en términos similares y el Departamento de Seguridad Nacinal (DSN) se hizo eco días después de lo expuesto por estos dos organismos.

También la Comisión Europea, la Agencia de la Unión Europea para la Ciberseguridad, el CERT-EU y la red de equipos nacionales de respuesta a incidentes de seguridad informática de la UE (red CSIRT) han estado siguiendo de cerca el desarrollo de la vulnerabilidad Log4Shell desde el 10 de diciembre de 2021.

La importancia de la noticia dio lugar a múltiples informaciones donde los términos Log4j y Log4Shell se utilizan profusamente, en ocasiones de forma algo confusa, creando ciertas dudas en cuanto a la relación entre ambos, así como a su caracterización como un tipo de virus, amenaza o ataque en el ciberespacio, lo cual en ninguno de los dos casos es cierto.

Para tratar de aclarar dudas dedicaré unos párrafos a explicar en qué consiste cada uno de ellos, cuál es su relación, donde radica su peligrosidad y la forma de protegerse.

Log4j vs Log4Shell

Log4j es una biblioteca de código abierto (open source) proporcionada por Apache Software Foundation que forma parte del marco de registro del lenguaje de programación Java y se utiliza para archivar los registros (logs) de los mensajes de error de una aplicación.

Un ejemplo habitual es cuando tecleamos mal el enlace a una página Web que estamos buscando y obtenemos un mensaje de error (el típico 404) que queda registrado en la biblioteca Log4j del servidor que hemos utilizado para la búsqueda.

Log4j es una de las bibliotecas más populares de Java y desde hace décadas se ha convertido en casi en un estándar para archivar los registros de errores. Pero como muchas bibliotecas de código abierto, al no depender de un solo proveedor o propietario, su código fuente es de acceso público lo que significa que se pueden distribuir y modificar libremente razón por la que  las mantienen y actualizan voluntarios dando origen a diversos tipos de fallos o vulnerabilidades,

Una de estas vulnerabilidades es Log4Shell (o CVE-2021-4428) que está presente en toda aplicación que contenga Log4j en sus versiones 2.0 a 2.25.0-rc2 y está calificada como indiqué anteriormente con la máxima gravedad (10/10) pues su explotación permite a un atacante acceder fácilmente a través de Internet a cualquier sistema, dispositivo o aplicación y tomar su control, ejecutar un código malicioso, acceder a los datos e información, o destruir, borrar o cifrar activos para luego demandar un rescate.

En resumen, Log4j es una biblioteca de registro y Log4Shell una de las vulnerabilidades de ella; ninguna de las dos son un virus ni un vector de ataque informático pero con la segunda se ha abierto una enorme puerta de acceso a millones de equipos con consecuencias difíciles de evaluar.

¿Cúal es el peligro?

Como suelo explicar al hablar de gestión de ciberriesgos, concretamente en la que denomino su ecuación,una vulnerabilidad es una debilidad o falta de control que permitiría o facilitaría que una amenaza actuase contra un activo o recurso de un sistema u organización, mientras que una amenaza es cualquier circunstancia o evento que puede explotar, intencionadamente o no, una vulnerabilidad específica de un sistema u organización.

En este contexto, al detectar tal vulnerabilidad (Log4Shell) los hackers de diferente motivación y objetivo, incluidos algunos Estados, han encontrado una gran oportunidad para explotarla, como así se está haciendo, pues al ser del tipo de Ejecución Remota de Código (RCE) es suficiente con enviar remotamente un código malicioso y al registrarse este en Log4j proporciona acceso al sistema o dispositivo pudiendo ejecutar tal código de forma remota tomando el control para posteriormente llevar a cabo sus actividades delictivas.

Desde antes de ser detectada, los ciberdelincuentes ya habían explotado esta vulnerabilidad, pues su vector de ataque es del tipo exploit 0-day, o de día cero, lo cual indica la cuenta de días, comenzando por 0, que el fallo ha estado disponible para el atacante hasta el momento en que se publica una revisión o un parche que corrige la vulnerabilidad.

En este tiempo y posteriormente se han producido millones de ataques, muchos de ellos no detectados, incluyendo ransomware (secuestro de información), minería de monedas virtuales, como bitcoins, troyanos bancarios (como Dridex), robots (bots o zombies) que comprometen equipos, de denegación de servicio (DoS o DDoS), etc., e incluso, como informó el Centro de inteligencia de amenazas de Microsoft (MSTIC), la explotación de log4Shell por múltiples grupos de actividad de Estado-Nación de origen en China, Irán, Corea del Norte y Turquía o el acceso a información de interés para los Estados como ha sido el caso del ataque a los equipos del Ministerio de Defensa belga que según notificó este organismo paralizó parte de sus actividades durante varios días

Uno de los ataques mas populares ha sido el perpetrado contra el famoso videojuego Minecraft, del tipo de juego libre o sandbox, que utiliza la biblioteca Log4j lo que facilitó que sus servidores fueron hackeados utilizando un simple mensaje de chat de sus jugadores, paralizando su actividad y eliminando jugadores.

A quien afecta

Esta pregunta es de difícil respuesta pues la gran mayoría de las aplicaciones, tanto públicas como privadas, están escritas en Java por lo que muchas de ellas, posiblemente cientos de miles, pueden tener instalada la biblioteca Log4j y en consecuencia estar expuestas a la vulnerabilidad Log4Shell.

A ello debe añadirse que al ser Log4j de código abierto es muy dificl conocer el número, ni siquiera aproximado, de sistemas, aplicaciones y dispositivos que la usan. Lo que si es evidente, dada la popularidad de Java es que está instalada en servidores, routers, ordenadores e impresoras, teléfonos móviles, smartphones y smartwatchs y otros dispositivos de Internet de las Cosas (IoT), así como en apliaciones, juegos, software de uso personal y profesionasl, etc.

Por ello la aparición de Log4Shell se ha convertido en una puerta abierta de enormes dimensiones puesta a disposición de toda una amplia gama de cibercriminales, individuos aislados, grupos organizados, organizaciones terroristas y Estados.

¿Cómo protegerse?

Desde una perspectiva de usuario individual la posibilidad de autoprotección es muy limitada, como lo es la de su detección, si bien, como siempre, es recomendable mantener actualizadas las aplicaciones y sistemas, de forma especial los antivirus, y si es posible contactar con sus proveedores, en particular los servicios en la nube, para conocer si utilizan la biblioteca Log4j y en caso afirmativo asegurarse que han tomado las medidas correctoras adecuadas.

Si el usuario lo es como integrante de una organización, empresa, etc, la respuesta a esta pregunta debe dirigirse a los desarrolladores, responsables del mantenimiento y administradores de sistemas y aplicaciones, sobre todo en los que están conectados a Internet.

En este caso, como en el de esos colectivos, las medidas a tomar son múltiples destacando entre ellas las siguientes, parte de las cuales están expuestas en la guía publicada por la CISA y su JCDC (Joint Cyber ​​Defense Collaborative):

  • Identificar los activos que utilizan Log4j comprobando la versión utilizada y si han sido afectados por Log4Shell y otras vulnerabilidades relacionadas con Log4j
  • Actualizar tales activos a las ultimas versiones publicadas de Log4j, con los parches disponibles, y revisar permanentemente la Guía «Vulnerabilidades de seguridad de Apache Log4j» publicada en la pagina Web de Apache donde se publican nuevas actualizaciones y medidas de mitigación.
  • Monitorizar posibles incidentes para detectar una posible explotación de Log4Shelly si se ha producido tomar las medidas necesarias para mitigar los daños y notificar siempre el incidente.

Y una vez mas recordar las medidas de protección elementales que deben tomarse para anticiparse a situaciones de este tipo, como disponer de antivirus y cortafuegos, en especial de aplicaciones web, limitar el tráfico por las redes, sobre todo en Internet, efectuarlo a través de una red privada virtual (VPN) y actualizar todas las aplicaciones y servicios para instalar los parches mas recientes.

Con esta y otras medidas reduciremos el nivel de riesgo teniendo siempre en mente que en la actualidad la pregunta ya no es saber si seremos atacados sino cuando lo seremos, si no lo hemos sido ya.