El agujero de ciberseguridad del siglo
Un error en un fragmento de código secundario muy popular deja desprotegidos millones de servidores, aplicaciones y dispositivos. Los administradores de sistemas podrían tardar años en repararlo
Como traca final de un año marcado por los ciberataques, cada vez más frecuentes y graves, la semana pasada salió a la luz la llamada Log4Shell, una vulnerabilidad que afecta a buena parte de los sistemas y dispositivos conectados a internet y que los ciberdelincuentes pueden explotar fácilmente para comprometer su funcionamiento, capturar datos y propagar nuevas infecciones. El alcance del problema es difícil de determinar, pero los especialistas consideran que es de los más graves que se han visto. Y todavía peor, a pesar de ser técnicamente sencillo de resolver, se tardará semanas, si no meses o incluso años, en hacerlo.
Log4Shell es la denominación que ha recibido el agujero de seguridad causado por un error de programación en la biblioteca de código abierto Log4j, que se usa en todo tipo de productos y aplicaciones conectados, desde equipaciones de red de Cisco y Broadcom, pasando por aparatos de domótica del hogar, los coches de Tesla, plataformas en la nube como las de Amazon AWS, Oracle, Twitter y Apple iCloud, servicios de videojuegos como Steam y Minecraft y, sobre todo, millones de aplicaciones corporativas de organismos públicos y empresas privadas como bancos o compañías de seguros.
La mayoría de las aplicaciones escritas en lenguaje Java contienen el mencionado software Log4j, que sirve para guardar de manera estándar el registro de los mensajes que las aplicaciones generan sobre el comportamiento del sistema, sus usuarios y los eventuales mensajes de error de ejecución, para que los programadores puedan examinarlo en caso de incidencias o cuando quieran optimizar su funcionamiento. Log4j forma parte del amplio repositorio de código abierto del Apache Software Foundation (ASF), una activa comunidad distribuida de programadores que nació en 1999 para desarrollar y mantener el servidor web httpd, uno de los más populares de la red, y desde entonces ha ido abordando otros muchos proyectos de programación que creadores de aplicaciones de todo el mundo incorporan libremente a sus propios productos. Muchos de estos módulos de software se ocupan de funciones secundarias de la aplicación, y evitan que los programadores tengan que dedicar tiempo y recursos a reinventar cosas que alguien ya creó y mantiene actualizadas. Es por eso que el código de Log4j se encuentra incrustado en una gran cantidad de aplicaciones y servicios que hasta ahora no se ha podido cuantificar.
Detectado a finales de noviembre
El día 29 de noviembre, un responsable de ciberseguridad del gigante digital chino Alibaba informó al ASF que había observado que escribiendo determinadas órdenes maliciosas en el chat entre usuarios del videojuego Minecraft era posible tomar el control de Log4j y ejecutar en el equipo una gran variedad de código remoto. Como se ha visto después, esta ejecución maliciosa puede ir desde activar redes de bots, capturar datos y extraerlos del servidor infectado o cifrar el contenido al estilo ransomware para pedir después un rescate, o simplemente quedarse en forma latente en el sistema a la espera de nuevas órdenes. El jueves 9 de diciembre, el ASF confirmó públicamente la existencia de la vulnerabilidad y la disponibilidad de una versión corregida del código de Log4j, e instó a todos los administradores de sistemas a aplicarla urgentemente. Desgraciadamente, ya era demasiado tarde: los ciberdelincuentes también habían detectado el agujero y algunas empresas especializadas aseguran que los días 1 y 2 ya se observaron los primeros ataques a servidores buscando versiones de Log4j vulnerables. A estas alturas se estima que el 40% de las redes del mundo han recibido este tipo de visitas maliciosas, que ya suman decenas de miles cada minuto. Microsoft asegura que algunos de estos intentos de intrusión corresponden a grupos generalmente vinculados a los gobiernos de China e Irán.
Simultáneamente, los administradores de sistemas informáticos hacían horas extras durante el fin de semana para intentar mitigar la amenaza. En muchos casos se trata de aplicar los parches de seguridad que los fabricantes de productos y servicios afectados han ido publicando en sus webs y que repositorios de código como GitHub han ido recopilando. Alguna empresa incluso ha publicado un parche recursivo, que explota la misma vulnerabilidad para proteger el sistema hasta que se le aplique una actualización más definitiva. En otros casos se han establecido listas negras de direcciones IP desde donde se sabe que proceden algunos ataques, pero los ciberdelincuentes son muy ágiles y enmascaran pronto su ubicación. Además, se han descubierto otras vías para explotar el punto débil de Log4j, como manipular las cabeceras de las peticiones que los navegadores de los visitantes hacen a los servidores web para ver cada una de sus páginas: por ejemplo, la llamada USER AGENT, que indica con qué navegador web y qué sistema operativo nos estamos conectando. En esta cabecera se pueden incluir órdenes maliciosas que tomen el control de Log4j.
El gran problema de esta vulnerabilidad es su ubicuidad. Como hemos dicho, los programadores de Log4j (tres voluntarios del ASF que trabajan en sus ratos libres) han tapado el agujero y han distribuido una versión protegida. Igualmente, los fabricantes de muchos productos y servicios afectados han creado parches que protegen los sistemas en funcionamiento. Desgraciadamente, se desconoce el alcance de la vulnerabilidad: cada programador incorpora el código de Log4j en su producto cuando más le conviene, y a menudo lo hace de manera indirecta sin ser consciente, porque el módulo está incluido en otra de las bibliotecas de software que ha usado. En pocas palabras, hay administradores de sistemas que no saben si su instalación contiene o no una versión vulnerable de Log4j, y es posible que ni siquiera sepan cómo averiguarlo.
Mientras los informáticos que sí que lo saben se afanan en poner remedio, ya han surgido en el sector al menos dos debates: uno, sobre la necesidad de que todas las aplicaciones estén documentadas a fondo con una sonda detallada de todos los módulos de código que contienen, y otro, sobre la responsabilidad de los productos comerciales que funcionan gracias a fragmentos de código abierto creado por voluntarios. Mientras tanto, sin embargo, nadie osa poner horizonte temporal a una eventual erradicación de Log4Shell, que probablemente continuará presente durante años en muchos rincones de internet como un nuevo vector de ataque a disposición de los ciberdelincuentes.
