Nuevas vulnerabilidades en las bibliotecas de Spring: cómo saber si está en riesgo y qué hacer

Publicado el 01 de abril de 2022
por Charlie Eriksen
ESTUDIO DE CASO

Nuevas vulnerabilidades en las bibliotecas de Spring: cómo saber si está en riesgo y qué hacer

Publicado el 01 de abril de 2022
por Charlie Eriksen
Ver recurso
Ver recurso

Recientemente, las librerías Spring, una de las librerías más populares en la comunidad Java, revelaron 2 vulnerabilidades relacionadas con la Ejecución Remota de Código (RCE). Para facilitarte la comprensión de si estás en riesgo de alguna de las dos vulnerabilidades y qué acciones tomar, hemos desglosado los detalles conocidos de "Spring4Shell" y "Spring Cloud Function".

Vulnerabilidad 1 - "Spring4Shell" (CVE-2022-22965)

El 29 de marzo de 2022, la comunidad descubrió una serie de tweets que contenían capturas de pantalla de una prueba de concepto de un exploit dirigido a Spring Core (SC) , que permite la ejecución remota de código para todas las versiones de Spring Core, incluida la versión más reciente, 5.3.17.

¿Qué aplicaciones están en peligro?

Actualmente, se ha confirmado que sólo las aplicaciones alojadas en Tomcat están en riesgo de sufrir este nuevo exploit. Aunque no se ha demostrado que el exploit tenga éxito contra el contenedor de servlets Embedded Tomcat, o cualquier otra aplicación no alojada en Tomcat, esto no descarta la posibilidad de que la amenaza tenga éxito en el futuro en estos marcos. 

Spring ha publicado un comunicado oficial sobre la vulnerabilidad, en el que se aclara que se deben cumplir las siguientes condiciones para ser vulnerable, según el conocimiento actual de la vulnerabilidad:

  • JDK 9 o superior
  • Apache Tomcat como contenedor de Servlets
  • Empaquetado como un WAR tradicional (en contraste con un jar ejecutable de Spring Boot)
  • dependencia de spring-webmvc o spring-webflux
  • Versiones de Spring Framework de la 5.3.0 a la 5.3.17, de la 5.2.0 a la 5.2.19 y versiones anteriores

¿Cómo funciona la explotación de "Spring4Shell"?

La explotación se basa en el uso de "Data Binding" (org.springframework.web.bind.WebDataBinder) en peticiones que hacen uso de Plain Old Java Objects (POJO) en la firma del método:

Donde la clase Foo es una clase POJO, que podría definirse como lo siguiente. Tenga en cuenta que la clase real no es importante, siempre y cuando sea cargada por el cargador de clases. 

Cuando una solicitud es manejada por un método como este, el Cargador de Clases es usado para resolver la clase. El cargador de clases es responsable de cargar las clases en tiempo de ejecución, sin tener que precargar primero todos los tipos posibles en la memoria. Averigua qué archivo .jar debe cargarse cuando se utiliza una nueva clase. 

Puedes encontrar la información más actualizada y detallada sobre esta vulnerabilidad directamente desde Spring en su blogpost, incluyendo posibles correcciones o soluciones.

Vulnerabilidad 2 - Función de Spring Cloud (CVE-2022-22963)

El 27 de marzo de 2022, Cyber Kendra reveló detalles sobre una vulnerabilidad de 0 días de ejecución remota de código (RCE) en las funciones de Spring Cloud para la que no existía ningún parche. A la vulnerabilidad se le asignó el ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.

¿Qué aplicaciones están en peligro?

La vulnerabilidad afectaba a las aplicaciones en estas condiciones:

  • JDK 9 o más reciente
  • Funciones de Spring Cloud versión 3.1.6 (o inferior), 3.2.2 (o inferior), o cualquier versión no compatible 

¿Cómo funciona la explotación?

Spring Cloud Function proporciona la capacidad para que los desarrolladores configuren cómo se maneja el enrutamiento a través de la propiedad spring.cloud.function.routing-expression, normalmente realizada a través de la configuración, o del código. Se trata de una potente capacidad que acepta el "Lenguaje de Expresión de Spring" (SpEL). A través de esta vulnerabilidad de día 0, hemos aprendido que esta propiedad podría establecerse a través de las cabeceras HTTP de una solicitud, lo que significa que un atacante podría incrustar código SpEL directamente en su solicitud HTTP a un punto final RoutingFunction, y así ejecutar código arbitrario. 

¿Qué medidas deben tomar los usuarios para mitigar el riesgo?

Spring ha lanzado las versiones 3.1.7 y 3.2.3 para solucionar este problema al no permitir que esta propiedad se establezca a través de las cabeceras HTTP, mitigando la vulnerabilidad. Después de actualizar a cualquiera de las dos versiones, no es necesario realizar ningún paso adicional.

¿Está interesado en saber más sobre cómo ayudamos a los desarrolladores a escribir un código más seguro? Reserve una demostración o explore nuestras directrices de codificación segura gratuitas en secure code coach.

Fuentes

Ver recurso
Ver recurso

Autor

Charlie Eriksen

¿Quieres más?

Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.

Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.

Ver blog
¿Quieres más?

Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores

Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.

Centro de recursos

Nuevas vulnerabilidades en las bibliotecas de Spring: cómo saber si está en riesgo y qué hacer

Publicado el 01 de abril de 2022
Por Charlie Eriksen

Recientemente, las librerías Spring, una de las librerías más populares en la comunidad Java, revelaron 2 vulnerabilidades relacionadas con la Ejecución Remota de Código (RCE). Para facilitarte la comprensión de si estás en riesgo de alguna de las dos vulnerabilidades y qué acciones tomar, hemos desglosado los detalles conocidos de "Spring4Shell" y "Spring Cloud Function".

Vulnerabilidad 1 - "Spring4Shell" (CVE-2022-22965)

El 29 de marzo de 2022, la comunidad descubrió una serie de tweets que contenían capturas de pantalla de una prueba de concepto de un exploit dirigido a Spring Core (SC) , que permite la ejecución remota de código para todas las versiones de Spring Core, incluida la versión más reciente, 5.3.17.

¿Qué aplicaciones están en peligro?

Actualmente, se ha confirmado que sólo las aplicaciones alojadas en Tomcat están en riesgo de sufrir este nuevo exploit. Aunque no se ha demostrado que el exploit tenga éxito contra el contenedor de servlets Embedded Tomcat, o cualquier otra aplicación no alojada en Tomcat, esto no descarta la posibilidad de que la amenaza tenga éxito en el futuro en estos marcos. 

Spring ha publicado un comunicado oficial sobre la vulnerabilidad, en el que se aclara que se deben cumplir las siguientes condiciones para ser vulnerable, según el conocimiento actual de la vulnerabilidad:

  • JDK 9 o superior
  • Apache Tomcat como contenedor de Servlets
  • Empaquetado como un WAR tradicional (en contraste con un jar ejecutable de Spring Boot)
  • dependencia de spring-webmvc o spring-webflux
  • Versiones de Spring Framework de la 5.3.0 a la 5.3.17, de la 5.2.0 a la 5.2.19 y versiones anteriores

¿Cómo funciona la explotación de "Spring4Shell"?

La explotación se basa en el uso de "Data Binding" (org.springframework.web.bind.WebDataBinder) en peticiones que hacen uso de Plain Old Java Objects (POJO) en la firma del método:

Donde la clase Foo es una clase POJO, que podría definirse como lo siguiente. Tenga en cuenta que la clase real no es importante, siempre y cuando sea cargada por el cargador de clases. 

Cuando una solicitud es manejada por un método como este, el Cargador de Clases es usado para resolver la clase. El cargador de clases es responsable de cargar las clases en tiempo de ejecución, sin tener que precargar primero todos los tipos posibles en la memoria. Averigua qué archivo .jar debe cargarse cuando se utiliza una nueva clase. 

Puedes encontrar la información más actualizada y detallada sobre esta vulnerabilidad directamente desde Spring en su blogpost, incluyendo posibles correcciones o soluciones.

Vulnerabilidad 2 - Función de Spring Cloud (CVE-2022-22963)

El 27 de marzo de 2022, Cyber Kendra reveló detalles sobre una vulnerabilidad de 0 días de ejecución remota de código (RCE) en las funciones de Spring Cloud para la que no existía ningún parche. A la vulnerabilidad se le asignó el ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.

¿Qué aplicaciones están en peligro?

La vulnerabilidad afectaba a las aplicaciones en estas condiciones:

  • JDK 9 o más reciente
  • Funciones de Spring Cloud versión 3.1.6 (o inferior), 3.2.2 (o inferior), o cualquier versión no compatible 

¿Cómo funciona la explotación?

Spring Cloud Function proporciona la capacidad para que los desarrolladores configuren cómo se maneja el enrutamiento a través de la propiedad spring.cloud.function.routing-expression, normalmente realizada a través de la configuración, o del código. Se trata de una potente capacidad que acepta el "Lenguaje de Expresión de Spring" (SpEL). A través de esta vulnerabilidad de día 0, hemos aprendido que esta propiedad podría establecerse a través de las cabeceras HTTP de una solicitud, lo que significa que un atacante podría incrustar código SpEL directamente en su solicitud HTTP a un punto final RoutingFunction, y así ejecutar código arbitrario. 

¿Qué medidas deben tomar los usuarios para mitigar el riesgo?

Spring ha lanzado las versiones 3.1.7 y 3.2.3 para solucionar este problema al no permitir que esta propiedad se establezca a través de las cabeceras HTTP, mitigando la vulnerabilidad. Después de actualizar a cualquiera de las dos versiones, no es necesario realizar ningún paso adicional.

¿Está interesado en saber más sobre cómo ayudamos a los desarrolladores a escribir un código más seguro? Reserve una demostración o explore nuestras directrices de codificación segura gratuitas en secure code coach.

Fuentes

Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.