Log4Shell, pesadilla (informática) antes de Navidad

17 diciembre, 2021
Foto: Pixabay en Pexels.

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.

Autor / Autora
Robert Clarisó Viladrosa
Profesor de los Estudios de Informática, Multimedia y Telecomunicación de la UOC. Director del Bachelor's Degree in Techniques for Software Development de la UOC.
Comentarios
Javier Martí19 diciembre, 2021 a las 2:22 pm

Excel·lent article Robert !!!
Clar i concís en explicar el problema 🙂
I a més a més, es denúncia que el programari lliure no només està per ser emprat per tothom, incloses les finalitats lucratives, sinó també recolzat.
Moltes gràcies Robert!

Responder
    rclariso23 diciembre, 2021 a las 12:13 pm

    Moltes gràcies Javier!

    Responder
Jordi Garcia20 diciembre, 2021 a las 11:17 am

Bon article, sobre una problematica actual, però disenteixo sobretot dels dos paràgrafs finals. La seguretat en si mateixa no es veu perjudicada de cap manera pel programari lliure, mes aviat tot el contrari. Gracies precissament a ser programari lliure es van poder solucionar les vulnerabilitats en temps record, en dos dies ja es tenien els primers patch per solucionar els problemes inmediats. I varen ser aquelles tres persones mateixes sense remuneració les que van salvar la papereta a tot l’entorn empresarial, que no havia aportat res.

Per altre banda cal recordar que el segon major problema aquest any van ser les multiples vulnerabiliatst del sistema d’impressió de windows, que van trigar mes de 4 mesos en solucionar. I no parlem dels incidents de ransomware (que n’hem patit les consequencies a Catalunya mateix) que s’aprofiten de múltiples vulnerabilitats 0-day als sistemes windows.

Responder
    rclariso23 diciembre, 2021 a las 12:11 pm

    Hola Jordi.

    Gràcies pel comentari. Intento aclarir el punt de vista que intentava exposar.

    El problema no és el software lliure com a filosofia ni com a metodologia de desenvolupament. Com tu expliques, el codi obert ha permès diagnosticar i resoldre el problema de forma molt efectiva.

    El problema de fons és l’ús que es fa del software lliure en productes i serveis d’ús massiu o de rellevància crítica. Quan es fa això, es genera un incentiu molt gran a qualsevol atacant per trobar errors o vulnerabilitats en aquest software. Per contrarrestar això, caldria que els «grans usuaris» fessin algun tipus de contribució als paquets que utilitzen (ja sigui en forma de temps de desenvolupament, testing, documentació, …) o donessin un incentiu als autors o a la comunitat per millorar-ne la qualitat.

    Certes tasques per assegurar la qualitat del software, com ara fer proves exhaustives, requereixen temps i esforç. Si un sistema crític per una empresa es recolza en un paquet de software lliure, no és just traslladar aquesta responsabilitat als desenvolupadors que hi contribueixen de forma desinteressada. Cal demanar als «grans usuaris» que siguin co-responsables de la qualitat del software lliure que utilitzen.

    Responder
Clara Beleña20 diciembre, 2021 a las 11:57 am

Totalment d’acord amb les conclusions del teu article, i també afegiria que la gestió de l’obsolescència és molt millorable en general!

Responder
    rclariso23 diciembre, 2021 a las 12:14 pm

    Moltes gràcies Clara. Totalment d’acord amb tu!

    Responder
Deja un comentario