Qué es Log4Shell y por qué es la peor vulnerabilidad informática de la década

El pasado 24 de noviembre, el investigador Chen Zhaojun, de Alibaba Cloud Security Team, encontró una debilidad en Log4j, una popular herramienta del gigante del código abierto Apache que está presente en un sinnúmero de páginas web y aplicaciones. La vulnerabilidad, bautizada como Log4Shell, permite a un potencial cibercriminal ejecutar código en un equipo ajeno de forma remota. Entre los riesgos que pueden colarse por esta puerta entreabierta y hasta ahora desconocida están virus informáticos que permitan secuestrar datos o habilitar sistemas de espionaje, entre otros.

Según recoge Bloomberg, Zhaojun se apresuró a contactar con Apache, pero mantuvo en secreto su descubrimiento con la intención de dar margen de respuesta a sus desarrolladores. “Por favor, daos prisa”, escribió a los pocos días. La urgencia era pertinente. Log4Shell ha sido calificada como la vulnerabilidad más crítica de la última década, no tanto por su complejidad como por el hecho de que el uso de esta librería está tan extendido que es imposible determinar a cuántas entidades afecta. El problema es lo que se conoce como una vulnerabilidad de día cero ―zero day―, que identifica aquellas brechas de seguridad para las que todavía no se ha diseñado un parche. Cualquier sistema que incorporase Log4j antes de que empezasen a llegar las actualizaciones está expuesto.

El anuncio oficial de la existencia de Log4Shell, que llegó el 9 de diciembre, desató una carrera en sentidos opuestos: desde un extremo, empresas y administraciones de todo el mundo corrieron a asegurar sus sistemas; desde el otro, bandas de cibercriminales de la talla de Conti ―uno de los principales operadores de secuestros informáticos a nivel mundial―, se apresuraron a sacar tajada antes de que la situación estuviese controlada. La competición sigue en marcha.

Log4j es una librería de código abierto (open source) creada por Apache Software Foundation. Los recursos de este tipo incluyen funciones ya desarrolladas que permiten a los programadores trabajar más deprisa, sin necesidad de construir todo desde cero. Miles de desarrollos integran esta herramienta en sus propios programas para monitorizar su actividad. “Es casi universal”, resume Eusebio Nieva, director técnico de la empresa de ciberseguridad Check Point Software para España y Portugal. La información contenida en los registros que genera Log4j puede emplearse, por ejemplo, para encontrar errores en el desempeño del programa que están vigilando.

La enorme difusión de esta librería la justifica la importancia de Apache en el mundo open source y el hecho de que Log4j esté dirigida al desarrollo de aplicaciones en Java. Este lenguaje de programación, presente en aplicaciones y páginas web, es según la última encuesta de Stack Overflow el cuarto más utilizado a nivel mundial, solo por detrás de Javascript, Python y SQL.

Esta vulnerabilidad podría permitir a un tercero ejecutar código en un equipo ajeno de forma remota. ¿Qué se puede hacer con un poder así? “Ancha es Castilla”, resume José Rosell, socio director de la compañía S2Grupo, especializada en ciberseguridad y operaciones de sistemas de misión crítica. La posibilidad de introducir comandos en la máquina atacada permitiría, por ejemplo, descargar un virus de secuestro informático con el que infectar y cifrar los equipos de la red; o sencillamente espiar. “Lo que tenemos es una vulnerabilidad que nos permite entrar en una o varias computadoras de la organización. A partir de ahí ya se pueden usar las técnicas clásicas de ataque”.

El principal problema y lo que convierte a esta vulnerabilidad en la peor de la década es en lo extendido que está el uso de esta librería. “Ha habido vulnerabilidades mucho más sofisticadas, el problema de esta es la superficie de exposición. Cada vez que lo pienso se me ponen los pelos de punta”, admite Rosell.

Al potencial de Log4Shell para el desastre contribuye el hecho de su aprovechamiento es una tarea relativamente fácil. “Para explotar estas vulnerabilidades, todo lo que se necesita es una pequeña cantidad de código Java, disponible fácilmente a partir de pruebas de concepto publicadas, y una herramienta que sea capaz de manipular el contenido de las solicitudes web u otro tráfico de internet que pueda ser registrado por el software objetivo del ataque”, precisa Sean Gallagher, investigador principal de amenazas de la firma de ciberseguridad Sophos.

La versatilidad de Java y la ubicuidad de Log4j en los desarrollos que emplean este lenguaje sitúa esta vulnerabilidad en todo tipo de sistemas. “Desde el router que tienes en tu casa, hasta la aplicación del móvil que tienes para acceder a tu cuenta del banco, pasando por los programas que puedes tener implementados en un coche”, enumera el portavoz de S2Grupo.

Aunque se están elaborando listas de proveedores cuyos productos integran Log4j, desde Apache insisten en que es imposible conocer con exactitud su verdadero alcance. “Cualquier cifra sería pura especulación y probablemente errónea por un gran margen”, sentencian en el blog de la fundación.

En Check Point habían detectado hasta el pasado viernes cerca de tres millones de intentos de explotar la vulnerabilidad. Más del 46% de estos procedían de grupos maliciosos conocidos. “Y estos son solo los que hemos visto nosotros”, matiza Nieva.

La firma de seguridad Netlab también encontró, a los pocos días de conocerse la vulnerabilidad, software malicioso de diez familias distintas propagándose a través de Log4j. Entre estos destacan criptomineros como Kinsing, que emplean los recursos de las máquinas infectadas para extraer criptomonedas, o botnets como Muhstik, que integran los equipos en una red con la que el cibercriminal puede orquestar otros ataques.

Para Rosell, el peor escenario posible es una escalada de incidentes de ciberseguridad que termine por saturar la capacidad de respuesta de empresas como la suya: “Ahora no es que sea plato de buen gusto, pero vamos a velocidad de crucero. El miedo que tenemos es que no dé tiempo a parchear suficientemente rápido como para evitar una ráfaga de ataques”.

Apache acompañó el anuncio de la vulnerabilidad con la publicación del primer parche destinado a subsanarla. Desde entonces, se han publicado otras dos actualizaciones que amplían la protección y complican la utilización de Log4j por parte de los cibercriminales. Los sistemas que tengan incorporadas las últimas versiones tendrían que estar a salvo.

La pelota está ahora en el tejado de las incontables empresas e instituciones cuyos programas informáticos (comerciales o hechos a medida) pueden incorporar una versión antigua de la librería. “En primer lugar, las empresas tienen que saber cuál de los programas que tienen es vulnerable, y los desarrolladores de ese software tienen que publicar nuevas versiones que los clientes puedan instalar. Las empresas que han creado sus propias aplicaciones de internet en las que utilizan componentes Java tendrán que comprobar y actualizar el código Log4j en cualquiera de esas aplicaciones”, detalla Gallagher.

A los usuarios finales nos queda la responsabilidad de asegurarnos de que estamos al día en el apartado de seguridad de nuestros dispositivos y sus aplicaciones. Aunque muchas de ellas se realizarán de forma automática y en segundo plano, es posible que en algunos casos se notifique que hay procesos pendientes. “Que se hagan lo antes posible todas las actualizaciones que se pidan de sistemas operativos de móviles, tabletas y ordenadores”, urge Rosell.

“Nunca”, sentencia Rosell. Una vez más, la amplia difusión de esta librería hace utópico esperar una que el 100% de las entidades que la usan instalen los parches pertinentes. Es razonable esperar que las grandes organizaciones inviertan los recursos necesarios en neutralizar la amenaza a corto plazo y que esto disipe un poco los riesgos asociados a Log4Shell. Sin embargo, la espera puede alargarse hasta la eternidad en el caso de entidades menores que no tienen los medios para tomar medidas o en aquellas que incluso ignoran que Log4j forma parte de sus sistemas.

“Por desgracia, hay cientos de productos vulnerables y es posible que las empresas no descubran todas sus vulnerabilidades hasta dentro de unos meses, si es que lo hacen”, comenta Gallagher. De hecho, lo habitual es que estas vulnerabilidades sigan siendo explotadas por los criminales hasta varios años después de haber sido identificadas.