Spring4Shell: lo que sabemos sobre la vulnerabilidad de ejecución remota de código en Java

¿Ya conoces Spring4Shell? Ve directamente a la sección de mitigación de Spring4Shell de este blog o lee nuestro análisis detallado de Spring4Shell para descubrir cómo funciona la ejecución remota de código (RCE) de día cero.

Muy temprano en la mañana del 30 de marzo (para mí), mi colega DeveloperSteve publicó un mensaje en nuestro canal de Slack que decía: «Oye, ¿viste esto?». Era una «alerta anticipada» sobre una «probable» ejecución remota de código (RCE) en el popular framework de Java Spring. Después supe que, incluso antes, el equipo de Seguridad de Snyk había empezado a investigar una posible RCE en Spring tras ver un tuit que ya fue eliminado.

Al principio, los detalles parecían poco claros. Había un tuit con capturas de pantalla que se había eliminado. También se hacía referencia a un pull request (PR) que, como resultó, se había creado el 18 de febrero, pero no se integró hasta el 29 de marzo.

Varias personas intentaban popularizar el apodo «Spring4Shell» (o, a veces, simplemente SpringShell), mientras que quienes mantienen Spring Core agregaban comentarios al PR que indicaban que no se conocía ninguna RCE.

Entonces, ¿qué diablos estaba pasando y qué está pasando ahora?

Entonces, ¿qué es Spring4Shell?

Si usaste la anotación @Autowired o aprovechaste la magia de la inyección por constructor, ya te encontraste con la inyección de dependencias en el ecosistema de Spring.

En las versiones afectadas, se puede lograr una RCE al manipular el ClassLoader mediante una solicitud HTTP POST cuidadosamente diseñada.

Por ahora, solo se sabe que el exploit es posible con una versión 9 o posterior del entorno de ejecución de Java (JRE) Y una versión 9 o posterior de Tomcat.

Por precaución y para no actuar con información incompleta, los investigadores de seguridad de Snyk dedicaron el día del 30 de marzo a revisar la situación.

Por ahora, nuestra conclusión es que existe una amenaza creíble de RCE en el paquete spring-beans de Spring Core. Para bien o para mal, Spring4Shell es el nombre oficial. Tiene sentido, ya que en el ecosistema de Spring ya existe un proyecto legítimo llamado Spring Shell.

Seguiremos publicando novedades en nuestra base de datos de vulnerabilidades a medida que evolucione la situación.

Mitigación de Spring4Shell

Se publicaron nuevas versiones de Spring Framework en las que el exploit actual no funciona. Son las versiones 5.2.20 y 5.3.18. Y, si trabajas con Spring Boot, hoy mismo se publicaron las versiones 2.5.12 y 2.6.6, que integran los cambios en Spring Framework y spring-beans.

Aquí tienes una lista de medidas de mitigación que puedes tomar, en orden de preferencia:

• Si usas Spring Framework directamente, actualiza a la versión 5.2.20 o 5.3.18

• Si usas Spring Boot, utiliza la versión 2.15.12 o 2.6.6

• Si no puedes actualizar tu versión de Spring por ahora, utiliza la versión 8 del JRE o un contenedor de Tomcat para mitigar el problema

Vale la pena tener en cuenta que es probable que haya más actualizaciones de Spring a medida que se descubran más vulnerabilidades (y posiblemente otras distintas). Esta suele ser la tendencia cuando se presta mucha atención a un problema de gravedad alta como este (¿alguien dijo Log4Shell?).

¡Las herramientas de Snyk ya se actualizaron para avisarte si tu proyecto es vulnerable!

Visita Snyk para crear una cuenta gratis. Desde allí (o en la línea de comandos), puedes analizar tu proyecto para saber si es vulnerable a Spring4Shell.

Esperamos actualizar esta publicación y crear un repositorio de código PoC para demostrar la RCE en las versiones 9 y posteriores del JRE y Tomcat. Vuelve aquí para ver las novedades.

Cómo surgió la confusión inicial en torno a Spring4Shell

Una de las primeras publicaciones de blog sobre las que alertaron a nuestro equipo en las primeras horas del 30 de marzo ya fue eliminada. La publicación hacía referencia a un tuit que también fue eliminado. A pesar de que ambos se eliminaron, había una referencia verificable a un commit relacionado con Spring Core y la deserialización (una función de Java que ya ha provocado RCE, como Log4Shell, ¿recuerdas?).

El comentario en este commit dice:

1Since SerializationUtils#deserialize is based on Java's serialization
2mechanism, it can be the source of Remote Code Execution (RCE)
3vulnerabilities.

A medida que avanzaba el día, aumentaban los rumores (con muy pocos hechos verificables que los respaldaran) de que quizá se trataba de una RCE en Spring Core.

Más adelante en los comentarios, una persona encargada de mantener Spring Core confirmó otro comentario que afirmaba que este commit no tenía nada que ver con ninguna RCE conocida.

De hecho, si revisas el PR que resuelve el commit, verás que se abrió por primera vez el 18 de febrero.

En resumen: mientras todo esto ocurría, la gente en Internet confundía este problema en evolución con otro problema conocido en un proyecto completamente distinto: Spring Cloud Function. Para no aumentar la confusión, no entraré en los detalles de esta vulnerabilidad. Basta con decir que, si estás leyendo algo sobre vulnerabilidades en Spring Cloud, estás buscando información sobre Spring4Shell en el lugar equivocado (por favor, ¿podemos darle otro nombre?).

En resumen

Protégete de Spring4Shell siguiendo las medidas de mitigación recomendadas anteriormente. Puedes crear una cuenta gratis de Snyk para empezar a corregir el problema.