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

Récemment, les bibliothèques Spring, parmi 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 de ces vulnérabilités et quelles mesures prendre, nous avons décrypté les détails connus concernant « Spring4Shell » et « Spring Cloud Function ».

Vulnérabilité 1 - « Spring4Shell » (CVE-2022-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'une exploitation ciblant Spring Core (SC), permettant l'exécution de code à distance sur toutes les versions de Spring Core, y compris la version la plus récente, la 5.3.17.

Quelles applications sont exposées ?

Actuellement, seules les applications hébergées sur Tomcat sont confirmées comme étant exposées à cette nouvelle exploitation. Bien que l'exploitation n'ait pas été démontrée comme réussie contre le conteneur de servlets Tomcat embarqué ou toute autre application non hébergée sur Tomcat, cela n'exclut pas la possibilité que la menace s'avère efficace à l'avenir contre ces frameworks.

Spring a publié une déclaration officielle concernant cette vulnérabilité, précisant que les conditions suivantes doivent être réunies pour être vulnérable, selon la compréhension actuelle de la faille :

• JDK 9 ou supérieur
• Apache Tomcat comme conteneur de servlets
• Packaging sous forme de WAR traditionnel (par opposition à un fichier jar exécutable Spring Boot)
• Dépendance spring-webmvc ou spring-webflux
• Versions du framework Spring 5.3.0 à 5.3.17, 5.2.0 à 5.2.19, et versions antérieures

Comment fonctionne l'exploitation « Spring4Shell » ?

L'exploitation repose sur l'utilisation du « Data Binding » (org.springframework.web.bind.WebDataBinder) dans les requêtes qui utilisent des 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 réelle n'a pas d'importance, tant qu'elle est chargée par le chargeur de classes (Class Loader).

Lorsqu'une requête est traitée par une méthode de ce type, le chargeur de classes est utilisé pour résoudre la classe. Le chargeur de classes est responsable du chargement des classes au moment de l'exécution, sans avoir à précharger tous les types possibles en mémoire. Il détermine quel fichier .jar charger lorsqu'une nouvelle classe est utilisée.

Vous pouvez trouver les informations les plus récentes et détaillées sur cette vulnérabilité directement sur le blog de Spring, incluant les correctifs potentiels ou les solutions de contournement.

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

Le 27 mars 2022, Cyber Kendra a révélé les détails d'une vulnérabilité « zero-day » d'exécution de code à distance (RCE) dans Spring Cloud Functions pour laquelle aucun correctif n'existait. La vulnérabilité a reçu l'identifiant CVE-2022-22963 : Vulnérabilité d'accès aux ressources par expression Spring.

Quelles applications sont exposées ?

La vulnérabilité affectait les applications remplissant 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 le routage via la propriété spring.cloud.function.routing-expression, généralement définie par la configuration ou le code. Cette fonctionnalité puissante accepte le langage « Spring Expression Language » (SpEL). Cette vulnérabilité zero-day a révélé que cette propriété pouvait être définie via les en-têtes HTTP d'une requête. Un attaquant pouvait donc 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 limiter les risques ?

Spring a publié les versions 3.1.7 et 3.2.3 pour corriger ce problème en empêchant la définition de cette propriété via les en-têtes HTTP, ce qui neutralise la vulnérabilité. Aucune étape supplémentaire n'est nécessaire après la mise à jour vers l'une de ces versions.

Vous souhaitez en savoir plus sur la façon dont nous aidons les développeurs à écrire un code plus sécurisé ? Réservez une démo ou explorez nos guides de codage sécurisé gratuits sur secure code coach.

‍

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/

‍