Fue aclamado brevemente como el próximo Log4Shell, un grave día cero en un marco ampliamente utilizado que sustenta miles de aplicaciones, pero poco más de una semana después de que se revelara la vulnerabilidad Spring4Shell Remote Code Execution (RCE) en Spring Framework, prácticamente no existe. evidencia de un impacto significativo en los usuarios.
Spring4Shell, también conocido por algunos como SpringShell y ahora rastreado como CVE-2022-22965, pasa por alto una vulnerabilidad previamente conocida rastreada como CVE-2010-1622 y afecta a cualquier aplicación que se ejecute en el elemento de registro Spring Core de Spring, el marco basado en el más popular. allí. Cuando se explota, en última instancia, permite que un actor no autenticado ejecute código arbitrario en el sistema de destino. Hasta ahora RCE; Más detalles se pueden encontrar aquí.
El asunto no se vio favorecido por la divulgación simultánea de una vulnerabilidad separada en Spring, que desafortunadamente se vinculó a Spring4Shell, lo que causó una confusión generalizada y llevó a más de un autoproclamado experto en seguridad que leyó algo mal a gritar «noticias falsas». .
Tim Mackey, estratega senior de seguridad en el Centro de Investigación de Seguridad Cibernética (CyRC) de Synopsys, dijo que esta confusión habla de un problema con la forma en que los piratas informáticos e investigadores éticos se comunican y divulgan sus descubrimientos.
Incluso cuando los investigadores hacen divulgaciones con las mejores intenciones, la divulgación es un proceso delicado y puede malinterpretarse fácilmente cuando solo una persona está motivada para atraer a los lectores a un blog o escribir un tweet viral.
«Hay una serie de razones para la divulgación responsable, pero una de las más importantes es garantizar que la información precisa y procesable llegue a manos de aquellos que necesitan abordar un problema con prontitud y precisión», dijo Mackey.
«La confusión que los equipos han experimentado con Spring4Shell no tenía por qué haber ocurrido y probablemente se habría evitado si no se hubiera filtrado información sobre Spring4Shell y no hubiera habido una vulnerabilidad independiente en otro componente que lleva el nombre de Spring».
No es fácil de explotar
Una cosa es segura. Spring4Shell no es una noticia falsa. Y según Martin Jartelius, director de seguridad de Outpost24, es «tan fundamental para todos los afectados» como Log4Shell.
Si bien la criticidad de una vulnerabilidad es algo subjetiva y aumenta cuanto más se es víctima de ella, como continúa explicando Jartelius, rápidamente se hizo evidente que no se cumplían los requisitos previos para explotar Spring4Shell como tal.
«Esta vulnerabilidad atrajo mucho interés porque era algo similar a Log4j en el sentido de que compartía las características de una biblioteca popular y se usaba en entornos similares con impactos similares», dijo. «La única diferencia eran los requisitos, y esa diferencia era enorme».
Shachar Menashe, director sénior de investigación de seguridad de JFrog, explicó estos términos en una publicación de blog. En el nivel más alto, una aplicación es vulnerable si se basa en Spring Framework, se ejecuta en JDK9 o posterior, o utiliza el enlace de datos para vincular los parámetros de solicitud a un objeto Java (esto se debe a que la vulnerabilidad está en el mecanismo de enlace de datos de Spring).
Además, dijo Menashe, gracias al vector de explotación específico elegido por el exploit de prueba de concepto (sobrescritura arbitraria de archivos por AccessLogValve), Spring4Shell tiene dos requisitos adicionales, a saber, que la aplicación web de Apace sirve y se ejecuta en Tomcat Tomcat debe proporcionarse como un recurso para aplicaciones web.
En otras palabras, las condiciones especiales que deben cumplirse para poder explotar Spring4Shell son bastante más complicadas que las que se requieren para explotar Log4Shell. aunque Spring4Shell se usa ampliamente de manera similar gracias a la popularidad del marco Spring menos posible ser explotado por el momento.
Resaca Log4Shell
Eduardo Ocete Entrala, investigador de seguridad de AT&T Alien Labs, dijo que al menos parte de la respuesta de Spring4Shell se debió a la respuesta de Log4Shell de diciembre de 2021.
“Las vulnerabilidades en el marco Java Spring han generado una reacción general en la comunidad de seguridad de software debido a su parecido con Log4Shell, que es una vulnerabilidad realmente crítica e impactante”, dijo. «Además, el uso generalizado del marco Spring también significó que la cantidad de sistemas que podrían verse afectados por la vulnerabilidad es grande».
Jartelius dijo: «Una vulnerabilidad crítica, difícil de identificar, que puede existir en sus aplicaciones y redes durante años, esperando que un atacante use la carga útil correcta, nunca es un gran alboroto, pero el pánico generado fue claramente desproporcionado.
“Es probable que sigamos viendo este tipo de sensacionalismo periodístico o de proveedores, y el mejor consejo para las organizaciones sigue siendo practicar una buena higiene cibernética a través de evaluaciones de seguridad periódicas para medir y reducir la superficie de ataque externa”, dijo.
no seas complaciente
Esto habla de una necesidad más amplia de las organizaciones y sus líderes de TI y equipos de seguridad para interactuar adecuadamente con las diversas herramientas y componentes utilizados en el inventario de TI, ya que cualquier cantidad de dependencias o vulnerabilidades pueden acechar debajo del capó.
Pascal Geenens, Director de Threat Intelligence en Radware, dijo: “SpringShell debería recordarles a todos que evalúen las buenas prácticas de higiene. Como comunidad, nos hemos sentido demasiado cómodos adoptando bibliotecas y módulos grandes y complejos y nos hemos olvidado de centrarnos en las dependencias entre módulos.
“Las organizaciones necesitan reducir sus bibliotecas y limitar las dependencias de módulos y códigos que no son relevantes para la aplicación; Sea más cuidadoso y crítico con lo que revelamos. y asegúrese de que estamos ejecutando las últimas versiones. Los atacantes no dejan piedra sin remover”.
Cuestiona tus fuentes
La saga Spring4Shell también es una advertencia para no caer en el miedo, la incertidumbre y la duda, y un recordatorio para todos en la comunidad de seguridad, ya sea director de seguridad de la información, investigador, hacker ético o periodista, para interrogar la nueva información de manera responsable.
“Todo esto nos lleva a la realidad de TI”, dijo Mackey de Synopsys: “¡Una estrategia de administración de parches que está influenciada por la cobertura de los medios no es un proceso eficiente!
“Los equipos que tenían una solución de análisis de composición de software (SCA) configurada para alertarlos de manera proactiva sobre nuevas vulnerabilidades que afectaban sus operaciones sabían qué sistemas se vieron afectados a las pocas horas del lanzamiento de CVE y qué acciones correctivas se requerían.
«En el caso de Spring4Shell, mejor conocido como CVE-2022-22965, los esfuerzos de marca distrajeron la atención de la tarea real y la confusión sobre cuál era el componente vulnerable no ayudó», dijo.
Aún así, Mackey dijo que es probable que el alcance del código afectado aumente a medida que se obtenga más conocimiento, Mackey dice que sería muy bueno si evalúa la vulnerabilidad en lugar de corregirla justo después del tiempo de este artículo, después de buscar actualizaciones.
En resumen, tenga cuidado, pero no tenga pesadillas.
