Log4Shell, pesadilla (informática) antes de Navidad

Si un ciberdelincuente pudiera escribir su carta a los Reyes, ¿qué pediría en una vulnerabilidad? En primer lugar, pediría una vulnerabilidad desconocida (zero-day). Así los sistemas de seguridad no están preparados para detectarla o mitigarla ni existe todavía un parche todavía que la elimine. En segundo lugar, pediría una vulnerabilidad que permitiera ejecutar código de forma remota. De esta forma, podría hacer lo que quisiera en el sistema atacado: robar datos, instalar troyanos, … Por otro lado, la vulnerabilidad debería afectar a un software que estuviera funcionando en muchos sistemas. Esto incrementaría el número de objetivos y prolongaría el tiempo necesario para parchearlos todos. Y, por último, que fuera muy fácil de explotar. Así cualquier persona sin grandes conocimientos podría tumbar una web o robar los datos de una gran empresa. ¡Claro que sí!

Pues este año los Reyes se han adelantado y nos han traído Log4Shell, una de las vulnerabilidades más severas de la historia reciente. Este problema de seguridad afecta al paquete Log4j, una librería de código abierto dentro del proyecto Apache. Esta librería está implementada en Java y se utiliza para generar un registro (log) de actividades. Como esta es una tarea bastante habitual en muchas aplicaciones, hay muchísimas aplicaciones y servicios que utilizan Log4j.

El problema

Por defecto, las últimas versiones de Log4j permiten usar una funcionalidad llamada JNDI (Java Naming and Directory Interface). Mediante JNDI, Log4j puede realizar consultas a servicios remotos y descargar código a ejecutar. El problema es que un atacante puede enviar texto que incluya una de estas consultas, apuntando a un servidor externo controlado por el atacante (tan fácil como “${jndi:mi-servidor}”). Log4j no comprueba si estas consultas se realizan sobre servidores de confianza, por lo que descargará y ejecutará el código malicioso.

¿Eso es malo? Mucho. Muchísimo. Log4Shell está puntuada con una severidad de 10 sobre 10 (crítica) en la escala CVSS. Y hay quien dice que debería ser 11 sobre 10.

¿Por qué? La cantidad de sistemas vulnerables es para llevarse las manos a la cabeza. Atacar los servidores de Minecraft escribiendo un simple mensaje en un chat. Hackear los servidores de Apple o Tesla cambiando el nombre de tu iPhone o tu vehículo. ¡Hasta el drone Ingenuity en Marte podría ser vulnerable! Y, por si esto fuera poco, otra vulnerabilidad de Log4j ha asomado la cabeza entre todo este caos.

¿Y ahora qué?

No hay duda: todas las organizaciones deberían estar comprobando si sus sistemas son vulnerables y aplicando los parches correspondientes. Pero, además, hay varias conclusiones que podemos sacar de todo este desaguisado.

La primera es que Java sigue dominando. Aunque muchas noticias últimamente parezcan indicar que Python le está ganando terreno a Java como lenguaje de programación, Log4Shell nos deja claro que Java está hasta en la tostadora.

La segunda es la importancia de tener en cuenta la seguridad informática cuando escribimos código. Es crítico no confiar en datos de entrada que pueden ser manipulados por un usuario. Nunca sabes dónde o cómo se va a utilizar el código que escribas.

Otra lección es la relevancia que tiene un paquete de software mantenido por tres personas no retribuidas en su tiempo libre. Las grandes empresas utilizan software libre en sus productos, pero raramente contribuyen para asegurar la calidad y seguridad del software que utilizan. Log4Shell nos demuestra que esta decisión no solo es éticamente reprochable, sino que además es mala para los negocios.

En teoría, el código abierto debería ser más seguro porque todo el mundo puede examinar el código para encontrar errores. Pero, en la práctica, esto no pasa si nadie dedica tiempo y recursos a revisar el código. Por esto es muy importante que las empresas ofrezcan incentivos y recompensas a quien desarrolla software libre… por el bien de todos.