Spring4Shell (CVE-2022-22965): vulnerabilidad crítica en Spring

Inicialmente, el 30 de marzo, se "insinuó" la primera notificación de una vulnerabilidad por el líder del equipo KnownSec 404, Heige.

El investigador twitteó un mensaje de advertencia "Spring core RCE（JDK >=9" junto con la imagen de una PoC.

Actualización: Esta vulnerabilidad está siendo explotada activamente en Internet. Ahora puede probar la explotación integral de Spring4Shell con esta "aplicación vulnerable y explotación de PoC" de GitHub.

Después de circular la noticia sobre la vulnerabilidad de ejecución remota de código (RCE) sin parches en Spring Framework, todos comenzaron a apresurarse para conseguir el código de explotación y la PoC. Finalmente se confirmó una vulnerabilidad Zero-Day en el módulo Spring Core de Spring Framework. Spring es mantenido por Spring.io (una subsidiaria de VMWare) y es utilizado por muchos marcos de software empresarial basados en Java.

Una vez filtrado la PoC con el exploit se ha visto mucha discusión y confusión relacionada con esta vulnerabilidad porque en realidad hay otras tres vulnerabilidades reveladas para el proyecto Spring y que no están relacionadas con Spring4Shell (CVE-2022-22965 - CERT KB #970766).

• RCE menos grave en en Spring Cloud Function (<=3.1.6 and <=3.2.2), identificado como CVE-2022-22963 y publicada el 29 de marzo. Ya hay exploit PoC, otra, otra.
• Una vulnerabilidad de gravedad media (que puede causar una condición DoS) afecta a las versiones de Spring Framework 5.3.0 a 5.3.16, CVE-2022-22950.
• Vulnerabilidad de Escalamiento de Privilegios Local (LPE) identificada como CVE-2022-27772 y lanzada el 23 de marzo.

Finalmente, "Spring4Shell" o RCE en Spring Core ha sido confirmado por varias fuentes. Es una vulnerabilidad crítica que permite que un atacante no autenticado ejecute código arbitrario en el sistema de destino. Esta es una vulnerabilidad sucesora y similar a CVE-2010-1622. Y al igual que ya se hizo hace unos años con Struts la PoC publicada se basa en abusar del ClassLoader que usa Tomcat. El exploit funciona modificando los ajustes de configuración de Tomcat (a través de AccessLogValve); más específicamente, cambia el esquema de nombres de los archivos de log y la ubicación donde se almacenan los mismos para llevarlos al document root.

Los usuarios que ejecutan JDK versión 9 y posteriores son vulnerables a un ataque de Ejecución Remota de Código (RCE), debido a una omisión de CVE-2010-1622. Todas las versiones de Spring Core están afectadas por Spring4Shell y todavía no se ha publicado el parche. La vulnerabilidad parece afectar a las funciones que utilizan la anotación RequestMapping y los parámetros POJO (Plain Old Java Object).

Estos son los requisitos y los escenarios posibles:

• JDK 9 o superior
• Apache Tomcat como contenedor de Servlet.
• Empaquetado como un WAR tradicional (en contraste con un JAR ejecutable de Spring Boot).
• Dependencia spring-webmvc o spring-webflux.
• Spring Framework versiones 5.3.0 a 5.3.17, 5.2.0 a 5.2.19 y versiones anteriores.

La vulnerabilidad afecta a las aplicaciones Spring MVC y Spring WebFlux que se ejecutan en JDK 9+. El exploit específico requiere que la aplicación se ejecute en Tomcat como una implementación WAR. Si la aplicación se implementa como un JAR ejecutable de Spring Boot, es decir, el valor predeterminado, no es vulnerable al exploit. Sin embargo, la naturaleza de la vulnerabilidad es más general y puede haber otras formas de explotarla.

En ciertas configuraciones, la explotación de este problema es sencilla, ya que solo requiere que un atacante envíe una solicitud HTTP manipulada a un sistema vulnerable. Sin embargo, la explotación de diferentes configuraciones requerirá que el atacante realice una investigación adicional para encontrar cargas útiles que sean efectivas.

Inicialmente, Praetorian confirma la presencia de un RCE en Spring Core, el enfoque recomendado actualmente es parchear DataBinder agregando una lista negra de patrones de campo vulnerables necesarios para la explotación. Después de esto, el equipo de Rapid7 también confirmó la vulnerabilidad Zero-Day Spring4Shell y proporcionó una ejecución remota de código no autenticado.

¿Este es un nuevo Log4Shell?

Spring es un marco de aplicación muy popular para aplicaciones Java, lo que genera preocupaciones importantes de que esto pueda conducir a ataques generalizados a medida que los actores de amenazas buscan aplicaciones vulnerables.

Dado que la explotación requiere un HTTP POST simple para una aplicación vulnerable, los actores de amenazas podrían crear scripts que escanean Internet y explotan automáticamente los servidores vulnerables. Los actores de amenazas pueden usar estos exploits para ejecutar comandos en el servidor, lo que permitirá el acceso remoto completo al dispositivo. Debido a los requisitos para explotar este error, es demasiado pronto para saber cuántas aplicaciones son vulnerables.

Este escenario de ataque recuerda lo que vimos en diciembre con la explotación masiva de los servidores Log4j utilizando los exploits Log4Shell para instalar malware y realizar ataques de ransomware. 

Mitigación o solución

Si se puede actualizar a Spring Framework 5.3.18 y 5.2.20, no se necesitan otras soluciones alternativas. Realizar un downgrade a Java 8 proporciona una solución alternativa viable, que puede ser algo rápido y sencillo como solución táctica, hasta que pueda actualizar a una versión compatible de Spring Framework.

En última instancia, para evitar que los escenarios de ataque se hagan realidad, se recomienda encarecidamente que el administrador aplique las mitigaciones proporcionadas por Praetorian lo antes posible si cree que sus aplicaciones son vulnerables.

Para versiones anteriores de Spring Framework no compatibles, la actualización a Apache Tomcat 10.0.20, 9.0.62 o 8.5.78 brinda protección contra el vector de ataque informado. Estas versiones cierran el vector de ataque en el lado de Tomcat. Se puede consultas Spring Framework RCE para ver alternativas de mitigación.

También se han publicado reglas YARA para la detección de Spring4Shell. Will Dorman también ha publicado un método alternativo con CURL.

El desarrollador hillu ha publicado un proyecto que ayuda a los usuarios a buscar aplicaciones que contengan bibliotecas Spring vulnerables.

Fuente: Praetorian | CyberKendra | Spring | LunaSec | SonaType

Suscríbete a nuestro Boletín