Nouvelle vulnérabilité dans la bibliothèque Spring : comment déterminer si vous êtes exposé et comment y remédier

Récemment, la bibliothèque 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 clarifier si vous êtes exposé à l'une de ces vulnérabilités et quelles mesures vous devez prendre, nous avons classé les détails connus de « 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 d'une preuve de concept d'exploitation visant Spring Core (SC). Cela permet l'exécution de code à distance sur toutes les versions de Spring Core, y compris la version 5.3.17 récemment publiée.

Quelles applications sont exposées à des risques ?

À l'heure actuelle, seules les applications hébergées sur Tomcat sont confirmées comme étant exposées à cette nouvelle vulnérabilité. Aucune exploitation réussie n'a été confirmée sur le conteneur de servlets Tomcat intégré ou sur d'autres applications hébergées ailleurs que sur Tomcat, mais cela n'exclut pas la possibilité que cette menace puisse à l'avenir affecter ces frameworks.

Déclaration officielle de Spring concernant la vulnérabilité. Il est ainsi clairement établi que, selon les connaissances actuelles en matière de vulnérabilité, les conditions suivantes doivent être remplies pour qu'une vulnérabilité puisse se produire.

• JDK 9 ou version ultérieure
• Apache Tomcat en tant que conteneur de servlets
• Empaqueté comme un WAR traditionnel (contrairement au fichier jar exécutable Spring Boot)
• Spring Web MVC ou Spring Web Flux dépendances
• Spring Framework versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et versions antérieures

Comment fonctionne l'exploit « Spring4Shell » ?

Cette exploitation repose sur l'utilisation de la « liaison de données » (org.springFramework.web.bind.WebDataBinder) dans les requêtes utilisant des objets Java simples (POJO) dans la signature de méthode.

Ici, la classe Foo est une classe POJO et peut être définie comme suit. Veuillez noter que tant que la classe est chargée par le chargeur de classes, la classe réelle n'a pas d'importance.

Lorsque les requêtes sont traitées à l'aide de cette méthode, les classes sont résolues à l'aide du chargeur de classes. Le chargeur de classes charge les classes lors de l'exécution sans avoir à précharger au préalable tous les types possibles dans la mémoire. Le fichier .jar à charger est déterminé au moment où 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. Le billet de blogcontient des corrections ou des solutions de contournement potentielles.

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

Le 27 mars 2022, CyberKendra a publié des informations détaillées concernant une vulnérabilité de type « remote code execution » (RCE) de type « zero-day » dans Spring Cloud Functions, pour laquelle aucun correctif n'est disponible. Cette vulnérabilité a reçu l'identifiant CVE-2022-22963 : Vulnérabilité d'accès aux ressources Spring Expression.

Quelles applications sont exposées à des risques ?

Cette vulnérabilité a affecté l'application 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

Quel est le mécanisme d'exploitation ?

Dans Spring Cloud Function, les développeurs peuvent configurer le traitement du routage à l'aide de la propriété spring.cloud.function.routing-expression. Cela se fait généralement à l'aide de paramètres ou de code.Il s'agit d'une fonctionnalité puissante qui accepte le langage d'expression Spring (SpEL). Cette vulnérabilité a révélé que cette propriété pouvait être configurée via l'en-tête HTTP de la requête. Cela signifie qu'un attaquant pourrait intégrer directement du code SpL dans une requête HTTP vers le point de terminaison RoutingFunction et exécuter du code arbitraire.

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

Au printemps, les versions 3.1.7 et 3.2.3 ont été publiées. Elles corrigent ce problème et réduisent la vulnérabilité en empêchant la configuration de cette propriété via l'en-tête HTTP. Aucune action supplémentaire n'est requise après la mise à niveau vers l'une de ces versions.

Souhaitez-vous en savoir plus sur la manière dont nous aidons les développeurs à écrire un code plus sécurisé ? Veuillezprendre rendez-vous pour une démonstration ou consultez gratuitement les directives de codage sécurisé dans Secure Code Coach.

‍

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

‍