Actualización al 31 de marzo: Spring ha confirmado el 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 se puede rastrear como CVE-2022-22965 .
Actualización: – Tenemos información sobre la vulnerabilidad Spring4Shell y hemos compartido los detalles en Spring4Shell: publicación de detalles y explotación . 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 una omisión de CVE-2010-1622.
A fines de 2021, Internet estaba en llamas con la caída de 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.
Hoy, los investigadores encontraron otra vulnerabilidad peor que puede causar daños severos a toneladas de aplicaciones. que puede arruinar el internet. En este punto, no hay una identificación de CVE para esta vulnerabilidad, pero podemos llamarla Spring4Shell . La vulnerabilidad existe en Spring core con la versión de JDK mayor o igual a 9.0.
Spring Framework y marco derivado spring -beans-*.jar archivos o CachedIntrospectionResults.classEn este punto, no tenemos información exacta sobre el error, pero de las fuentes no confirmadas, obtuvimos algunos detalles interesantes.
Todos los detalles a continuación se confirman y ahora se comparten desde una fuente no confirmada . No nos hacemos responsables de los daños causados.
Detalles de vulnerabilidad e investigación
Como el marco ligero de código abierto de Java más popular del mundo, Spring permite a los desarrolladores centrarse en la lógica empresarial y simplifica el ciclo de desarrollo de las aplicaciones empresariales de Java.
La explotación requiere un punto final con DataBinder habilitado (por ejemplo, una solicitud POST que descodifica datos del cuerpo de la solicitud automáticamente) y depende en gran medida del contenedor de servlet para la aplicación. Por ejemplo, cuando Spring se implementa en Apache Tomcat, se puede acceder a WebAppClassLoader, lo que permite a un atacante llamar a captadores y definidores para, en última instancia, escribir un archivo JSP malicioso en el disco. Sin embargo, si Spring se implementa utilizando el contenedor de servlet de Tomcat incorporado, el cargador de clases es un LaunchedURLClassLoader que tiene acceso limitado.
Sin embargo, en la versión JDK9 (y superior) del framework Spring, un atacante remoto puede obtener el objeto AccessLogValve y los valores de los campos maliciosos a través de la función de vinculación de parámetros del framework sobre la base del cumplimiento de ciertas condiciones, activando así el mecanismo de canalización. y escribir campos arbitrarios. archivo en la ruta.
- Actualmente se sabe que la activación de esta vulnerabilidad requiere dos condiciones básicas:
- Use el marco Spring MVC de JDK9 y superior
(1). Compruebe el número de versión de JDK
En el servidor en ejecución del sistema de la organización, ejecute el comando ” java -version ” para verificar la versión de JDK en ejecución. Si el número de versión es menor o igual a 8, no se ve afectado por la vulnerabilidad.
(2). Verifique el uso del marco Spring
1. Si el proyecto del sistema de organización se implementa en forma de paquete de guerra, siga los pasos a continuación para juzgar.
Descomprima el paquete war: Cambie el sufijo del archivo war a .zip y descomprima el archivo zip
Busque un archivo jar en formato spring-beans-*.jar (por ejemplo, spring-beans-5.3.16.jar) en el directorio de descompresión. Si existe, significa que el sistema empresarial se desarrolla utilizando el marco Spring.
Si el archivo spring-beans-*.jar no existe, busque la existencia del archivo CachedIntrospectionResuLts.class en el directorio de descompresión. Si existe, significa que el sistema empresarial se desarrolla utilizando el marco Spring.
2. Si el proyecto del sistema de organización se ejecuta directa e independientemente en forma de un paquete jar, juzgue de acuerdo con los siguientes pasos.
- Descomprima el paquete jar: cambie el sufijo del archivo jar a .zip y descomprima el archivo zip.
- Busque un archivo jar en formato spring-beans-*.jar (por ejemplo, spring-beans-5.3.16.jar) en el directorio de descompresión. Si existe, significa que el sistema empresarial se desarrolla utilizando el marco Spring.
- Si el archivo spring-beans-*.jar no existe, busque la existencia del archivo CachedIntrospectionResuLts.class en el directorio de descompresión. Si existe, significa que el sistema empresarial se desarrolla utilizando el marco Spring.
(3) Investigación Integral
Después de completar los dos pasos anteriores de solución de problemas, se cumplen las siguientes dos condiciones al mismo tiempo para determinar que está afectado por esta vulnerabilidad:
- El número de versión de JDK es 9 y superior;
- utilizando el marco de primavera o el marco derivado.
Guías de reparación de vulnerabilidades
De momento, no hay parche oficial para primavera . Pero se recomienda utilizar las siguientes dos soluciones temporales para la protección, prestar atención al lanzamiento de parches oficiales de manera oportuna y corregir vulnerabilidades de acuerdo con los parches oficiales.
Actualización: ahora el equipo de Spring solucionó la vulnerabilidad y lanzó las últimas versiones de Spring Boot 2.6.6 y 2.5.12 que dependen de Spring Framework 5.3.18
Tenemos algunas actualizaciones, esta vulnerabilidad es mucho más grande que la vulnerabilidad Log4Shell . Por lo tanto, recomendamos prestar atención al lanzamiento de parches oficiales y hacer que se aplique antes que los delincuentes.
protección WAF
En dispositivos de protección de red como WAF, implemente el filtrado de reglas para cadenas como “clase.*”, “Clase.*”, “*.clase.*” y “*.Clase.*” de acuerdo con la situación real del tráfico de servicios desplegados. Después de filtrar las reglas, pruebe la operación comercial para evitar un impacto adicional.
Medidas de reparación temporal
La reparación temporal de la fuga se debe realizar en los siguientes dos pasos al mismo tiempo:
1. Busque la anotación @InitBinder globalmente 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, agregue {“class.*”,”Class.* a la lista negra original “,”*.class.*”, “*.Class.*”}. (Nota: si este fragmento de código se usa mucho, debe agregarse 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 cargue esta clase (se recomienda agregarla en el paquete donde se encuentra el controlador). Después de agregar la clase, el proyecto debe volver a compilarse y empaquetarse, y probarse para la verificación funcional. y volver a publicar el proyecto.
importar org.springframework.core.annotation.Order;
importar org.springframework.web.bind.WebDataBinder;
importar org.springframework.web.bind.annotation.ControllerAdvice;
importar org.springframework.web.bind.annotation.InitBinder;
@ControllerAdvice
@Pedido(10000)
clase pública GlobalControllerAdvice{
@InitBinder
public void setAllowedFields(webdataBinder dataBinder){
String[]abd=nueva cadena[]{"clase.*","Clase.*","*.clase.*","*.Clase.*"};
dataBinder.setDisallowedFields(abd);
}
}
Desde el Repositorio Git de los proyectos de Spring, parece que el desarrollador de Spring está trabajando en una solución para la vulnerabilidad de ejecución remota de código, pero tenemos que esperar la confirmación oficial.