¿Cómo abordar temporalmente SpringShell? Vulnerabilidad día cero en Spring Core

Después de múltiples reportes aparecidos durante la última semana, Spring confirmó la vulnerabilidad de ejecución remota de código (RCE) en Spring Framework. La vulnerabilidad ha sido identificada como CVE-2022-22965 y es muy posible que ya haya sido explotada de forma activa.

Según se ha reportado, la explotación de esta falla, ahora conocida como SpringShell, requiere de un endpoint con DataBinder habilitado y depende en gran medida del contenedor de servlet para la aplicación. Por ejemplo, cuando Spring se implementa en Apache Tomcat, es posible acceder a WebAppClassLoader, permitiendo a los actores de amenazas llamar a captadores y definidores para 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.

En versiones JDK9 y posteriores del framework Spring, los hackers maliciosos 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 para escribir archivos arbitrarios en la ruta.

¿CÓMO VERIFICAR LA EXPOSICIÓN A ESTA FALLA?

Especialistas en ciberseguridad mencionan que hay diversos métodos para verificar el grado de exposición a un ataque.

Verifique el número de versión de JDK

En el servidor en ejecución del sistema, ejecute el comando java -version para verificar la versión de JDK en ejecución. Si se ejecutan versiones 8 o posteriores, el sistema no se verá afectado.

Verifique el uso del marco Spring

Si el proyecto del sistema se implementa en forma de paquete war, siga los pasos a continuación para determinar si el sistema se ve comprometido:

• 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 en el directorio de descompresión. Si existe, significa que el sistema se desarrolla utilizando el marco Spring
• Si el archivo spring-beans-*.jar no existe, busque la existencia del archivo CachedIntrospectionResuLts.class. Si este archivo existe, significa que el sistema se desarrolla utilizando el marco Spring

Si el proyecto del sistema de organización se ejecuta directa e independientemente en forma de un paquete jar, verifique aplicando 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 en el directorio de descompresión. Si existe, significa que el sistema se desarrolla utilizando el marco Spring
• Si el archivo spring-beans-*.jar no existe, busque la existencia del archivo CachedIntrospectionResuLts.class. Si existe, significa que el sistema se ejecuta usando el marco Spring

EN BUSCA DE LA FALLA

Después de completar los dos pasos anteriores de solución de problemas, se cumplen las siguientes dos condiciones al mismo tiempo para determinar la presencia de la falla:

• Uso de JDK en versiones 9 y posteriores
• Uso del marco Spring

MITIGACIÓN

La vulnerabilidad no ha sido corregida oficialmente, aunque ya se sabe de la existencia de dos soluciones alternativas aplicables al menos hasta que los desarrolladores de Spring puedan emitir un parche completo.

WAF

En sistemas protegidos con firewall de aplicaciones web (WAF), implemente el filtrado de reglas para cadenas como  “class.*”, “Class.*”, “*.class.*”, y “*.Class.*” de acuerdo con la situación real del tráfico de servicios desplegados. Después aplicar el filtrado, haga las pruebas necesarias para evitar un impacto adicional en sus sistemas.

Soluciones adicionales

Puede aplicar simultáneamente los siguientes pasos para mitigar el riesgo de explotación:

• Busque la anotación @InitBinder 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.*”, “*.class.*”, “*.Class.*”
•  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. 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

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);
             }
        }

Los parches estarán listos en breve, por lo que se espera poder prevenir la explotación masiva de esta vulnerabilidad.

Para conocer más sobre riesgos de seguridad informática, malware, vulnerabilidades y tecnologías de la información, no dude en ingresar al sitio web del Instituto Internacional de Seguridad Cibernética (IICS).

El cargo ¿Cómo abordar temporalmente SpringShell? Vulnerabilidad día cero en Spring Core apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente