Bug RCE en Spring Framework
Mientras que los defensores todavía se tambalean por la vulnerabilidad de Log4j, a finales de marzo, se encontró una vulnerabilidad de alta gravedad de ejecución remota de código en el Spring Core Java Framework, un marco popular para la construcción de aplicaciones web Java modernas. El exploit específico se dirige a Java 9+ y especialmente a aquellos que utilizan TomCat como despliegue WAR.
La vulnerabilidad permite a un atacante no autorizado y no autenticado ejecutar código arbitrario en un sistema objetivo. Mientras que ciertas configuraciones son fáciles de explotar, otras configuraciones requerirán algunos esfuerzos En cualquier escenario, recomendamos la mitigación inmediata.
Descripción de la vulnerabilidad
Recientemente, Ridge Security descubrió una nueva vulnerabilidad RCE de 0 días en el Spring Framework. Un cambio introducido en Java 9 hace aproximadamente cinco años, combinado con el Spring Framework, puede dar lugar a aplicaciones vulnerables. En entornos JDK 9+, el atacante puede modificar el archivo de registro del middleware desplegando una carga útil maliciosa para la ejecución remota de código.
Debido a la gravedad crítica de esta vulnerabilidad, se recomienda que los usuarios de Spring Framework comprueben si están afectados por la vulnerabilidad, y tomen medidas de corrección inmediatas. RidgeBot 3.9.4 ha actualizado su biblioteca de plugins para incluir la detección y explotación de Spring4Shell.
Número de vulnerabilidad
CVE-2022-22965 (https://nvd.nist.gov/vuln/detail/CVE-2022-22965 )
Nivel de riesgo
Crítico
Versión afectada
Para la rama de Spring Framework 5.3, versión anterior a la 5.3.18
Para la rama de Spring Framework 5.2, versión anterior a la 5.2.20
Métodos de detección
Método #1 Comprobar manualmente
Comprobación de la versión del JDK
Ejecute el comando “java-version” para comprobar la versión del JDK. Si el número de versión del JDK es ≤8, no está afectado por esta vulnerabilidad.
Detección de Spring Framework
1. Si la aplicación se despliega en forma de archivo .war, siga los siguientes pasos:
Descomprima el archivo .war: cambie el sufijo del archivo .war por un archivo .zip;
Busque archivos con el formato spring-beans-*.jar (como spring-beans-5.3.16.jar) en el directorio descomprimido. Si existe, significa que la aplicación está desarrollada con Spring Framework;
Si los archivos spring-beans-*.jar no existen, busque el archivo CachedlntrospectionResults.class en el directorio descomprimido. Si existe, significa que la aplicación está desarrollada con Spring Framework.
2. Si la aplicación se ejecuta de forma independiente en forma de archivo .jar, detéctela siguiendo los siguientes pasos:
Descomprima el archivo .jar: cambie el sufijo del archivo .jar por zip y descomprima el archivo .zip;
Buscar la existencia de archivos jar con el formato spring-beans-*.jar (por ejemplo, spring-beans-5.3.16.jar) en el directorio descomprimido. Si existe, significa que la aplicación está desarrollada con Spring Framework;
Si los archivos spring-beans-*.jar no existen, busque el archivo CachedIntrospectionResults.class en el directorio descomprimido. Si existe, significa que el sistema empresarial está desarrollado con Spring Framework.
Detección adicional
Después de completar los dos pasos anteriores para la resolución de problemas, si se cumplen dos de las siguientes condiciones, entonces está afectado por esta vulnerabilidad:
Versión del JDK ≥ 9;
Se utiliza el Spring Framework o los frameworks derivados;
La interfaz web de la aplicación utiliza el objeto JavaBean.
Método #2 Comprobación automatizada con RidgeBot
Pruebas de penetración con RidgeBot
RidgeBot ha soportado la detección de vulnerabilidades de Spring Framework desde la versión 3.9.4. Los usuarios pueden realizar pruebas automatizadas sobre los sistemas de destino utilizando RidgeBot. RidgeBot informará si el spring4shell existe o no. La captura de pantalla 1 muestra las secuencias de ataque que RidgeBot lanzó para explotar la vulnerabilidad Spring4Shell; la captura de pantalla 2 muestra la evidencia real de que el objetivo ha sido comprometido por el exploit exitoso de RidgeBot.
Captura de pantalla 1: secuencia de ataque para probar la CVE-2022-22965
Captura de pantalla 2: Evidencia de CVE-2022-22965 Spring Framework RCE explotado
Correcciones recomendadas
Lanzamiento del parche oficial
Se ha publicado el parche oficial, y Spring puede actualizarse a la versión de seguridad 5.3.18 o 5.2.20 para su mitigación.
Protección WAF
En el dispositivo de protección de la red, añada reglas de filtrado para la cadena “class.module.*” basadas en el tráfico desplegado. Después de desplegar las reglas de filtrado, pruebe la operación comercial para evitar un impacto adicional.
Mitigación temporal
Además, siga estos dos pasos para la mitigación temporal si no puede actualizar la versión de Spring:
1. Busca la anotación @InitBinder globalmente en la aplicación para ver si el método dataBinder.setDisallowedFields es llamado en el cuerpo del método. Si se llama al método en el código, añada “class.module.*” a la lista negra original.
Nota: Si este fragmento de código se utiliza con frecuencia, es necesario añadirlo en todas partes.
2. Cree la siguiente clase global en el paquete del proyecto del sistema de aplicación, y asegúrese de que esta clase sea cargada por Spring (se recomienda añadirla en el paquete donde se encuentra el Controlador). 3. Después de añadir la clase, el proyecto necesita ser recompilado, empaquetado y probado para su verificación funcional, y republicado.
Soporte técnico de Ridge Security
Ridge Security proporcionará activamente soporte técnico a nuestros usuarios, y continuará rastreando e informando el progreso de este RCE de primavera de manera oportuna. Si tiene alguna pregunta, póngase en contacto con support@ridgesecurity.ai.
Tomado de: Ridge Security
por Lydia Zhang | Abr 18, 2022 | IA en la prueba de penetración automatizada
