spring-shell-vuln

Spring4Shell: vulnerabilidad RCE en Spring core

Spring ha confirmado la RCE en Spring Framework. El equipo acaba de publicar la declaración junto con las guías de mitigación para el problema. Ahora, esta vulnerabilidad puede rastrearse como CVE-2022-22965.

Se ha compartido información sobre la vulnerabilidad Spring4Shell y los detalles en la publicación Spring4Shell: Details and Exploit. Además, el equipo de seguridad de Praetorian ha confirmado que Spring Core en JDK9+ es vulnerable a la ejecución remota de código debido a un bypass de CVE-2010-1622.

Inicialmente, comenzó el 30 de marzo; la primera notificación de la vulnerabilidad fue insinuada por el líder del equipo KnownSec 404, Heige. Tuiteó el mensaje de advertencia "Spring core RCE （JDK >=9" junto con la imagen del PoC.

Mientras publicamos la historia de la vulnerabilidad, Heige desaparece de Twitter. No sabemos el motivo, pero puede haber algo detrás.

Eventos

A finales de 2021, internet estaba en llamas con la publicación de un Zero-day, una vulnerabilidad de ejecución remota de código también conocida como Log4Shell, en Apache Log4j2. La vulnerabilidad fue encontrada por el equipo de seguridad de Alibaba Cloud.

- Esta vulnerabilidad NO es tan grave como Log4Shell. Todos los escenarios de ataque son más complejos debido a la naturaleza de los ataques de Manipulación del Class Loader en Java. La explotación de Spring4Shell requiere un conocimiento profundo de Java para obtener un PoC funcional. La Manipulación del Class Loader es más complicada de entender que la vulnerabilidad Log4Shell.

Hoy, los investigadores han encontrado otra vulnerabilidad grave que podría causar daños severos. El fallo ahora se rastrea como CVE-2022-22965; podemos llamarlo Spring4Shell. La vulnerabilidad existe en Spring core con versiones de JDK mayores o iguales a 9.0.

Spring Framework y el framework derivado: archivos spring -beans-*.jar o CachedIntrospectionResults.class

Todos los detalles a continuación están confirmados. No me hago responsable de ningún daño causado.

Detalles de la vulnerabilidad e investigación

Como uno de los frameworks de código abierto más populares y ligeros de Java en el mundo, Spring permite a los desarrolladores centrarse en la lógica de negocio y simplifica el ciclo de desarrollo de las aplicaciones empresariales Java.

La explotación requiere un endpoint con DataBinder habilitado (por ejemplo, una petición POST que decodifica automáticamente los datos del cuerpo de la solicitud) y depende en gran medida del contenedor de servlets de la aplicación. Por ejemplo, cuando Spring se despliega en Apache Tomcat, el WebAppClassLoader es accesible, lo que permite a un atacante llamar a getters y setters para, en última instancia, escribir un archivo JSP malicioso en el disco. Sin embargo, si Spring se despliega usando el contenedor de servlets Tomcat Embebido, el classloader es un LaunchedURLClassLoader que tiene acceso limitado.

Sin embargo, en la versión JDK9 (y superior) de Spring Framework, un atacante remoto puede obtener el objeto AccessLogValve y valores de campos maliciosos a través de la función de enlace de parámetros del framework, siempre que se cumplan ciertas condiciones.

• Actualmente se sabe que activar esta vulnerabilidad requiere dos condiciones básicas:
• Usar el framework Spring MVC y JDK9 o superior

(1). Comprobar el número de versión del JDK

En el servidor en ejecución del sistema de la organización, ejecute el comando "java -version" para comprobar la versión de JDK en uso. Si el número de versión es menor o igual a 8, el sistema no está afectado por la vulnerabilidad.

(2). Comprobar el uso de Spring Framework

1. Si el proyecto del sistema de la organización está desplegado como paquete war, siga los pasos siguientes para determinarlo.

• Descomprima el paquete war: cambie la extensión del archivo war a .zip y descomprima el archivo zip.
• Busque un archivo jar con el formato spring-beans-*.jar (por ejemplo, spring-beans-5.3.16.jar) en el directorio de descompresión. Si existe, significa que el sistema de negocio está desarrollado con el framework Spring.
• Si el archivo spring-beans-*.jar no existe, busque la presencia del archivo CachedIntrospectionResuLts.class en el directorio de descompresión. Si existe, significa que el sistema de negocio está desarrollado con el framework Spring.

2. Si el proyecto del sistema de la organización se ejecuta directa e independientemente como paquete jar, determínelo según los pasos siguientes.

• Descomprima el paquete jar: cambie la extensión del archivo jar a .zip y descomprima el archivo zip.
• Busque un archivo jar con el formato spring-beans-*.jar (por ejemplo, spring-beans-5.3.16.jar) en el directorio de descompresión. Si existe, significa que el sistema de negocio está desarrollado con el framework Spring.
• Si el archivo spring-beans-*.jar no existe, busque la presencia del archivo CachedIntrospectionResuLts.class en el directorio de descompresión. Si existe, significa que el sistema de negocio está desarrollado con el framework Spring.

(3) Investigación exhaustiva

Después de completar los dos pasos de solución de problemas anteriores, se deben cumplir simultáneamente las dos condiciones siguientes para determinar que el sistema está afectado por esta vulnerabilidad:

1. El número de versión del JDK es 9 o superior;
2. Se utiliza el framework Spring o un framework derivado.

Guías de corrección de la vulnerabilidad

Ahora, el equipo de Spring ha corregido la vulnerabilidad y ha publicado las últimas versiones de Spring Boot 2.6.6 y 2.5.12, que dependen de Spring Framework 5.3.18.

Protección WAF

En los dispositivos de protección de red como el WAF, implemente reglas de filtrado para cadenas como "class.", "Class.", ".class." y ".Class.", según la situación real del tráfico de los servicios desplegados. Después de aplicar las reglas de filtrado, pruebe el funcionamiento del negocio para evitar impactos adicionales.

Medidas temporales de reparación

La reparación temporal de la vulnerabilidad debe realizarse con los siguientes dos pasos al mismo tiempo:

1. Busque la anotación @InitBinder de forma global en la aplicación para ver si se llama al método dataBinder.setDisallowedFields en el cuerpo del método. Si se encuentra la introducción de este fragmento de código, añada {"class.","Class. a la lista negra original ",".class.", ".Class."}. (Nota: si este fragmento de código se usa mucho, debe añadirse en todas partes)

2. Cree la siguiente clase global en el paquete del proyecto del sistema de la aplicación y asegúrese de que Spring carga esta clase (se recomienda añadirla en el paquete donde se encuentra el Controller). Después de añadir la clase, el proyecto debe recompilarse, empaquetarse, someterse a pruebas de verificación funcional y volver a publicarse.

import org.springframework.core.annotation.Order;

        import org.springframework.web.bind.WebDataBinder;

        import org.springframework.web.bind.annotation.ControllerAdvice;

        import org.springframework.web.bind.annotation.InitBinder;

        @ControllerAdvice

        @Order(10000)

        public class GlobalControllerAdvice{ 

             @InitBinder

             public void setAllowedFields(webdataBinder dataBinder){

             String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};

             dataBinder.setDisallowedFields(abd);

             }

        }

Desde el repositorio Git de los proyectos de Spring, parece que el desarrollador de Spring está trabajando en una corrección para la vulnerabilidad de ejecución remota de código, pero tenemos que esperar a la confirmación oficial.