Hace ahora un año, tuvo lugar la difusión de una vulnerabilidad ‘zero day’ que afectó potencialmente a millones de usuarios de toda clase de plataformas online (de Steam a Cloudflare, de iCloud a Minecraft, etcétera): la denominada vulnerabilidad ‘Log4Shell’, así denominada porque afectaba a una casi desconocida biblioteca de código abierto denominada Apache Log4J.
Pero, aunque fuera poco conocida, lo cierto es que era (y sigue siendo) una pieza fundamental entre las aplicaciones (libres y privativas) del ecosistema Java, al tener la función de facilitar que éstas mantengan un registro de las actividades realizadas en tiempo de distribución.
Tan fundamental era esta pieza, que rápidamente se asignó a la vulnerabilidad una puntuación 10/10 en el CVSS (Common Scoring System). Por fortuna, tan sólo 24 horas después de difundirse la existencia de la vulnerabilidad, los mantenedores del proyecto Log4J habían sido capaces de lanzar la versión parcheada.
El escándalo de los voluntarios trabajando contrarreloj para Silicon Valley
Lo cual, como se reveló al poco tiempo, era un logro descomunal, pues el equipo de personas responsable de este software (usado, insistimos, por miles de grandes plataformas) era de tan sólo 10 personas… de las cuales sólo 3 pudieron contribuir en ese momento a crear el parche. ¿El motivo? Todos ellos eran desarrolladores voluntarios que trabajan en Log4J “en su tiempo libre”. Alguno de ellos sólo pudo dormir dos horas aquella estresante noche.
Cuando esto se supo, muchos usuarios denunciaron la precaria situación de un proyecto tan crítico. Se criticó que la Fundación Apache tenga una amplia página detallando las responsabilidades de los programadores de sus proyectos, cuando es gente que trabaja por amor al arte… y, sobre todo, arreciaron las críticas contra las compañías multimillonarias que se benefician del software que esta gente desarrolla sin molestarse en realizar ninguna donación.
Tanto, que tan sólo un mes después de aquello, la propia Casa Blanca convocó una cumbre de las organizaciones open source, grandes tecnológicas y agencias federales estadounidenses para evitar nuevos casos de vulnerabilidades graves en proyectos open source críticos. Se llegó a hablar de establecer mecanismos para permitir la sostenibilidad de los mismos y acortar su tiempo de respuesta.
Pero, ¿cómo está la cosa doce meses después?
Log4J y Log4Shell, un año más tarde
En resumen, a día de hoy, el creador y principal responsable de Log4J, Ralph Goers, sigue teniendo dos trabajos “a tiempo completo”, en el que Log4J es, precisamente, el no-remunerado. El número total de colaboradores (repetimos, todos ellos voluntarios) sólo se ha incrementado en uno (1, sí). Goers, al menos, ha visto como su número de patrocinadores en GitHub Sponsors se ha multiplicado desde los tres (3, sí) que tenía cuando explotó el tema de Log4Shell hasta los actuales 31 (otros 90 llegaron a patrocinarle en algún momento tras la polémica, pero ya se han ‘caído’).
Podríamos decir que a Goers y sus compañeros les queda la tranquilidad del trabajo bien hecho: su rápida reacción en diciembre de 2021 evitó muchos ciberataques. Sin embargo, aún hoy, entre el 30% y el 40% de las instalaciones de Log4J no se han molestado en instalar las versiones parcheadas del mismo.
Tanto es así que, en una fecha tan reciente como septiembre de 2022, las agencias de ciberseguridad en los Estados Unidos, Reino Unido, Australia y Canadá lanzaron una advertencia de que cibercriminales presuntamente financiados por el régimen de Irán seguían explotando las vulnerabilidades de Log4j para ejecutar campañas de ransomware.
(function() {
window._JS_MODULES = window._JS_MODULES || {};
var headElement = document.getElementsByTagName(‘head’)[0];
if (_JS_MODULES.instagram) {
var instagramScript = document.createElement(‘script’);
instagramScript.src = ‘https://platform.instagram.com/en_US/embeds.js’;
instagramScript.async = true;
instagramScript.defer = true;
headElement.appendChild(instagramScript);
}
})();
