Hace poco se dio a conocer la noticia de que fue detectada una vulnerabilidad crítica del tipo zero day en el módulo Spring Core enviado como parte de Spring Framework, que permite a un atacante remoto no autenticado ejecutar su código en el servidor.
Según algunas estimaciones, el módulo Spring Core se utiliza en el 74 % de las aplicaciones Java. El peligro de la vulnerabilidad se reduce por el hecho de que solo las aplicaciones que utilizan la anotación «@RequestMapping» al conectar los controladores de solicitudes y utilizan el enlace de parámetros de formulario web en el formato «nombre=valor» (POJO, Plain Old Java Object), en lugar de JSON/XML, son susceptibles al ataque. Todavía no está claro qué aplicaciones y marcos de Java se ven afectados por el problema.
Esta vulnerabilidad, denominada «Spring4Shell», aprovecha la inyección de clase que conduce a un RCE completo y es muy grave. Se eligió el nombre «Spring4Shell» porque Spring Core es una biblioteca ubicua, similar a log4j que generó la infame vulnerabilidad Log4Shell .
Creemos que los usuarios que ejecutan JDK versión 9 y posteriores son vulnerables a un ataque RCE. Todas las versiones de Spring Core se ven afectadas.
Existen estrategias para mitigar el ataque y creemos que no todos los servidores Spring son necesariamente vulnerables, dependiendo de otros factores que se analizan a continuación . Dicho esto, actualmente recomendamos que todos los usuarios apliquen mitigaciones o actualicen si están usando Spring Core.
La explotación de la vulnerabilidad solo es posible cuando se utiliza Java/JDK 9 o una versión más reciente. La vulnerabilidad bloquea la inclusión en la lista negra de los campos «clase», «módulo» y «classLoader» o el uso de una lista blanca explícita de campos permitidos.
El problema se debe a la capacidad de eludir la protección contra la vulnerabilidad CVE-2010-1622, corregida en Spring Framework en 2010 y asociada con la ejecución del controlador classLoader al analizar los parámetros de la solicitud.
El funcionamiento del exploit se reduce a enviar una solicitud con los parámetros «class.module.classLoader.resources.context.parent.pipeline.first.*», cuyo procesamiento, al usar » WebappClassLoaderBase «, conduce a una llamada a la clase AccessLogValve.
La clase especificada le permite configurar el registrador para crear un archivo jsp arbitrario en el entorno raíz de Apache Tomcat y escribir el código especificado por el atacante en este archivo. El archivo creado está disponible para solicitudes directas y se puede usar como shell web. Para atacar una aplicación vulnerable en el entorno de Apache Tomcat, basta con enviar una solicitud con ciertos parámetros utilizando la utilidad curl.
El problema bajo consideración en Spring Core no debe confundirse con las vulnerabilidades recientemente identificadas CVE-2022-22963 y CVE-2022-22950. El primer problema afecta al paquete Spring Cloud y también permite lograr la ejecución remota de código (exploit). CVE-2022-22963 se corrigió en las versiones Spring Cloud 3.1.7 y 3.2.3.
El segundo problema CVE-2022-22950 está presente en Spring Expression, se puede usar para lanzar ataques DoS y se corrige en Spring Framework 5.3.17. Estas son vulnerabilidades fundamentalmente diferentes. Los desarrolladores de Spring Framework aún no han hecho ninguna declaración sobre la nueva vulnerabilidad y no han publicado una solución.
Como medida de protección temporal, se recomienda utilizar una lista negra de parámetros de consulta no válidos en su código.
Todavía no está claro cuán catastróficas pueden ser las consecuencias del problema identificado y si los ataques serán tan masivos como en el caso de la vulnerabilidad en Log4j 2. La vulnerabilidad recibió el nombre en clave Spring4Shell, CVE-2022-22965 y se lanzaron las actualizaciones Spring Framework 5.3.18 y 5.2.20 para abordar la vulnerabilidad.
Un parche ahora está disponible a partir del 31 de marzo de 2022 en las versiones de Spring más recientes publicadas 5.3.18 y 5.2.20 . Recomendamos a todos los usuarios actualizar. Para aquellos que no pueden actualizar, las siguientes mitigaciones son posibles:
Según la publicación de Praetorian que confirma la presencia de un RCE en Spring Core, el enfoque recomendado actualmente es parchear DataBinderagregando una lista negra de patrones de campo vulnerables necesarios para la explotación.
Finalmente si estás interesado en poder conocer más al respecto sobre la nota, puedes consultar los detalles en el siguiente enlace.