Nouvelles vulnérabilités dans les bibliothèques Spring : comment savoir si vous êtes à risque et que faire

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). Pour vous aider à déterminer plus facilement si vous êtes exposé à l'une ou l'autre des 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 découvert 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 menacées ?

Actuellement, 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 un succès 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 déclaration sur la vulnérabilité, qui précise que les conditions suivantes doivent être remplies pour être vulnérable, selon la compréhension actuelle de la vulnérabilité :

• JDK 9 ou supérieur
• 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 :

Où la classe Foo est une classe POJO, qui pourrait être définie comme suit. Notez que la classe elle-même n'est pas importante, tant qu'elle est chargée par le Class Loader.

Lorsqu'une demande est traitée par une méthode comme celle-ci, le Class Loader est utilisé pour résoudre la classe. Le Class Loader 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.

Vous pouvez trouver les informations les plus récentes et les plus détaillées sur cette vulnérabilité directement auprès de Spring sur leur billet de blog, y compris des correctifs ou des solutions de contournement potentiels.

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

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

Quelles applications sont menacé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 inférieure), 3.2.2 (ou infé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 appris que cette propriété pouvait être définie via les en-têtes HTTP d'une requête, ce qui signifiait 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 atténuer les risques ?

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

Vous souhaitez en savoir plus sur la manière dont nous aidons les développeurs à écrire du code plus sécurisé ? Réservez une démo ou explorez nos directives de codage sécurisé gratuites sur coach de code sécurisé.

‍

Sources

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

‍