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

Récemment, 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 vous aider à mieux comprendre si vous êtes exposé à ces vulnérabilités et quelles mesures prendre, nous avons détaillé les informations connues sur « 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 illustrant une preuve de concept de vulnérabilité dans Spring Core (SC). Cette vulnérabilité permet l'exécution à distance de code Spring Core sur toutes les versions, y compris la version 5.3.17 récemment publiée.

Quelles applications sont concernées par ce risque ?

À l'heure actuelle, seules les applications hébergées sur Tomcat ont été identifiées comme étant exposées à cette nouvelle vulnérabilité. Bien qu'aucune attaque visant le conteneur Tomcat Servlet intégré ou toute autre application non hébergée par Tomcat n'ait encore été confirmée, cela n'exclut pas la possibilité que ces cadres soient utilisés avec succès à l'avenir.

Au printemps, une déclaration officielle a été publiée concernant cette vulnérabilité. D'après les connaissances actuelles sur cette vulnérabilité, il est précisé que les conditions suivantes doivent être réunies pour qu'une attaque puisse avoir lieu :

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

Comment fonctionne la faille « Spring4Shell » ?

Cette vulnérabilité dépend de l'utilisation de « data binding » (org.springframework.web.bind.Web.bind.WebDataBinder) dans les requêtes utilisant des objets Java ordinaires (POJO) dans la signature de la méthode :

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

Lorsque la requête est traitée par cette méthode, le chargeur de classes est utilisé pour analyser la classe. Le chargeur de classes est responsable du chargement des classes lors de l'exécution, sans avoir à précharger tous les types possibles dans la mémoire. Il détermine quel fichier .jar doit être chargé lors de l'utilisation d'une nouvelle classe.

Vous pouvez trouver des informations récentes et détaillées sur cette vulnérabilité directement sur Spring, notamment des articles de blogincluant des correctifs potentiels ou des solutions de contournement.

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

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

Quelles applications sont concernées par ce risque ?

Cette vulnérabilité affecte 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 prise en charge

Comment fonctionne l'exploitation ?

Spring Cloud Function permet aux développeurs de configurer le traitement du routage 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 de « Spring Expression Language » (SpEL). Grâce à cette vulnérabilité de type « zero-day », nous avons découvert que cette propriété peut être définie via l'en-tête HTTP de la requête, ce qui signifie qu'un attaquant peut intégrer directement du code SpEL dans la requête HTTP de son point de terminaison RoutingFunction, et ainsi exécuter du code arbitraire.

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

Les versions 3.1.7 et 3.2.3 publiées au printemps ont résolu ce problème en empêchant la configuration de cette propriété via l'en-tête HTTP, ce qui a permis de pallier la vulnérabilité. Après la mise à niveau vers l'une ou l'autre de ces versions, aucune autre mesure 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 notre guide gratuit sur le codage sécurisé , le Coach de codage sécurisé.

‍

Source

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

‍