Nuevas vulnerabilidades en las bibliotecas de Spring: cómo saber si estás en riesgo y qué hacer
Recientemente, las bibliotecas Spring, una de las bibliotecas más populares de la comunidad Java, revelaron 2 vulnerabilidades relacionadas con la ejecución remota de código (RCE). Para ayudarte a comprender mejor si corres el riesgo de sufrir alguna de estas vulnerabilidades y qué medidas debes tomar, hemos desglosado los detalles conocidos de «Spring4Shell» y «Spring Cloud Function».
Vulnerabilidad 1: «Spring4Shell» (CVE-22965)
El 29 de marzo de 2022, la comunidad descubrió una serie de tuits 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 en todas las versiones de Spring Core, incluida la versión publicada más recientemente, la 5.3.17.
¿Qué aplicaciones están en riesgo?
Actualmente, solo se ha confirmado que las aplicaciones alojadas en Tomcat corren el riesgo de sufrir este nuevo exploit. Si bien no se ha demostrado que la explotación tenga éxito contra el contenedor de servlets integrado de Tomcat ni contra ninguna otra aplicación que no esté alojada en Tomcat, eso no descarta la posibilidad de que la amenaza tenga éxito en el futuro para estos marcos.
Spring publicó un anuncio oficial declaración sobre la vulnerabilidad, que aclara que se deben cumplir las siguientes condiciones para ser vulnerable, de acuerdo con la comprensión actual de la vulnerabilidad:
- JDK 9 o superior
- Apache Tomcat como contenedor de servlets
- Empaquetado como un WAR tradicional (a diferencia de un archivo ejecutable de Spring Boot)
- dependencia de spring-webmvc o spring-webflux
- Spring Framework versiones 5.3.0 a 5.3.17, 5.2.0 a 5.2.19 y versiones anteriores
¿Cómo funciona la explotación de «Spring4Shell»?
La explotación se basa en el uso de la «vinculación de datos» (org.springFramework.webbind.WebDataBinder) en las solicitudes que utilizan objetos Java antiguos y sencillos (POJO) en la firma del método:
Donde la clase Foo es una clase POJO, que podría definirse de la siguiente manera. Ten en cuenta que la clase real no es importante, siempre y cuando la cargue el cargador de clases.
Cuando una solicitud es gestionada por un método como este, el cargador de clases se utiliza 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. Determina qué archivo.jar se debe cargar cuando se usa una nueva clase.
Puede encontrar la información más actualizada y detallada sobre esta vulnerabilidad directamente desde Spring en su entrada de blog, incluidas las posibles correcciones o soluciones alternativas.
Vulnerabilidad 2: Función Spring Cloud (CVE-333322963)
El 27 de marzo de 2022, Cyber Kendra reveló detalles sobre una vulnerabilidad de ejecución remota de código (RCE) en 0 días en Spring Cloud Functions para la que no existía ningún parche. Se asignó el ID a la vulnerabilidad CVE-333322963: Vulnerabilidad de acceso a recursos de Spring Expression.
¿Qué aplicaciones están en riesgo?
La vulnerabilidad afectó a las aplicaciones en las siguientes condiciones:
- JDK 9 o más reciente
- Spring Cloud Functions 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 brinda a los desarrolladores la capacidad de configurar cómo se maneja el enrutamiento a través de la propiedad spring.cloud.function.routing-expression, generalmente mediante configuración o código. Se trata de una potente capacidad que acepta el «Spring Expression Language» (SpEL). Gracias a esta vulnerabilidad de 0 días, descubrimos que esta propiedad podía configurarse a través de los encabezados HTTP de una solicitud, lo que significaba que un atacante podía incrustar código SPel directamente en su solicitud HTTP dirigida a un punto final de RoutingFunction y, por lo tanto, ejecutar código arbitrario.
¿Qué medidas deben tomar los usuarios para mitigar el riesgo?
La primavera tiene publicado las versiones 3.1.7 y 3.2.3 abordan este problema al no permitir que esta propiedad se establezca a través de encabezados HTTP, lo que mitiga la vulnerabilidad. Tras actualizar a cualquiera de las versiones, no es necesario realizar ningún paso adicional.
¿Está interesado en obtener más información sobre cómo ayudamos a los desarrolladores a escribir código más seguro? Reserva una demostración o consulta nuestras directrices de codificación segura y gratuitas en entrenador de código seguro.
Fuentes
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Recientemente, las bibliotecas Spring, una de las bibliotecas más populares de la comunidad Java, revelaron 2 vulnerabilidades relacionadas con la ejecución remota de código (RCE). Hemos desglosado los detalles conocidos de «Spring4Shell» y «Spring Cloud Function» para ayudarte a entender si estás en riesgo y qué hacer en ese caso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Recientemente, las bibliotecas Spring, una de las bibliotecas más populares de la comunidad Java, revelaron 2 vulnerabilidades relacionadas con la ejecución remota de código (RCE). Para ayudarte a comprender mejor si corres el riesgo de sufrir alguna de estas vulnerabilidades y qué medidas debes tomar, hemos desglosado los detalles conocidos de «Spring4Shell» y «Spring Cloud Function».
Vulnerabilidad 1: «Spring4Shell» (CVE-22965)
El 29 de marzo de 2022, la comunidad descubrió una serie de tuits 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 en todas las versiones de Spring Core, incluida la versión publicada más recientemente, la 5.3.17.
¿Qué aplicaciones están en riesgo?
Actualmente, solo se ha confirmado que las aplicaciones alojadas en Tomcat corren el riesgo de sufrir este nuevo exploit. Si bien no se ha demostrado que la explotación tenga éxito contra el contenedor de servlets integrado de Tomcat ni contra ninguna otra aplicación que no esté alojada en Tomcat, eso no descarta la posibilidad de que la amenaza tenga éxito en el futuro para estos marcos.
Spring publicó un anuncio oficial declaración sobre la vulnerabilidad, que aclara que se deben cumplir las siguientes condiciones para ser vulnerable, de acuerdo con la comprensión actual de la vulnerabilidad:
- JDK 9 o superior
- Apache Tomcat como contenedor de servlets
- Empaquetado como un WAR tradicional (a diferencia de un archivo ejecutable de Spring Boot)
- dependencia de spring-webmvc o spring-webflux
- Spring Framework versiones 5.3.0 a 5.3.17, 5.2.0 a 5.2.19 y versiones anteriores
¿Cómo funciona la explotación de «Spring4Shell»?
La explotación se basa en el uso de la «vinculación de datos» (org.springFramework.webbind.WebDataBinder) en las solicitudes que utilizan objetos Java antiguos y sencillos (POJO) en la firma del método:
Donde la clase Foo es una clase POJO, que podría definirse de la siguiente manera. Ten en cuenta que la clase real no es importante, siempre y cuando la cargue el cargador de clases.
Cuando una solicitud es gestionada por un método como este, el cargador de clases se utiliza 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. Determina qué archivo.jar se debe cargar cuando se usa una nueva clase.
Puede encontrar la información más actualizada y detallada sobre esta vulnerabilidad directamente desde Spring en su entrada de blog, incluidas las posibles correcciones o soluciones alternativas.
Vulnerabilidad 2: Función Spring Cloud (CVE-333322963)
El 27 de marzo de 2022, Cyber Kendra reveló detalles sobre una vulnerabilidad de ejecución remota de código (RCE) en 0 días en Spring Cloud Functions para la que no existía ningún parche. Se asignó el ID a la vulnerabilidad CVE-333322963: Vulnerabilidad de acceso a recursos de Spring Expression.
¿Qué aplicaciones están en riesgo?
La vulnerabilidad afectó a las aplicaciones en las siguientes condiciones:
- JDK 9 o más reciente
- Spring Cloud Functions 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 brinda a los desarrolladores la capacidad de configurar cómo se maneja el enrutamiento a través de la propiedad spring.cloud.function.routing-expression, generalmente mediante configuración o código. Se trata de una potente capacidad que acepta el «Spring Expression Language» (SpEL). Gracias a esta vulnerabilidad de 0 días, descubrimos que esta propiedad podía configurarse a través de los encabezados HTTP de una solicitud, lo que significaba que un atacante podía incrustar código SPel directamente en su solicitud HTTP dirigida a un punto final de RoutingFunction y, por lo tanto, ejecutar código arbitrario.
¿Qué medidas deben tomar los usuarios para mitigar el riesgo?
La primavera tiene publicado las versiones 3.1.7 y 3.2.3 abordan este problema al no permitir que esta propiedad se establezca a través de encabezados HTTP, lo que mitiga la vulnerabilidad. Tras actualizar a cualquiera de las versiones, no es necesario realizar ningún paso adicional.
¿Está interesado en obtener más información sobre cómo ayudamos a los desarrolladores a escribir código más seguro? Reserva una demostración o consulta nuestras directrices de codificación segura y gratuitas en entrenador de código seguro.
Fuentes
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Recientemente, las bibliotecas Spring, una de las bibliotecas más populares de la comunidad Java, revelaron 2 vulnerabilidades relacionadas con la ejecución remota de código (RCE). Para ayudarte a comprender mejor si corres el riesgo de sufrir alguna de estas vulnerabilidades y qué medidas debes tomar, hemos desglosado los detalles conocidos de «Spring4Shell» y «Spring Cloud Function».
Vulnerabilidad 1: «Spring4Shell» (CVE-22965)
El 29 de marzo de 2022, la comunidad descubrió una serie de tuits 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 en todas las versiones de Spring Core, incluida la versión publicada más recientemente, la 5.3.17.
¿Qué aplicaciones están en riesgo?
Actualmente, solo se ha confirmado que las aplicaciones alojadas en Tomcat corren el riesgo de sufrir este nuevo exploit. Si bien no se ha demostrado que la explotación tenga éxito contra el contenedor de servlets integrado de Tomcat ni contra ninguna otra aplicación que no esté alojada en Tomcat, eso no descarta la posibilidad de que la amenaza tenga éxito en el futuro para estos marcos.
Spring publicó un anuncio oficial declaración sobre la vulnerabilidad, que aclara que se deben cumplir las siguientes condiciones para ser vulnerable, de acuerdo con la comprensión actual de la vulnerabilidad:
- JDK 9 o superior
- Apache Tomcat como contenedor de servlets
- Empaquetado como un WAR tradicional (a diferencia de un archivo ejecutable de Spring Boot)
- dependencia de spring-webmvc o spring-webflux
- Spring Framework versiones 5.3.0 a 5.3.17, 5.2.0 a 5.2.19 y versiones anteriores
¿Cómo funciona la explotación de «Spring4Shell»?
La explotación se basa en el uso de la «vinculación de datos» (org.springFramework.webbind.WebDataBinder) en las solicitudes que utilizan objetos Java antiguos y sencillos (POJO) en la firma del método:
Donde la clase Foo es una clase POJO, que podría definirse de la siguiente manera. Ten en cuenta que la clase real no es importante, siempre y cuando la cargue el cargador de clases.
Cuando una solicitud es gestionada por un método como este, el cargador de clases se utiliza 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. Determina qué archivo.jar se debe cargar cuando se usa una nueva clase.
Puede encontrar la información más actualizada y detallada sobre esta vulnerabilidad directamente desde Spring en su entrada de blog, incluidas las posibles correcciones o soluciones alternativas.
Vulnerabilidad 2: Función Spring Cloud (CVE-333322963)
El 27 de marzo de 2022, Cyber Kendra reveló detalles sobre una vulnerabilidad de ejecución remota de código (RCE) en 0 días en Spring Cloud Functions para la que no existía ningún parche. Se asignó el ID a la vulnerabilidad CVE-333322963: Vulnerabilidad de acceso a recursos de Spring Expression.
¿Qué aplicaciones están en riesgo?
La vulnerabilidad afectó a las aplicaciones en las siguientes condiciones:
- JDK 9 o más reciente
- Spring Cloud Functions 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 brinda a los desarrolladores la capacidad de configurar cómo se maneja el enrutamiento a través de la propiedad spring.cloud.function.routing-expression, generalmente mediante configuración o código. Se trata de una potente capacidad que acepta el «Spring Expression Language» (SpEL). Gracias a esta vulnerabilidad de 0 días, descubrimos que esta propiedad podía configurarse a través de los encabezados HTTP de una solicitud, lo que significaba que un atacante podía incrustar código SPel directamente en su solicitud HTTP dirigida a un punto final de RoutingFunction y, por lo tanto, ejecutar código arbitrario.
¿Qué medidas deben tomar los usuarios para mitigar el riesgo?
La primavera tiene publicado las versiones 3.1.7 y 3.2.3 abordan este problema al no permitir que esta propiedad se establezca a través de encabezados HTTP, lo que mitiga la vulnerabilidad. Tras actualizar a cualquiera de las versiones, no es necesario realizar ningún paso adicional.
¿Está interesado en obtener más información sobre cómo ayudamos a los desarrolladores a escribir código más seguro? Reserva una demostración o consulta nuestras directrices de codificación segura y gratuitas en entrenador de código seguro.
Fuentes
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Recientemente, las bibliotecas Spring, una de las bibliotecas más populares de la comunidad Java, revelaron 2 vulnerabilidades relacionadas con la ejecución remota de código (RCE). Para ayudarte a comprender mejor si corres el riesgo de sufrir alguna de estas vulnerabilidades y qué medidas debes tomar, hemos desglosado los detalles conocidos de «Spring4Shell» y «Spring Cloud Function».
Vulnerabilidad 1: «Spring4Shell» (CVE-22965)
El 29 de marzo de 2022, la comunidad descubrió una serie de tuits 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 en todas las versiones de Spring Core, incluida la versión publicada más recientemente, la 5.3.17.
¿Qué aplicaciones están en riesgo?
Actualmente, solo se ha confirmado que las aplicaciones alojadas en Tomcat corren el riesgo de sufrir este nuevo exploit. Si bien no se ha demostrado que la explotación tenga éxito contra el contenedor de servlets integrado de Tomcat ni contra ninguna otra aplicación que no esté alojada en Tomcat, eso no descarta la posibilidad de que la amenaza tenga éxito en el futuro para estos marcos.
Spring publicó un anuncio oficial declaración sobre la vulnerabilidad, que aclara que se deben cumplir las siguientes condiciones para ser vulnerable, de acuerdo con la comprensión actual de la vulnerabilidad:
- JDK 9 o superior
- Apache Tomcat como contenedor de servlets
- Empaquetado como un WAR tradicional (a diferencia de un archivo ejecutable de Spring Boot)
- dependencia de spring-webmvc o spring-webflux
- Spring Framework versiones 5.3.0 a 5.3.17, 5.2.0 a 5.2.19 y versiones anteriores
¿Cómo funciona la explotación de «Spring4Shell»?
La explotación se basa en el uso de la «vinculación de datos» (org.springFramework.webbind.WebDataBinder) en las solicitudes que utilizan objetos Java antiguos y sencillos (POJO) en la firma del método:
Donde la clase Foo es una clase POJO, que podría definirse de la siguiente manera. Ten en cuenta que la clase real no es importante, siempre y cuando la cargue el cargador de clases.
Cuando una solicitud es gestionada por un método como este, el cargador de clases se utiliza 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. Determina qué archivo.jar se debe cargar cuando se usa una nueva clase.
Puede encontrar la información más actualizada y detallada sobre esta vulnerabilidad directamente desde Spring en su entrada de blog, incluidas las posibles correcciones o soluciones alternativas.
Vulnerabilidad 2: Función Spring Cloud (CVE-333322963)
El 27 de marzo de 2022, Cyber Kendra reveló detalles sobre una vulnerabilidad de ejecución remota de código (RCE) en 0 días en Spring Cloud Functions para la que no existía ningún parche. Se asignó el ID a la vulnerabilidad CVE-333322963: Vulnerabilidad de acceso a recursos de Spring Expression.
¿Qué aplicaciones están en riesgo?
La vulnerabilidad afectó a las aplicaciones en las siguientes condiciones:
- JDK 9 o más reciente
- Spring Cloud Functions 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 brinda a los desarrolladores la capacidad de configurar cómo se maneja el enrutamiento a través de la propiedad spring.cloud.function.routing-expression, generalmente mediante configuración o código. Se trata de una potente capacidad que acepta el «Spring Expression Language» (SpEL). Gracias a esta vulnerabilidad de 0 días, descubrimos que esta propiedad podía configurarse a través de los encabezados HTTP de una solicitud, lo que significaba que un atacante podía incrustar código SPel directamente en su solicitud HTTP dirigida a un punto final de RoutingFunction y, por lo tanto, ejecutar código arbitrario.
¿Qué medidas deben tomar los usuarios para mitigar el riesgo?
La primavera tiene publicado las versiones 3.1.7 y 3.2.3 abordan este problema al no permitir que esta propiedad se establezca a través de encabezados HTTP, lo que mitiga la vulnerabilidad. Tras actualizar a cualquiera de las versiones, no es necesario realizar ningún paso adicional.
¿Está interesado en obtener más información sobre cómo ayudamos a los desarrolladores a escribir código más seguro? Reserva una demostración o consulta nuestras directrices de codificación segura y gratuitas en entrenador de código seguro.
Fuentes
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Tabla de contenido
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Recursos para empezar
Secure coding learning that reflects real AI usage
Align secure coding training to real AI development activity — automatically assigning guidance to developers using AI tools, without manual intervention.Align secure coding training to real AI development activity — automatically assigning guidance to developers using AI tools, without manual intervention.
Train developers on the real risks in their code, whether human-written or AI-generated
Adaptive Learning auto-assigns targeted secure coding training to the developers introducing real vulnerabilities, reducing recurring risks at the source.Secure Code Warrior blog banner with a blue overlay over a developer working at a multi-monitor desk displaying code, alongside the headline 'Train developers on the real risks in their code.'l