Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Spring4Shell

hacking

Définition

Spring4Shell (CVE-2022-22965) est une vulnérabilité de désérialisation Java dans Spring Framework permettant l'exécution de code à distance sur des applications Spring MVC ou Spring WebFlux déployées sur Tomcat avec JDK 9+. Divulguée en mars 2022 dans un contexte de comparaisons avec Log4Shell, elle présente un niveau de complexité d'exploitation plus élevé mais un impact similaire. La vulnérabilité exploite le mécanisme de DataBinding de Spring : quand Spring mappe des paramètres HTTP vers des objets Java, il peut traverser la hiérarchie d'objets via des expressions comme class.module.classLoader.URLs[0]. Sur Tomcat, cela permet de modifier la configuration du ClassLoader pour déployer une webshell JSP dans le répertoire ROOT de Tomcat. Les conditions d'exploitation : JDK 9 ou supérieur (qui expose l'API de module), déploiement sur Tomcat (pas sur d'autres containers comme Jetty ou Undertow), et Spring MVC ou WebFlux avec des endpoints acceptant des paramètres liés à des objets Plain Old Java Object (POJO). L'exploitation écrit une webshell JSP en modifiant les paramètres du ClassLoader Tomcat via des requêtes GET/POST avec des paramètres spécialement construits. La webshell est accessible depuis le navigateur et permet l'exécution de commandes OS. Des PoCs publics (comme CVE-2022-22965-PoC sur GitHub) automatisent l'exploitation. Spring a corrigé la vulnérabilité dans Spring Framework 5.3.18 et 5.2.20. La mitigation temporaire consiste à restreindre les DataBinders pour exclure les propriétés 'class' des objets liables.

Fonctionnement

Exploitation via requêtes HTTP : des paramètres comme class.module.classLoader.URLs[0]=jar:file:///tmp/hack.jar!/ modifient le ClassLoader Tomcat. Puis des paramètres class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bc2%7Di... configurent le AccessLogValve de Tomcat pour écrire dans un fichier .jsp accessible. La webshell est déployée en quelques requêtes HTTP sans authentification (si l'endpoint Spring est public).

Exploitation offensive

Spring4Shell cible les applications Spring modernes (framework très répandu en Java enterprise), en particulier celles qui utilisent Spring MVC avec des objets complexes en DataBinding. L'impact est RCE sur le serveur d'application avec les privilèges du processus Tomcat. Des applications SaaS et des microservices basés sur Spring Boot ont été vulnérables.

Détection et mitigation

Mettre à jour Spring Framework vers 5.3.18+ ou 5.2.20+. Ajouter un DataBinder init binder global qui refuse les patterns 'class' et 'module' : binder.setDisallowedFields('class.*', 'module.*', 'classLoader.*'). Les WAF avec des signatures Spring4Shell (patterns class.module.classLoader dans les paramètres) bloquent les exploitations connues.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis