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 la divulgación de la vulnerabilidad de ejecución remota de código (RCE) Spring4Shell en Spring Framework, hay prácticamente no hay evidencia de ningún 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 cualquier aplicación creada en el elemento de registro Spring Core de Spring, uno de los más populares. marcos por ahí. Si 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 están disponibles aquí.
Las cosas no mejoraron con la divulgación simultánea de una vulnerabilidad separada en Spring, con la que Spring4Shell lamentablemente se combinó, lo que generó una confusión generalizada y llevó a más de un autoproclamado experto en seguridad que no había leído algo correctamente a gritar “noticias falsas”. .
Tim Mackey, estratega principal 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 hackers e investigadores éticos comunican y divulgan sus descubrimientos.
Aunque los investigadores divulgan con la mejor de las intenciones, la divulgación es un proceso tenso y puede malinterpretarse fácilmente si solo una persona está motivada para sensacionalizar para atraer lectores a un blog o escribir un tweet viral.
“La divulgación responsable existe por varias razones, pero una de las más importantes es garantizar que la información concisa y procesable esté en manos de aquellos que necesitan abordar un problema de manera rápida y precisa”, dijo Mackey.
“La confusión que experimentaron los equipos con Spring4Shell no tenía por qué ocurrir, y probablemente se habría evitado si no se hubiera filtrado información sobre Spring4Shell y no hubiera habido una vulnerabilidad independiente en un componente diferente que comparte el nombre de Spring”.
No es fácil de explotar
Una cosa es segura. Spring4Shell no es una noticia falsa. Y según el director de seguridad de Outpost24, Martin Jartelius, es tan crítico como Log4Shell “para cualquiera que se vea afectado por él”.
Es cierto que la criticidad de una vulnerabilidad es algo subjetiva y aumenta si eres víctima de ella, pero como continúa explicando Jartelius, rápidamente se ha hecho evidente que las condiciones previas para explotar Spring4Shell no fueron creadas iguales, como tales.
“Esta vulnerabilidad ha despertado un gran interés porque era algo similar a Log4j, ya que compartía las características de ser una biblioteca popular y se usaba en entornos similares con un impacto similar”, dijo. “La única diferencia fueron las condiciones previas, y esa diferencia fue enorme”.
El director sénior de investigación de seguridad de JFrog, Shachar Menashe, explicó estas condiciones en una publicación de blog. En el nivel más alto, una aplicación es vulnerable si se crea 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 a través de AccessLogValve), Spring4Shell impone dos requisitos adicionales, a saber, que la aplicación web debe ser atendida por Apace Tomcat y que debe implementarse en Tomcat como un recurso de aplicación web.
En otras palabras, el conjunto particular de condiciones que deben cumplirse para que se explote Spring4Shell es bastante más complicado que las que se requieren para aprovechar Log4Shell, por lo que aunque Spring4Shell está igualmente extendido gracias a la popularidad del marco Spring, es menos probable para ser explotado por ahora.
Resaca Log4Shell
Eduardo Ocete Entrala, investigador de seguridad de AT&T Alien Labs, dijo que al menos parte de la reacción a Spring4Shell se deriva de la reacción a Log4Shell en diciembre de 2021.
“Las vulnerabilidades en el marco Java Spring han causado una reacción generalizada en la comunidad de seguridad del software debido a su similitud con Log4Shell, que fue 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 residir durante años en sus aplicaciones y redes esperando que un atacante use la carga útil correcta nunca se preocupa por nada, pero el pánico creado fue claramente desproporcionado.
“Es probable que sigamos viendo este tipo de sensacionalismo periodístico o de proveedores, y el mejor consejo para las empresas sigue siendo practicar una buena higiene cibernética a través de una evaluación de seguridad regular para medir y reducir la superficie de ataque externa”, dijo.
no seas complaciente
Esto habla de una necesidad más amplia entre las organizaciones, y sus líderes de TI y equipos de seguridad, para familiarizarse adecuadamente con las diversas herramientas y componentes que se utilizan en el estado de TI, ya que puede haber una gran cantidad de dependencias o vulnerabilidades al acecho. capó.
El director de inteligencia de amenazas de Radware, Pascal Geenens, dijo: “SpringShell debería ser un recordatorio para que todos hagan un balance de las buenas prácticas de higiene. Como comunidad, nos hemos sentido demasiado cómodos con bibliotecas y módulos grandes y complejos y nos hemos olvidado de centrarnos en las dependencias entre módulos.
“Las organizaciones deben reducir sus bibliotecas y limitar las dependencias de los módulos y el código que no son relevantes para la aplicación; ser más cuidadosos y perspicaces con lo que estamos exponiendo; y asegúrese de que estamos ejecutando las versiones más recientes. Los atacantes no dejan piedra sin remover”.
Interroga a tus fuentes
La saga Spring4Shell también se presenta como una advertencia para tener cuidado de no caer en el miedo, la incertidumbre y la duda, y un recordatorio para todos en la comunidad de seguridad, ya sea un director de seguridad de la información, un investigador, un hacker ético o un periodista, para cuestionar nueva información. responsablemente
“Todo esto nos lleva a una realidad dentro 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, o SCA, que estaba configurada para alertar de manera proactiva sobre nuevas vulnerabilidades que afectaban sus operaciones sabían a las pocas horas de la publicación del CVE qué sistemas se vieron afectados y qué acción correctiva se requería.
“En el caso de Spring4Shell, más apropiadamente conocido como CVE-2022-22965, el esfuerzo de marca distrajo de la tarea en cuestión y la confusión en torno a cuál era el componente vulnerable no ayudó”, dijo.
Aun así, dijo Mackey, al igual que con muchas vulnerabilidades de alto perfil, es probable que el alcance del código afectado crezca a medida que se obtenga más conocimiento, por lo que si evaluó la vulnerabilidad en lugar de remediarla, inmediatamente después de terminar este artículo sería una muy buena tiempo para comprobar si hay actualizaciones.
En resumen, tenga cuidado, pero no tenga pesadillas.