Estos últimos días seguramente hayan sido bastante movidos para sysadmins repartidos por organizaciones de todo el mundo, el motivo una vulnerabilidad 0-Day denominada Log4Shell log4j vulnerability (CVE-2021-44228): https://nvd.nist.gov/vuln/detail/CVE-2021-44228#range-7252421, con un score de 10 sobre 10, que muchos denominaron como de dimensiones catastróficas.
No entraré demasiado en detalles, puesto que información hay de sobra en internet, simplemente señalar que es una vulnerabilidad relativamente fácil de explotar, por ejemplo los servidores de minecraft: https://www.minecraft.net/es-es, fueron hackeados con un simple mensaje enviado en su Chat, y que ha afectado a distintos productos software, muy extendidos y heterogéneos entre sí, hablamos de referencias de Apache, VMWare, Fortinet, Cisco, Solarwinds… algunas de ellas bien resumidas en la alerta de INCIBE correspondiente: https://www.incibe-cert.es/alerta-temprana/avisos-seguridad/log4shell-vulnerabilidad-0day-ejecucion-remota-codigo-apache-log4j
Un curioso ejemplo de hasta dónde puede llegar el problema, es que el helicóptero Ingenuity que estos días ha estado sobrevolando el planeta Marte, utiliza un Apache Log4j afectado por la vulnerabilidad.
¿Qué hacer en un caso como este?
Pues básicamente seguir las siguientes premisas:
- Comprobar si afecta a alguno de los productos que utilizas en tu organización, y seguir las medidas de mitigación correspondientes. Desde SwitHak se han currado un buen resumen de productos y fabricantes involucrados: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
- Comprobar si la librería comprometida, está siendo utilizada en algún desarrollo propio (ya han sacado herramientas de escaneo si necesitas una ayuda extra), y posteriormente actualizar a la versión segura si corresponde.
- Comprobar si tu solución firewall posee opción de bloqueo, y obtener las últimas firmas para tratar de mitigar los ataques externos.
Pero a parte de las pautas anteriores, creo interesante hacer una reflexión sobre el origen de esta vulnerabilidad, y me explico, la misma está asociada a una librería OpenSource de la Apache Foundation, que básicamente permite en el entorno de aplicaciones Java, mantener un LOG o registro de actividades realizadas. Es decir, que muchas soluciones software, e incluso un desarrollo propio en este lenguaje, puede que se hayan beneficiado del uso de esa librería. Esta práctica es muy común, es decir, si ya hay un componente hecho que además funciona bien, no tiene sentido desarrollar la funcionalidad de cero para tu proyecto.
Cuando se ha publicado la vulnerabilidad, muchos han dirigido las miradas a los desarrolladores que están manteniendo la librería, incluso ha habido algunos ataques desagradables a través de redes sociales, sin embargo el trasfondo requiere cuanto menos algo de atención.
Y es que la librería se mantiene por 3 desarrolladores, que lo hacen de manera altruista en su tiempo libre, tal y como se puede comprobar en la página de Ralph Goers, el creador además de la versión inicial de Log4J. Es decir, estas personas tienen su trabajo a tiempo completo, y en sus ratos libres mantienen o desarrollan proyectos como Log4J, y lo hacen de gratis o casi de gratis, ya que a lo sumo reciben algo de dinero de los sponsors que consigan a través de GitHub como el ejemplo anterior (en el momento de la vulnerabilidad, el bueno de Ralph únicamente contaba con 3 sponsors).
Tras las críticas y ataques recibidos, estos desarrolladores han tratado de defenderse, indicando que el problema (solucionado en menos de 24 horas), ha conllevado un duro trabajo por su parte, restado incluso de horas de sueño, y todo ello sin recibir un duro a cambio.
La reflexiones finales, al menos desde mi punto de vista, son que muchas veces el software libre no recibe el apoyo y reconocimiento necesario. Siguiendo el ejemplo de esta vulnerabilidad, por una parte, vemos que hay empresas millonarias utilizando una librería (con la criticidad que ha demostrado tener), sin aportar absolutamente nada a las personas que en último término están encargándose de la misma, por otro, vemos críticas además hacía ese trabajo altruista cuando surgen problemas. Supongo que la solución no es fácil ni sencilla, pero sin duda es necesario que se trabaje en mejorar las condiciones de los desarrolladores de proyectos similares a Log4J.
