Explicando Spring4Shell: El desastre de seguridad en Internet que no fue

La exageración y la hipérbole estuvieron a la vista esta semana cuando el mundo de la seguridad reaccionó a los informes de otro Log4Shell. La vulnerabilidad salió a la luz en diciembre y podría decirse que es una de las amenazas de Internet más graves en años. Bautizado como Spring4Shell, el nuevo error de ejecución de código en el ampliamente utilizado marco Spring Java, incendió rápidamente el mundo de la seguridad mientras los investigadores se apresuraban a evaluar su gravedad.

Uno de los primeras publicaciones para informar sobre la falla fue el sitio de noticias tecnológicas Cyber ​​Kendra, que advirtió sobre el daño severo que la falla podría causar a “toneladas de aplicaciones” y “puede arruinar Internet”. Casi de inmediato, las empresas de seguridad, muchas de ellas empujando el aceite de serpiente, se volcaron para advertir sobre el peligro inminente que todos enfrentaríamos. Y todo eso antes de que estuviera disponible una designación de seguimiento de vulnerabilidades o un aviso de los mantenedores de Spring.

Todos a bordo

El tren de exageraciones comenzó el miércoles después de que un investigador publicara un exploit de prueba de concepto que podría instalar de forma remota una puerta trasera de control remoto basada en la web conocida como shell web en un sistema vulnerable. La gente estaba comprensiblemente preocupada porque la vulnerabilidad era muy fácil de explotar y estaba en un marco que impulsa una gran cantidad de sitios web y aplicaciones.

La vulnerabilidad reside en dos productos Spring: Spring MVC y Spring WebFlux, que permiten a los desarrolladores escribir y probar aplicaciones. La falla es el resultado de los cambios introducidos en JDK9 que resucitaron una vulnerabilidad de hace una década rastreada como CVE-2010-1622. Dada la abundancia de sistemas que combinan Spring Framework y JDK9 o posterior, no es de extrañar que la gente estuviera preocupada, especialmente porque el código de explotación ya estaba disponible (el filtrador inicial eliminó rápidamente el PoC, pero para entonces ya era demasiado tarde).

El jueves, la falla finalmente recibió la designación CVE-2022-22965. Los defensores de la seguridad también obtuvieron una descripción mucho más matizada de la amenaza que representaba. El código filtrado, Los mantenedores de primavera dijeronse ejecutaba solo cuando una aplicación desarrollada por Spring se ejecutaba sobre Apache Tomcat y solo cuando la aplicación se implementaba como un tipo de archivo conocido como GUERRAabreviatura de archivo web.

“Si la aplicación se implementa como un archivo ejecutable de Spring Boot, es decir, el valor predeterminado, no es vulnerable al exploit”, escribieron los mantenedores de Spring. “Sin embargo, la naturaleza de la vulnerabilidad es más general y puede haber otras formas de explotarla”.

Si bien la publicación dejó abierta la posibilidad de que el exploit PoC se pueda mejorar para que funcione con otras configuraciones, nadie ha descubierto una variación que lo haga, al menos por ahora.

“Es algo que los desarrolladores deberían arreglar, si están usando una versión afectada”, dijo Will Dormann, analista de vulnerabilidades del CERT, en un mensaje privado. “Pero todavía estamos en el bote de no saber de una sola aplicación que sea explotable”.

En Twitter, Dormann criticó a Cyber ​​Kendra.

“Las formas en que Cyber ​​Kendra empeoró esto para todos”, dijo. escribió. “1) Publicación de blog sensacional que indica que esto va a arruinar Internet (¡bandera roja!) 2) Enlace a un compromiso de git sobre deserialización que no tiene absolutamente nada que ver con el problema demostrado por la parte original”.

Un representante de Cyber ​​Kendra no respondió a un correo electrónico en busca de comentarios. Para ser justos, la línea sobre arruinar Internet fue tachada más tarde.

concha de primavera, no Spring4Shell

Lamentablemente, a pesar de que existe consenso de que, al menos por ahora, la vulnerabilidad no representa nada parecido a la amenaza de Log4Shell, el nombre Spring4Shell se ha mantenido en gran medida. Eso probablemente inducirá a error a algunos sobre su gravedad. En el futuro, Ars se referirá a él por su nombre más apropiado, SpringShell.

Varios investigadores dicen que han detectado escaneos en la naturaleza que usan el PoC CVE-2022-22965 filtrado o un exploit muy parecido. No es inusual que los investigadores prueben benignamente los servidores para comprender qué tan frecuente es una nueva vulnerabilidad. Un poco más preocupante es un informe el viernes en el que los investigadores de Netlab 360 dijeron que una variante de Mirai, un malware que puede manipular miles de dispositivos IoT y producir ataques de denegación de servicio paralizantes, “ha ganado la carrera como la primera botnet que adoptó esta vulnerabilidad”.

Para hacer las cosas más confusas, la semana pasada apareció una vulnerabilidad de ejecución de código separada que afecta a Spring Cloud Function, que permite a los desarrolladores separar fácilmente la lógica comercial en una aplicación de un tiempo de ejecución específico. La falla, rastreada como CVE-2022-22963, reside en Spring Expression Language, generalmente conocido como SpEL.

Ambas vulnerabilidades son potencialmente graves y de ninguna manera deben ignorarse. Eso significa actualizar Spring Framework a 5.3.18 o 5.2.20 y, por precaución, también actualizar a Tomcat 10.0.20, 9.0.62 o 8.5.78. Aquellos que usan la función Spring Cloud deben actualizar a cualquiera 3.1.7 o 3.2.3.

Para las personas que no están seguras de si sus aplicaciones son vulnerables a CVE-2022-22965, los investigadores de la empresa de seguridad Randori han publicado un sencillo, guión no malicioso que puede hacer precisamente eso.

Así que, por todos los medios, prueba y parchea como si no hubiera un mañana, pero no creas en las exageraciones.