Detección de vulnerabilidades en Spring4Shell con RidgeBot



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.


https://github.com/spring-projects/spring-framework/tags


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



0 comentarios

Entradas Recientes

Ver todo