Nouvelles vulnérabilités dans les bibliothèques Spring : comment déterminer si vous êtes à risque et quelles mesures prendre

Récemment, les bibliothèques Spring, l'une des bibliothèques les plus populaires de la communauté Java, ont révélé deux vulnérabilités liées à l'exécution de code à distance (RCE). Afin de vous aider à déterminer plus facilement si vous êtes exposé à l'une ou l'autre de ces vulnérabilités et quelles mesures prendre, nous avons ventilé les informations connues pour « Spring4Shell » et « Spring Cloud Function ».

Vulnérabilité 1 - « Spring4Shell » (CVE-42-22965)

Le 29 mars 2022, la communauté a identifié une série de tweets contenant des captures d'écran d'une preuve de concept d'un exploit ciblant Spring Core (SC), qui permet l'exécution de code à distance pour toutes les versions de Spring Core, y compris la version la plus récente, 5.3.17.

Quelles applications sont susceptibles d'être affectées ?

À l'heure actuelle, seules les applications hébergées sur Tomcat sont confirmées comme étant exposées à ce nouvel exploit. Bien que l'exploitation n'ait pas été démontrée comme efficace contre le conteneur de servlet Tomcat intégré ou toute autre application non hébergée par Tomcat, cela n'exclut pas la possibilité que la menace s'avère efficace à l'avenir pour ces frameworks.

Spring a publié un communiqué officiel concernant la vulnérabilité, précisant que les conditions suivantes doivent être remplies pour qu'il y ait vulnérabilité, selon la compréhension actuelle de la vulnérabilité :

• JDK 9 ou version ultérieure
• Apache Tomcat en tant que conteneur de servlets
• Emballé sous forme de fichier WAR traditionnel (contrairement à un fichier jar exécutable Spring Boot)
• dépendance spring-webmvc ou spring-webflux
• Versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et versions antérieures de Spring Framework

Comment fonctionne l'exploitation « Spring4Shell » ?

L'exploitation repose sur l'utilisation de la « liaison de données » (org.springframework.web.bind.WebDataBinder) dans les requêtes qui utilisent de vieux objets Java simples (POJO) dans la signature de la méthode :

La classe Foo est une classe POJO, qui pourrait être définie comme suit. Veuillez noter que la classe elle-même n'est pas importante, tant qu'elle est chargée par le chargeur de classes.

Lorsqu'une requête est traitée par une méthode telle que celle-ci, le chargeur de classes est utilisé pour résoudre la classe. Le chargeur de classes est chargé de charger les classes au moment de l'exécution, sans avoir à précharger tous les types possibles en mémoire au préalable. Il détermine quel fichier .jar charger lorsqu'une nouvelle classe est utilisée.

Les informations les plus récentes et détaillées concernant cette vulnérabilité sont disponibles directement auprès de Spring sur leur blog, y compris les correctifs ou solutions de contournement potentiels.

Vulnérabilité 2 : Fonctionnalité Spring Cloud (CVE-249 22963)

Le 27 mars 2022, Cyber Kendra a publié des informations concernant une vulnérabilité d'exécution de code à distance (RCE) de type 0-day dans Spring Cloud Functions, pour laquelle aucun correctif n'existait. L'ID CVE-04-22963 a été attribué à cette vulnérabilité : Vulnérabilité d'accès aux ressources dans Spring Expression.

Quelles applications sont susceptibles d'être affectées ?

La vulnérabilité a affecté 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 version non prise en charge

Comment fonctionne l'exploitation ?

Spring Cloud Function permet aux développeurs de configurer la manière dont le routage est géré 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 qui accepte le « Spring Expression Language » (SPel). Grâce à cette vulnérabilité 0-day, nous avons découvert que cette propriété pouvait être définie via les en-têtes HTTP d'une requête, ce qui signifie qu'un attaquant pouvait intégrer du code SPEL directement dans sa requête HTTP vers un point de terminaison RoutingFunction, et ainsi exécuter du code arbitraire.

Quelles mesures les utilisateurs doivent-ils prendre pour réduire les risques ?

Le printemps a publié les versions 3.1.7 et 3.2.3 afin de résoudre ce problème en désactivant la définition de cette propriété via les en-têtes HTTP, ce qui atténue la vulnérabilité. Après la mise à niveau vers l'une ou l'autre de ces versions, aucune étape supplémentaire n'est nécessaire.

Souhaitez-vous en savoir plus sur la manière dont nous aidons les développeurs à écrire du code plus sécurisé ? Veuillez réserver une démonstration ou explorer nos directives de codage sécurisé gratuites sur coach de code sécurisé.

‍

Sources d'information

• 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/

‍