Nouvelles vulnérabilités dans Spring : comment déterminer si vous êtes concerné et quelles mesures prendre
Récemment, Spring, l'une des bibliothèques les plus populaires de la communauté Java, a révélé deux vulnérabilités liées à l'exécution de code à distance (RCE). Afin de vous aider à mieux comprendre si vous êtes exposé à ces vulnérabilités et quelles mesures prendre, nous avons détaillé les informations connues sur « Spring4Shell » et « Spring Cloud Function ».
Vulnérabilité 1 - « Spring4Shell » (CVE-2022-22965)
Le 29 mars 2022, la communauté a identifié une série de tweets contenant des captures d'écran illustrant une preuve de concept de vulnérabilité dans Spring Core (SC). Cette vulnérabilité permet l'exécution à distance de code Spring Core sur toutes les versions, y compris la version 5.3.17 récemment publiée.
Quelles applications sont concernées par ce risque ?
À l'heure actuelle, seules les applications hébergées sur Tomcat ont été identifiées comme étant exposées à cette nouvelle vulnérabilité. Bien qu'aucune attaque visant le conteneur Tomcat Servlet intégré ou toute autre application non hébergée par Tomcat n'ait encore été confirmée, cela n'exclut pas la possibilité que ces cadres soient utilisés avec succès à l'avenir.
Au printemps, une déclaration officielle a été publiée concernant cette vulnérabilité. D'après les connaissances actuelles sur cette vulnérabilité, il est précisé que les conditions suivantes doivent être réunies pour qu'une attaque puisse avoir lieu :
- JDK 9 ou version ultérieure
- Apache Tomcat en tant que conteneur de servlets
- Empaqueté sous forme de WAR traditionnel (contrairement au fichier jar exécutable Spring Boot)
- Dépendances Spring-webmvc ou Spring-webflux
- Spring Framework versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et versions antérieures
Comment fonctionne la faille « Spring4Shell » ?
Cette vulnérabilité dépend de l'utilisation de « data binding » (org.springframework.web.bind.Web.bind.WebDataBinder) dans les requêtes utilisant des objets Java ordinaires (POJO) dans la signature de la méthode :
La classe Foo est une classe POJO qui peut être définie comme suit. Veuillez noter que la classe réelle n'a pas d'importance, tant qu'elle est chargée par le chargeur de classes.
Lorsque la requête est traitée par cette méthode, le chargeur de classes est utilisé pour analyser la classe. Le chargeur de classes est responsable du chargement des classes lors de l'exécution, sans avoir à précharger tous les types possibles dans la mémoire. Il détermine quel fichier .jar doit être chargé lors de l'utilisation d'une nouvelle classe.
Vous pouvez trouver des informations récentes et détaillées sur cette vulnérabilité directement sur Spring, notamment des articles de blogincluant des correctifs potentiels ou des solutions de contournement.
Vulnérabilité 2 - Fonction Spring Cloud (CVE-2022-22963)
Le 27 mars 2022, Cyber Kendra a publié des informations détaillées concernant une vulnérabilité d'exécution de code à distance (RCE) de type « zero-day » dans Spring Cloud Functions, pour laquelle aucun correctif n'est encore disponible. Cette vulnérabilité a reçu l'identifiant CVE-2022-22963 : vulnérabilité d'accès aux ressources d'expression Spring.
Quelles applications sont concernées par ce risque ?
Cette vulnérabilité affecte les applications dans les conditions suivantes :
- JDK 9 ou version ultérieure
- Spring Cloud Functions version 3.1.6 (ou antérieure), 3.2.2 (ou antérieure) ou toute autre version non prise en charge
Comment fonctionne l'exploitation ?
Spring Cloud Function permet aux développeurs de configurer le traitement du routage via la propriété spring.cloud.function.routing-expression, généralement via la configuration ou le code. Il s'agit d'une fonctionnalité puissante de « Spring Expression Language » (SpEL). Grâce à cette vulnérabilité de type « zero-day », nous avons découvert que cette propriété peut être définie via l'en-tête HTTP de la requête, ce qui signifie qu'un attaquant peut intégrer directement du code SpEL dans la requête HTTP de son point de terminaison RoutingFunction, et ainsi exécuter du code arbitraire.
Quelles mesures les utilisateurs devraient-ils prendre pour réduire les risques ?
Les versions 3.1.7 et 3.2.3 publiées au printemps ont résolu ce problème en empêchant la configuration de cette propriété via l'en-tête HTTP, ce qui a permis de pallier la vulnérabilité. Après la mise à niveau vers l'une ou l'autre de ces versions, aucune autre mesure n'est nécessaire.
Souhaitez-vous en savoir plus sur la manière dont nous aidons les développeurs à écrire un code plus sécurisé ?Veuillez réserver une démonstration ou consulter notre guide gratuit sur le codage sécurisé , le Coach de codage sécurisé.
Source
- 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/
Récemment, Spring, l'une des bibliothèques les plus populaires de la communauté Java, a révélé deux vulnérabilités liées à l'exécution de code à distance (RCE). Nous avons analysé les détails connus de « Spring4Shell » et « Spring Cloud Function » afin de vous aider à déterminer si vous êtes exposé à un risque et, le cas échéant, comment y remédier.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
Récemment, Spring, l'une des bibliothèques les plus populaires de la communauté Java, a révélé deux vulnérabilités liées à l'exécution de code à distance (RCE). Afin de vous aider à mieux comprendre si vous êtes exposé à ces vulnérabilités et quelles mesures prendre, nous avons détaillé les informations connues sur « Spring4Shell » et « Spring Cloud Function ».
Vulnérabilité 1 - « Spring4Shell » (CVE-2022-22965)
Le 29 mars 2022, la communauté a identifié une série de tweets contenant des captures d'écran illustrant une preuve de concept de vulnérabilité dans Spring Core (SC). Cette vulnérabilité permet l'exécution à distance de code Spring Core sur toutes les versions, y compris la version 5.3.17 récemment publiée.
Quelles applications sont concernées par ce risque ?
À l'heure actuelle, seules les applications hébergées sur Tomcat ont été identifiées comme étant exposées à cette nouvelle vulnérabilité. Bien qu'aucune attaque visant le conteneur Tomcat Servlet intégré ou toute autre application non hébergée par Tomcat n'ait encore été confirmée, cela n'exclut pas la possibilité que ces cadres soient utilisés avec succès à l'avenir.
Au printemps, une déclaration officielle a été publiée concernant cette vulnérabilité. D'après les connaissances actuelles sur cette vulnérabilité, il est précisé que les conditions suivantes doivent être réunies pour qu'une attaque puisse avoir lieu :
- JDK 9 ou version ultérieure
- Apache Tomcat en tant que conteneur de servlets
- Empaqueté sous forme de WAR traditionnel (contrairement au fichier jar exécutable Spring Boot)
- Dépendances Spring-webmvc ou Spring-webflux
- Spring Framework versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et versions antérieures
Comment fonctionne la faille « Spring4Shell » ?
Cette vulnérabilité dépend de l'utilisation de « data binding » (org.springframework.web.bind.Web.bind.WebDataBinder) dans les requêtes utilisant des objets Java ordinaires (POJO) dans la signature de la méthode :
La classe Foo est une classe POJO qui peut être définie comme suit. Veuillez noter que la classe réelle n'a pas d'importance, tant qu'elle est chargée par le chargeur de classes.
Lorsque la requête est traitée par cette méthode, le chargeur de classes est utilisé pour analyser la classe. Le chargeur de classes est responsable du chargement des classes lors de l'exécution, sans avoir à précharger tous les types possibles dans la mémoire. Il détermine quel fichier .jar doit être chargé lors de l'utilisation d'une nouvelle classe.
Vous pouvez trouver des informations récentes et détaillées sur cette vulnérabilité directement sur Spring, notamment des articles de blogincluant des correctifs potentiels ou des solutions de contournement.
Vulnérabilité 2 - Fonction Spring Cloud (CVE-2022-22963)
Le 27 mars 2022, Cyber Kendra a publié des informations détaillées concernant une vulnérabilité d'exécution de code à distance (RCE) de type « zero-day » dans Spring Cloud Functions, pour laquelle aucun correctif n'est encore disponible. Cette vulnérabilité a reçu l'identifiant CVE-2022-22963 : vulnérabilité d'accès aux ressources d'expression Spring.
Quelles applications sont concernées par ce risque ?
Cette vulnérabilité affecte les applications dans les conditions suivantes :
- JDK 9 ou version ultérieure
- Spring Cloud Functions version 3.1.6 (ou antérieure), 3.2.2 (ou antérieure) ou toute autre version non prise en charge
Comment fonctionne l'exploitation ?
Spring Cloud Function permet aux développeurs de configurer le traitement du routage via la propriété spring.cloud.function.routing-expression, généralement via la configuration ou le code. Il s'agit d'une fonctionnalité puissante de « Spring Expression Language » (SpEL). Grâce à cette vulnérabilité de type « zero-day », nous avons découvert que cette propriété peut être définie via l'en-tête HTTP de la requête, ce qui signifie qu'un attaquant peut intégrer directement du code SpEL dans la requête HTTP de son point de terminaison RoutingFunction, et ainsi exécuter du code arbitraire.
Quelles mesures les utilisateurs devraient-ils prendre pour réduire les risques ?
Les versions 3.1.7 et 3.2.3 publiées au printemps ont résolu ce problème en empêchant la configuration de cette propriété via l'en-tête HTTP, ce qui a permis de pallier la vulnérabilité. Après la mise à niveau vers l'une ou l'autre de ces versions, aucune autre mesure n'est nécessaire.
Souhaitez-vous en savoir plus sur la manière dont nous aidons les développeurs à écrire un code plus sécurisé ?Veuillez réserver une démonstration ou consulter notre guide gratuit sur le codage sécurisé , le Coach de codage sécurisé.
Source
- 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/
Récemment, Spring, l'une des bibliothèques les plus populaires de la communauté Java, a révélé deux vulnérabilités liées à l'exécution de code à distance (RCE). Afin de vous aider à mieux comprendre si vous êtes exposé à ces vulnérabilités et quelles mesures prendre, nous avons détaillé les informations connues sur « Spring4Shell » et « Spring Cloud Function ».
Vulnérabilité 1 - « Spring4Shell » (CVE-2022-22965)
Le 29 mars 2022, la communauté a identifié une série de tweets contenant des captures d'écran illustrant une preuve de concept de vulnérabilité dans Spring Core (SC). Cette vulnérabilité permet l'exécution à distance de code Spring Core sur toutes les versions, y compris la version 5.3.17 récemment publiée.
Quelles applications sont concernées par ce risque ?
À l'heure actuelle, seules les applications hébergées sur Tomcat ont été identifiées comme étant exposées à cette nouvelle vulnérabilité. Bien qu'aucune attaque visant le conteneur Tomcat Servlet intégré ou toute autre application non hébergée par Tomcat n'ait encore été confirmée, cela n'exclut pas la possibilité que ces cadres soient utilisés avec succès à l'avenir.
Au printemps, une déclaration officielle a été publiée concernant cette vulnérabilité. D'après les connaissances actuelles sur cette vulnérabilité, il est précisé que les conditions suivantes doivent être réunies pour qu'une attaque puisse avoir lieu :
- JDK 9 ou version ultérieure
- Apache Tomcat en tant que conteneur de servlets
- Empaqueté sous forme de WAR traditionnel (contrairement au fichier jar exécutable Spring Boot)
- Dépendances Spring-webmvc ou Spring-webflux
- Spring Framework versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et versions antérieures
Comment fonctionne la faille « Spring4Shell » ?
Cette vulnérabilité dépend de l'utilisation de « data binding » (org.springframework.web.bind.Web.bind.WebDataBinder) dans les requêtes utilisant des objets Java ordinaires (POJO) dans la signature de la méthode :
La classe Foo est une classe POJO qui peut être définie comme suit. Veuillez noter que la classe réelle n'a pas d'importance, tant qu'elle est chargée par le chargeur de classes.
Lorsque la requête est traitée par cette méthode, le chargeur de classes est utilisé pour analyser la classe. Le chargeur de classes est responsable du chargement des classes lors de l'exécution, sans avoir à précharger tous les types possibles dans la mémoire. Il détermine quel fichier .jar doit être chargé lors de l'utilisation d'une nouvelle classe.
Vous pouvez trouver des informations récentes et détaillées sur cette vulnérabilité directement sur Spring, notamment des articles de blogincluant des correctifs potentiels ou des solutions de contournement.
Vulnérabilité 2 - Fonction Spring Cloud (CVE-2022-22963)
Le 27 mars 2022, Cyber Kendra a publié des informations détaillées concernant une vulnérabilité d'exécution de code à distance (RCE) de type « zero-day » dans Spring Cloud Functions, pour laquelle aucun correctif n'est encore disponible. Cette vulnérabilité a reçu l'identifiant CVE-2022-22963 : vulnérabilité d'accès aux ressources d'expression Spring.
Quelles applications sont concernées par ce risque ?
Cette vulnérabilité affecte les applications dans les conditions suivantes :
- JDK 9 ou version ultérieure
- Spring Cloud Functions version 3.1.6 (ou antérieure), 3.2.2 (ou antérieure) ou toute autre version non prise en charge
Comment fonctionne l'exploitation ?
Spring Cloud Function permet aux développeurs de configurer le traitement du routage via la propriété spring.cloud.function.routing-expression, généralement via la configuration ou le code. Il s'agit d'une fonctionnalité puissante de « Spring Expression Language » (SpEL). Grâce à cette vulnérabilité de type « zero-day », nous avons découvert que cette propriété peut être définie via l'en-tête HTTP de la requête, ce qui signifie qu'un attaquant peut intégrer directement du code SpEL dans la requête HTTP de son point de terminaison RoutingFunction, et ainsi exécuter du code arbitraire.
Quelles mesures les utilisateurs devraient-ils prendre pour réduire les risques ?
Les versions 3.1.7 et 3.2.3 publiées au printemps ont résolu ce problème en empêchant la configuration de cette propriété via l'en-tête HTTP, ce qui a permis de pallier la vulnérabilité. Après la mise à niveau vers l'une ou l'autre de ces versions, aucune autre mesure n'est nécessaire.
Souhaitez-vous en savoir plus sur la manière dont nous aidons les développeurs à écrire un code plus sécurisé ?Veuillez réserver une démonstration ou consulter notre guide gratuit sur le codage sécurisé , le Coach de codage sécurisé.
Source
- 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/
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez consulter le rapport.Veuillez réserver une démonstration.
Récemment, Spring, l'une des bibliothèques les plus populaires de la communauté Java, a révélé deux vulnérabilités liées à l'exécution de code à distance (RCE). Afin de vous aider à mieux comprendre si vous êtes exposé à ces vulnérabilités et quelles mesures prendre, nous avons détaillé les informations connues sur « Spring4Shell » et « Spring Cloud Function ».
Vulnérabilité 1 - « Spring4Shell » (CVE-2022-22965)
Le 29 mars 2022, la communauté a identifié une série de tweets contenant des captures d'écran illustrant une preuve de concept de vulnérabilité dans Spring Core (SC). Cette vulnérabilité permet l'exécution à distance de code Spring Core sur toutes les versions, y compris la version 5.3.17 récemment publiée.
Quelles applications sont concernées par ce risque ?
À l'heure actuelle, seules les applications hébergées sur Tomcat ont été identifiées comme étant exposées à cette nouvelle vulnérabilité. Bien qu'aucune attaque visant le conteneur Tomcat Servlet intégré ou toute autre application non hébergée par Tomcat n'ait encore été confirmée, cela n'exclut pas la possibilité que ces cadres soient utilisés avec succès à l'avenir.
Au printemps, une déclaration officielle a été publiée concernant cette vulnérabilité. D'après les connaissances actuelles sur cette vulnérabilité, il est précisé que les conditions suivantes doivent être réunies pour qu'une attaque puisse avoir lieu :
- JDK 9 ou version ultérieure
- Apache Tomcat en tant que conteneur de servlets
- Empaqueté sous forme de WAR traditionnel (contrairement au fichier jar exécutable Spring Boot)
- Dépendances Spring-webmvc ou Spring-webflux
- Spring Framework versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et versions antérieures
Comment fonctionne la faille « Spring4Shell » ?
Cette vulnérabilité dépend de l'utilisation de « data binding » (org.springframework.web.bind.Web.bind.WebDataBinder) dans les requêtes utilisant des objets Java ordinaires (POJO) dans la signature de la méthode :
La classe Foo est une classe POJO qui peut être définie comme suit. Veuillez noter que la classe réelle n'a pas d'importance, tant qu'elle est chargée par le chargeur de classes.
Lorsque la requête est traitée par cette méthode, le chargeur de classes est utilisé pour analyser la classe. Le chargeur de classes est responsable du chargement des classes lors de l'exécution, sans avoir à précharger tous les types possibles dans la mémoire. Il détermine quel fichier .jar doit être chargé lors de l'utilisation d'une nouvelle classe.
Vous pouvez trouver des informations récentes et détaillées sur cette vulnérabilité directement sur Spring, notamment des articles de blogincluant des correctifs potentiels ou des solutions de contournement.
Vulnérabilité 2 - Fonction Spring Cloud (CVE-2022-22963)
Le 27 mars 2022, Cyber Kendra a publié des informations détaillées concernant une vulnérabilité d'exécution de code à distance (RCE) de type « zero-day » dans Spring Cloud Functions, pour laquelle aucun correctif n'est encore disponible. Cette vulnérabilité a reçu l'identifiant CVE-2022-22963 : vulnérabilité d'accès aux ressources d'expression Spring.
Quelles applications sont concernées par ce risque ?
Cette vulnérabilité affecte les applications dans les conditions suivantes :
- JDK 9 ou version ultérieure
- Spring Cloud Functions version 3.1.6 (ou antérieure), 3.2.2 (ou antérieure) ou toute autre version non prise en charge
Comment fonctionne l'exploitation ?
Spring Cloud Function permet aux développeurs de configurer le traitement du routage via la propriété spring.cloud.function.routing-expression, généralement via la configuration ou le code. Il s'agit d'une fonctionnalité puissante de « Spring Expression Language » (SpEL). Grâce à cette vulnérabilité de type « zero-day », nous avons découvert que cette propriété peut être définie via l'en-tête HTTP de la requête, ce qui signifie qu'un attaquant peut intégrer directement du code SpEL dans la requête HTTP de son point de terminaison RoutingFunction, et ainsi exécuter du code arbitraire.
Quelles mesures les utilisateurs devraient-ils prendre pour réduire les risques ?
Les versions 3.1.7 et 3.2.3 publiées au printemps ont résolu ce problème en empêchant la configuration de cette propriété via l'en-tête HTTP, ce qui a permis de pallier la vulnérabilité. Après la mise à niveau vers l'une ou l'autre de ces versions, aucune autre mesure n'est nécessaire.
Souhaitez-vous en savoir plus sur la manière dont nous aidons les développeurs à écrire un code plus sécurisé ?Veuillez réserver une démonstration ou consulter notre guide gratuit sur le codage sécurisé , le Coach de codage sécurisé.
Source
- 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/
Table des matières
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
La puissance de la sécurité des applications OpenText + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Formation sur les codes de sécurité : thèmes et contenu
Notre contenu de pointe évolue constamment pour s'adapter au paysage changeant du développement logiciel, tout en tenant compte de votre rôle. Les sujets abordés couvrent tout, de l'IA à l'injection XQuery, et s'adressent à divers postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu par thème et par rôle de ce que notre catalogue de contenu a à offrir.
Ressources pour vous aider à démarrer
Cybermon est de retour : la mission AI pour vaincre le boss est désormais disponible sur demande.
Cybermon 2025 : la campagne « Vaincre le boss » est désormais disponible toute l'année dans SCW. La guerre de sécurité avancée de l'IA/LLM tribale, le renforcement de l'IA de sécurité à grande échelle.
Interprétation de la loi sur la résilience des réseaux : que signifie la sécurité par le biais de la conception et du développement de logiciels ?
Comprenez les exigences de la loi européenne sur la résilience des réseaux (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent s'y préparer grâce à des pratiques de conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facteur déterminant 1 : des critères de réussite clairs et mesurables
Le catalyseur n° 1 constitue le premier volet de notre série en dix parties consacrée aux facteurs de réussite. Il démontre comment relier la sécurité du code aux résultats opérationnels, tels que la réduction des risques et l'accélération de la maturité des programmes à long terme.