Spring4Shell explicado: el desastre de seguridad de Internet que no fue

imágenes falsas

El bombo y el bombo estaban en plena vigencia esta semana cuando el mundo de la seguridad reaccionó a los informes de otro Log4Shell. La vulnerabilidad se conoció en diciembre y es probablemente una de las amenazas de Internet más graves en años. Apodado Spring4Shell, el nuevo error de ejecución de código en el marco Java ampliamente utilizado de Spring rápidamente prendió fuego al mundo de la seguridad mientras los investigadores luchaban por evaluar su gravedad.

Una de las primeras publicaciones en informar sobre el error fue el sitio de noticias tecnológicas Cyber ​​​​Kendra, que advirtió sobre el daño grave que el error podría causar a «toneladas de aplicaciones» y «arruinar Internet». Casi de inmediato, las empresas de seguridad, muchas de ellas bombeando aceite de serpiente, se apresuraron a advertir sobre el peligro inminente que todos enfrentaríamos. Y todo esto antes de que los mantenedores de Spring dispusieran de una designación o aviso de seguimiento de vulnerabilidades.

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 residía en un marco que admite una gran cantidad de sitios web y aplicaciones.

La vulnerabilidad existe en dos productos Spring: Spring MVC y Spring WebFlux, que permiten a los desarrolladores escribir y probar aplicaciones. El error es el resultado de los cambios introducidos en JDK9 que resucitaron una vulnerabilidad de hace décadas rastreada como CVE-2010-1622. Dada la plétora de sistemas que combinan Spring Framework y JDK9 o superior, no era de extrañar que la gente estuviera preocupada, especialmente porque el código de explotación ya estaba en la naturaleza (el primer filtrador cerró rápidamente el PoC, pero llegó demasiado tarde).

Finalmente, el jueves, el error se denominó CVE-2022-22965. A los defensores de la seguridad también se les dio una descripción mucho más matizada de la amenaza que representaban. El código filtrado, dijeron los mantenedores de Spring, se ejecutó solo cuando una aplicación desarrollada por Spring se ejecutó en Apache Tomcat, y luego solo cuando la aplicación se implementó como un tipo de archivo conocido como WAR, abreviatura de archivo web.

«Si la aplicación se implementa como un archivo JAR ejecutable de Spring Boot, es decir, de forma predeterminada, 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 pudiera mejorarse para funcionar con otras configuraciones, nadie ha detectado una variante que lo haga, al menos hasta ahora.

“Es una cosa que los desarrolladores deben corregir cuando usan una versión afectada”, dijo Will Dormann, analista de vulnerabilidades de CERT, en un mensaje privado. «Pero todavía estamos en el bote ya que no hay una sola aplicación que pueda ser explotada».

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

«Cómo Cyber ​​​​Kendra lo empeoró para todos», dijo. escribió. «1) Publicación de blog sensacional que sugiere que esto arruinará Internet (¡bandera roja!) 2) Enlace a un compromiso de Git sobre deserialización que no tiene absolutamente nada que ver con el problema señalado por la parte original».

Un representante de Cyber ​​​​Kendra no respondió a un correo electrónico solicitando comentarios. Para ser justos, la línea sobre la destrucción de Internet se tachó más tarde.

concha de primavera, no Spring4Shell

Desafortunadamente, si bien el consenso es que la vulnerabilidad no se acerca a la amenaza que representa Log4Shell, al menos por ahora, el nombre Spring4Shell se ha mantenido en gran medida. Eso probablemente inducirá a error a algunos en cuanto a su gravedad. En el futuro, Ars se referirá a él con su nombre más adecuado, SpringShell.

Varios investigadores dicen que han descubierto escaneos en la naturaleza que usan el PoC CVE-2022-22965 filtrado o un exploit muy similar. No es raro que los investigadores prueben benévolamente los servidores para comprender qué tan frecuente es una nueva vulnerabilidad. Un poco más preocupante es un informe del viernes en el que los investigadores de Netlab 360 dijeron que una variante de Mirai, un malware que puede apuntar a miles de dispositivos IoT y generar ataques devastadores de denegación de servicio, «ganó la carrera para ser el primer botnet». tiene que ha asumido esta vulnerabilidad.

Para confundir aún más las cosas, la semana pasada surgió una vulnerabilidad de ejecución de código separada que afecta la función Spring Cloud que permite a los desarrolladores desacoplar fácilmente la lógica comercial en una aplicación de un tiempo de ejecución específico. El error rastreado como CVE-2022-22963 reside en Spring Expression Language, comúnmente conocido como SpEL.

Ambas vulnerabilidades son potencialmente graves y no deben ignorarse. Eso significa actualizar Spring Framework a 5.3.18 o 5.2.20 y también actualizar a Tomcat 10.0.20, 9.0.62 o 8.5.78 como medida de precaución. Aquellos que usan la función Spring Cloud deben actualizar a 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 firma de seguridad Randori tienen una solución simple: guión no malicioso puede hacer precisamente eso.

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



DEJA UNA RESPUESTA

Por favor ingrese su comentario!
Por favor ingrese su nombre aquí