Nuevas vulnerabilidades en las bibliotecas de Spring: cómo saber si está en riesgo y qué hacer
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
- 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 librerías Spring, una de las más populares en la comunidad Java, han revelado 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 si lo estás.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
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
- 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 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
- 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 siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
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
- 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/
Índice
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
.png)
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
