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

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). Afin de vous aider à mieux comprendre si vous êtes exposé à l'une de ces vulnérabilités et quelles mesures vous devez prendre, nous avons détaillé les informations connues concernant « Spring4Shell » et « Spring Cloud Function ».

Vulnérabilité 1 : « Spring4Shell » (CVE-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 à distance de code sur toutes les versions de Spring Core, y compris la version la plus récente, la 5.3.17.

Quelles applications sont concernées ?

À l'heure actuelle, il a été confirmé que seules les applications hébergées sur Tomcat sont susceptibles d'être affectées par cette nouvelle faille. Bien qu'il n'ait pas été démontré que l'exploitation de cette faille ait réussi contre le conteneur de servlets intégré de Tomcat ou contre toute autre application non hébergée sur Tomcat, cela n'exclut pas la possibilité que la menace réussisse à l'avenir pour ces frameworks.

Spring a publié une déclaration officielle 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 supérieur
• Apache Tomcat en tant que conteneur de servlets
• Empaquetado como un WAR tradicional (a diferencia de un archivo ejecutable de Spring Boot)
• dépendance de spring-webmvc ou spring-webflux
• Versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et versions antérieures du framework Spring

Comment fonctionne l'exploitation de « Spring4Shell » ?

L'exploitation repose sur l'utilisation du « lient de données » (org.springFramework.webbind.WebDataBinder) dans les requêtes qui utilisent des objets Java simples et anciens (POJO) dans la signature de la méthode :

Où la classe Foo est une classe POJO, qui pourrait être définie de la manière suivante. Veuillez noter que la classe réelle n'a pas d'importance, tant qu'elle est chargée par le chargeur de classes.

Lorsqu'une requête est géré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 au préalable tous les types possibles en mémoire. Il détermine quel fichier .jar doit être chargé 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 auprès de Spring dans son article de blog, y compris les correctifs ou solutions alternatives possibles.

Vulnérabilité 2 : Fonction Spring Cloud (CVE-333322963)

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

Quelles applications sont concerné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 autre version non compatible

Comment fonctionne l'exploitation ?

Spring Cloud Function offre aux développeurs la possibilité de configurer la gestion du routage via la propriété spring.cloud.function.routing-expression, généralement par le biais d'une configuration ou d'un code. Il s'agit d'une fonctionnalité puissante qui prend en charge le « Spring Expression Language » (SpEL). Grâce à cette vulnérabilité zero-day, nous avons découvert que cette propriété pouvait être configurée 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 adressée à un point de terminaison RoutingFunction et ainsi exécuter du code arbitraire.

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

La primavera a publié les versions 3.1.7 et 3.2.3 qui résolvent ce problème en empêchant cette propriété d'être définie via des en-têtes HTTP, ce qui atténue la vulnérabilité. Après avoir effectué la mise à jour vers l'une de ces versions, aucune autre action 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 nos directives de codage sécurisé gratuites sur le formateur de codage sécurisé.

‍

Fuentes

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

‍