La amenaza persistente: por qué vulnerabilidades graves como Log4Shell y Spring4Shell siguen siendo importantes

Como desarrolladores, estamos constantemente equilibrando funcionalidades, correcciones y fechas de entrega. Sin embargo, hay un problema latente que sorprendentemente se ha pasado por alto: el uso continuado de versiones vulnerables de Log4j y Spring Framework en muchos proyectos. A pesar de la gran exposición mediática de las vulnerabilidades Log4Shell y Spring4Shell, una cantidad alarmante de aplicaciones todavía funciona con estas bombas de tiempo. No es un simple descuido: es un riesgo importante. Nos apasiona crear, pero parte de crear es asegurarnos de que nuestras estructuras sean seguras.

El dilema de los desarrolladores

Como desarrolladores, equilibramos constantemente la publicación de nuevas funcionalidades con el mantenimiento de los proyectos y las funcionalidades existentes. Es un acto de equilibrio que exige tiempo y toda nuestra capacidad de concentración. Llevar un control de las dependencias de cada proyecto y asegurarnos de que estén actualizadas puede parecer una batalla cuesta arriba, sobre todo cuando hay presión para entregar nuevas funcionalidades. En medio de tantas tareas, vulnerabilidades críticas como Log4Shell y Spring4Shell pueden pasar desapercibidas; no por negligencia, sino por el gran volumen de tareas que gestionamos a diario. Sin embargo, es esencial reconocer que la seguridad de las aplicaciones innovadoras es un aspecto crucial del desarrollo de software hoy en día.

El estado actual de Log4Shell

¿Recuerdas Log4Shell? Esa grave vulnerabilidad de Apache Log4j descubierta en 2021 que permitía a los atacantes ejecutar código en tu servidor al registrar una cadena especial. Un atacante podía usar una búsqueda JNDI con el protocolo LDAP para inyectar un archivo de clase precompilado y ejecutar código malicioso. Incluso en versiones más recientes de Java, esta vulnerabilidad podía causar daños mediante ataques de deserialización. La complejidad del ataque de esta vulnerabilidad crítica se considera muy baja, lo que hace que la amenaza sea aún mayor de lo habitual. Consulta nuestra publicación del blog para conocer todos los detalles.

Más del 20 % de las empresas siguen siendo vulnerables a Log4Shell.

Actualmente, muchas empresas todavía tienen una versión obsoleta y vulnerable de la biblioteca Log4j en alguno de sus proyectos. De todas las empresas que analizan su código de producción en busca de vulnerabilidades, 21 % todavía tienen proyectos vulnerables a Log4Shell. Eso significa que más de 60 mil proyectos siguen en riesgo de sufrir una brecha debido a una vulnerabilidad que se divulgó y corrigió hace más de dos años. ¡Es muchísimo! Si tenemos en cuenta que estas empresas ya usan herramientas de seguridad y trabajan activamente para mitigar los problemas que detectan, el número real de versiones vulnerables de Log4j en uso será mucho mayor. Solo pensarlo no solo da miedo, sino que también es muy inquietante.

Spring4Shell en circulación

Otro ejemplo muy conocido fue Spring4Shell, divulgada en marzo de 2022. La vulnerabilidad de spring-beans también podía permitir la ejecución remota de código malicioso. Aunque la complejidad del ataque era baja y había exploits para casos específicos, el impacto fue menor que el de Log4Shell. Consulta la publicación del blog dedicada al tema para obtener más detalles.

Al extender esta vulnerabilidad a Glassfish mediante un nuevo exploit en abril de 2022, el equipo de Snyk demostró que esta vulnerabilidad es muy significativa y que podría aprovecharse en muchos más casos, más allá del exploit inicial para Tomcat.

Al igual que Log4Shell, descubrimos que Spring4Shell todavía está presente. Cerca del 35 % de las empresas aún tienen Spring4Shell en alguno de sus proyectos. Aunque el riesgo de una brecha por Spring4Shell no era tan significativo como el de Log4Shell, el equipo de Snyk demostró varios exploits potenciales al identificar y desarrollar una prueba de concepto (POC) de exploit para Glassfish. Esto demuestra que incluso amenazas aparentemente menores pueden dar lugar a vulnerabilidades de seguridad importantes. ¡Que todavía no se haya publicado ningún exploit no significa que una vulnerabilidad no pueda comprometer una aplicación!

Además, esto demuestra que muchas aplicaciones Spring dependen de versiones antiguas y obsoletas del framework, y que se considera poco importante actualizar y dar mantenimiento a las aplicaciones existentes. Sin embargo, en el fondo sabemos que es una bomba de tiempo que puede explotar en cualquier momento.

Un llamado de atención para quienes mantienen aplicaciones

Hablemos claro y vayamos al grano. Todos conocemos el orgullo que sentimos cuando nuestro código por fin funciona sin problemas, y lo último que queremos es volver a tocarlo, especialmente por algo tan poco emocionante como actualizar bibliotecas. Pero aquí está el problema: las vulnerabilidades Log4Shell y Spring4Shell no se van a corregir solas. Y, sinceramente, no son errores menores que podamos ignorar. Son brechas enormes en las defensas de nuestras aplicaciones. Si todavía tienes vulnerabilidades como Log4Shell o Spring4Shell en tu entorno, estás innecesariamente expuesto a ataques de alta gravedad.

Snyk puede ayudarte a detectar y corregir vulnerabilidades de seguridad en tus aplicaciones. Se integra con los flujos de trabajo de desarrollo de varias formas, por ejemplo, mediante repositorios de Git, su interfaz de línea de comandos (CLI) o los procesos de integración continua (CI) existentes. Así, los desarrolladores pueden identificar riesgos de seguridad en las primeras etapas del ciclo de desarrollo, antes de que se conviertan en problemas mayores. El registro es gratuito y te permite acceder de inmediato a sus funciones. Sin embargo, el valor real está en cómo se gestionan y resuelven las vulnerabilidades detectadas.

Debemos asumir nuestra responsabilidad. No se trata solo de encontrar una solución rápida o esperar que una simple actualización lo resuelva todo. A veces, tenemos que tomar la difícil decisión de eliminar o reemplazar una biblioteca vulnerable. Sí, quizá nos retrase un poco y no sea la parte más emocionante de nuestro trabajo, pero es fundamental. Se trata de garantizar que nuestro código sea sólido, no solo hoy, sino a largo plazo.

Así que no esperemos a que alguien más resuelva estos problemas. Con las herramientas adecuadas, podemos detectar estas vulnerabilidades a tiempo, pero debemos ser nosotros quienes actuemos. Nos corresponde reforzar nuestras defensas, corregir esas vulnerabilidades y mantener nuestras aplicaciones seguras. Pongámonos manos a la obra, no solo como programadores, sino como personas que respaldan su trabajo y se aseguran de que sea lo más seguro posible.