Después de Log4j 2, escuché que Java ha sido atacado nuevamente. Esta vez, parece que la situación es más grave, porque el marco de la aplicación de código abierto de pila completa y la implementación del contenedor de inversión de control de la plataforma Java se ven afectados: la familia Spring. , e Internet Hay más de una escapatoria.
Spring siempre ha sido una de las tecnologías imprescindibles para el desarrollo de programación. Un desarrollador full-stack llamado Bogdan N. incluso comentó: "Aprende Java, aprende el framework Spring y nunca perderás tu trabajo". La puerta de primavera se incendia, Java sufrirá.
Se informa que el 30 de marzo, la Plataforma de Intercambio de Vulnerabilidades de Seguridad de la Información Nacional (CNVD) recibió la Vulnerabilidad de Ejecución de Comandos Remotos de Spring Framework (CNVD-2022-23942) reportada por Ant Technology Group Co., Ltd. Un atacante podría aprovechar esta vulnerabilidad para ejecutar comandos de forma remota sin autorización. CNVD tiene una calificación general de " Crítico alto " para esta vulnerabilidad.
En la noche del 31 de marzo, los funcionarios de Spring.io también emitieron un anuncio anticipado urgente , confirmando la existencia de la vulnerabilidad Spring Framework RCE, y las versiones afectadas cubren JDK 9 y posteriores, Spring Framework versiones 5.3.0 a 5.3.17, 5.2 .0 a 5.2.19 y anteriores, etc.
antecedente
Esta vulnerabilidad tiene que comenzar a partir de la noche del 29 de marzo.
En ese momento, muchos internautas dieron la noticia de que había una vulnerabilidad RCE "épica" en el marco de Spring, y hubo un sonido atronador. De repente, los desarrolladores que estaban a punto de quedarse dormidos se sentaron para verificar la situación sobre el vulnerabilidad, lo que hizo que la gente en el círculo técnico entrara en pánico.
Sin embargo, lo que es inusual es que esta vulnerabilidad no provocó las acciones urgentes de muchas grandes empresas en el círculo como el incidente Log4j2 Incluso la fuente de la vulnerabilidad divulgada en el extranjero provino de QQ y algunos sitios web de seguridad de redes nacionales.
Esto también llevó a muchos internautas a especular que la vulnerabilidad debería haber sido descubierta primero por una agencia de seguridad nacional y personal de seguridad. Efectivamente, según el " Boletín de seguridad sobre la vulnerabilidad de ejecución de comandos remotos en Spring Framework " publicado por la Plataforma de intercambio de vulnerabilidades de seguridad de la información nacional (CNVD) el 31 de marzo , este grupo de misteriosos sombreros blancos incluye Ant Technology Group, Qi Anxin Technology, Tecnología de la información de Hangzhou Anheng, Tecnología Antiy, 360, Beijing Tianrongxin, por supuesto, estos son para más adelante.
Anteriormente, algunos internautas publicaron la vulnerabilidad en GitHub (se eliminó, pero algunos internautas guardaron la página):
Fuente: https://archive.ph/DIbrv
Según el contenido de la transmisión por Internet:
La vulnerabilidad RCE 0day en Spring Framework afecta a la versión 9 y posteriores de JDK, utilizando Spring Framework o marcos derivados.
Con el trasfondo creciente de esta vulnerabilidad en línea, muchos investigadores de seguridad de redes y compañías de seguridad extranjeras también publicaron en Twitter para expresar la existencia de esta vulnerabilidad:
A medida que las cosas se fermentaron, antes de que Spring lanzara oficialmente las últimas instrucciones, los desarrolladores no pudieron determinar qué aplicaciones usaban funciones vulnerables, lo que también llevó a los desarrolladores a solicitar cualquier función relacionada con Spring. ¿Existe una vulnerabilidad RCE 0day en Spring Core?
Al mismo tiempo, muchos internautas bromearon:
No entre en pánico, aunque Java ahora ha llegado a la versión Java 18, muchas empresas todavía están atrapadas en la versión Java 8 e inferior.
Diferentes vulnerabilidades de seguridad también han causado serias sombras psicológicas a los ingenieros de Java:
Las vulnerabilidades de primavera de día cero realmente existen
Justo cuando los desarrolladores estaban cada vez más ansiosos, los funcionarios de Spring.io se presentaron la noche del 31 de marzo para confirmar la existencia de esta vulnerabilidad y brindaron una solución.
Según el anuncio, descubrimos que el impacto de esta vulnerabilidad es mucho más grave de lo que pensábamos. Si se cumplen los siguientes umbrales, es muy probable que se vea afectado por la vulnerabilidad:
- JDK 9 o posterior
- Apache Tomcat como contenedor de servlets
- Empaquetado como un WAR tradicional (en comparación con el archivo ejecutable Spring Boot)
- dependencias spring-webmvc o spring-webflux
- Spring Framework versiones 5.3.0 a 5.3.17, 5.2.0 a 5.2.19 y anteriores
solución preliminar
Actualmente, Spring.io ha lanzado las versiones Spring Framework 5.3.18 y 5.2.20, y también trae las últimas Spring Boot 2.6.6 y 2.5.12 que dependen de Spring Framework 5.3.18. Porque si puede actualizar a Spring Framework 5.3.18 y 5.2.20, las siguientes correcciones no son necesarias.
De lo contrario, Spring recomienda oficialmente establecer campos no permitidos de WebDataBinder a través de @ControllerAdvice.
@ControllerAdvice
@Order(Ordered.LOWEST_PRECEDENCE)
public class BinderControllerAdvice {
@InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{
"class.*", "Class.*", "*.class.*", "*.Class.*"};
dataBinder.setDisallowedFields(denylist);
}
}
Esta solución suele funcionar, pero no es 100% capaz de prevenir la vulnerabilidad. Entonces, para ser más seguro, Spring.io también recomienda que las aplicaciones puedan extender RequestMappingHandlerAdapter y actualizar WebDataBinder al final después de todas las demás inicializaciones. Para lograr esto, las aplicaciones Spring Boot pueden declarar un bean WebMvcRegistrations (Spring MVC) o WebFluxRegistrations (Spring WebFlux).
En Spring MVC (y de manera similar en WebFlux) el ejemplo es el siguiente:
package car.app;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.web.servlet.WebMvcRegistrations;
import org.springframework.context.annotation.Bean;
import org.springframework.web.bind.ServletRequestDataBinder;
import org.springframework.web.context.request.NativeWebRequest;
import org.springframework.web.method.annotation.InitBinderDataBinderFactory;
import org.springframework.web.method.support.InvocableHandlerMethod;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter;
import org.springframework.web.servlet.mvc.method.annotation.ServletRequestDataBinderFactory;
@SpringBootApplication
public class MyApp {
public static void main(String[] args) {
SpringApplication.run(CarApp.class, args);
}
@Bean
public WebMvcRegistrations mvcRegistrations() {
return new WebMvcRegistrations() {
@Override
public RequestMappingHandlerAdapter getRequestMappingHandlerAdapter() {
return new ExtendedRequestMappingHandlerAdapter();
}
};
}
private static class ExtendedRequestMappingHandlerAdapter extends RequestMappingHandlerAdapter {
@Override
protected InitBinderDataBinderFactory createDataBinderFactory(List<InvocableHandlerMethod> methods) {
return new ServletRequestDataBinderFactory(methods, getWebBindingInitializer()) {
@Override
protected ServletRequestDataBinder createBinderInstance(
Object target, String name, NativeWebRequest request) throws Exception {
ServletRequestDataBinder binder = super.createBinderInstance(target, name, request);
String[] fields = binder.getDisallowedFields();
List<String> fieldList = new ArrayList<>(fields != null ? Arrays.asList(fields) : Collections.emptyList());
fieldList.addAll(Arrays.asList("class.*", "Class.*", "*.class.*", "*.Class.*"));
binder.setDisallowedFields(fieldList.toArray(new String[] {
}));
return binder;
}
};
}
}
}
Para Spring MVC sin Spring Boot, las aplicaciones pueden cambiar de @EnableWebMvc a extender DelegatingWebMvcConfiguration directamente, como en esta documentación (https://docs.spring.io/spring-framework/docs/current/reference/html/web.html #mvc -config-advanced-java) como se describe en la sección Configuración avanzada y, a continuación, invalide el método createRequestMappingHandlerAdapter.
Con base en lo anterior, recomendamos que los fabricantes de productos (servicios) y los operadores de sistemas de información afectados por la vulnerabilidad realicen una autoinspección lo antes posible y actualicen a la última versión de manera oportuna.
Referencias:
https://www.cyberkendra.com/2022/03/rce-0-day-exploit-found-in-spring-cloud.html
https://its.pku.edu.cn/announce/tz20220330110501.jsp
https://github.com/spring-projects/spring-framework/commit/7f7fb58dd0dae86d22268a4b59ac7c72a6c22529
https://www.bleepingcomputer.com/news/security/new-spring-java-framework-zero-day-allows-remote-code-execution/
https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/