meng-security/spring4shell-local-verification-labSpring Framework CVE-2022-22965 本地影响条件验证、版本升级修复与复测项目
Ce projet permet d'apprendre et de valider la vulnérabilité CVE-2022-22965 du framework Spring, également connue sous le nom de Spring4Shell, en ce qui concerne les conditions d'impact, les manifestations de risque, les méthodes de correction et le processus de re-test après correction.
Le projet a été réalisé dans un environnement local autorisé et mis en place personnellement. L'accent n'est pas mis sur l'attaque de cibles réelles, mais sur la construction d'environnements de test Spring MVC avant et après correction, la vérification point par point des conditions d'impact liées à la vulnérabilité, et l'observation sécurisée et en lecture seule des différences dans les chemins de propriétés internes du binding de données Spring avant et après la mise à niveau de version.
Ce projet a réalisé les étapes suivantes :
Ce projet est destiné uniquement à un environnement local personnel ou à un environnement de test de sécurité explicitement autorisé.
Le projet n'effectue aucune analyse, détection ou exploitation de vulnérabilité sur des sites web publics, serveurs ou systèmes métier tiers, et ne contient aucune donnée utilisateur réelle ni donnée métier réelle.
Pendant le test, les opérations suivantes n'ont pas été effectuées :
Il est interdit d'utiliser les méthodes de test de ce projet sur une cible non autorisée.
CVE-2022-22965, communément appelée Spring4Shell, est une vulnérabilité d'exécution de code à distance liée au mécanisme de liaison de données (data binding) des paramètres de requête dans le framework Spring.
Spring MVC permet de lier automatiquement les paramètres de requête HTTP aux propriétés des objets Java. Par exemple, ce projet reçoit les paramètres de nom et d'email via :
@ModelAttribute("profile") UserProfile profile
Normalement, les paramètres de requête name et email sont liés à l'objet UserProfile en fonction du nom de la propriété.
Dans les versions affectées, les restrictions d'accès à certains chemins de propriétés internes ne sont pas assez strictes. Lorsque l'on utilise JDK 9 ou une version ultérieure et que des conditions spécifiques de conteneur Servlet, de mode de déploiement et de liaison de données sont remplies, les paramètres de requête externes peuvent suivre l'objet métier normal pour accéder à des objets internes liés à la classe Java, au module, au chargeur de classe ou au conteneur.
Dans un environnement exploitable particulier, un attaquant pourrait modifier la configuration du serveur ou écrire des fichiers sur le serveur, créant ainsi un risque d'exécution de code à distance.
Ce projet n'effectue pas d'exploitation de code à distance complète, mais utilise le chemin de propriété suivant pour un diagnostic de différence sécurisé et en lecture seule :
class.module.name
Ce projet a été réalisé dans un environnement expérimental isolé sur VMware local.
127.0.0.1Données de test des fonctionnalités normales :
Alice[email protected]Chemin de propriété pour le diagnostic de sécurité :
class.module.name
spring4shell-local-verification-lab/
README.md : Présentation du projet, approche de test, résultats de validation et explications de correctiondocs/ : Rapport de vérification des conditions d'impact locales de Spring4Shell, correction et re-testimages/ : Captures d'écran de l'environnement du projet, du processus de test et du re-testvulnerable-demo/ : Projet avant correction utilisant Spring Framework 5.3.17fixed-demo/ : Projet après correction utilisant Spring Framework 5.3.18notes/ : Notes d'apprentissage et enregistrement du processusStructure principale du code source :
config/ : Classes de configuration Spring MVC et classe d'initialisation de l'applicationcontroller/ : Contrôleur de traitement de formulaire et de diagnostic de chemin de propriétémodel/ : Classe UserProfile pour recevoir les paramètres de nom et d'emailWEB-INF/views/ : Pages JSP pour la page d'accueil, le résultat de soumission et le résultat de diagnosticCe projet a créé deux applications Spring MVC, l'une avant correction et l'autre après correction.
Répertoire du projet :
vulnerable-demo
Version utilisée :
Spring Framework 5.3.17
Fichier WAR généré :
spring4shell-vulnerable-demo.war
Adresse d'accès :
http://127.0.0.1:8080/spring4shell-vulnerable-demo/
Page de diagnostic :
http://127.0.0.1:8080/spring4shell-vulnerable-demo/binding-probe
Répertoire du projet :
fixed-demo
Version utilisée :
Spring Framework 5.3.18
Fichier WAR généré :
spring4shell-fixed-demo.war
Adresse d'accès :
http://127.0.0.1:8080/spring4shell-fixed-demo/
Page de diagnostic :
http://127.0.0.1:8080/spring4shell-fixed-demo/binding-probe
Le projet de test fournit un simple formulaire de profil utilisateur, comprenant :
Le contrôleur reçoit les paramètres de requête via :
@ModelAttribute("profile") UserProfile profile
Lorsque l'utilisateur soumet le nom et l'email, Spring MVC lie automatiquement les paramètres name et email à l'objet UserProfile.
La page de résultat lit l'objet lié et affiche le nom et l'email soumis par l'utilisateur.
Cette fonction permet de confirmer que le projet fonctionne correctement et prouve qu'il existe un point d'entrée de liaison de données de requête Spring MVC valide dans l'application.
Ce projet suit l'approche « d'abord confirmer les fonctionnalités normales, puis confirmer les conditions d'impact, ensuite effectuer un diagnostic de risque en lecture seule, enfin corriger et retester ».
UserProfile en utilisant @ModelAttribute.BeanWrapper de Spring pour effectuer un diagnostic en lecture seule de class.module.name.Ce projet a vérifié point par point les conditions d'impact suivantes :
spring-webmvc@ModelAttributeLes dépendances Spring réellement déployées dans le projet avant correction incluent :
spring-beans-5.3.17.jarspring-core-5.3.17.jarspring-web-5.3.17.jarspring-webmvc-5.3.17.jarCe projet ne juge pas directement si la vulnérabilité est présente uniquement en fonction de la version du framework Spring, mais effectue une analyse complète en combinant JDK, Spring MVC, Tomcat, le déploiement WAR et le point d'entrée de liaison de données.
Pour éviter d'effectuer une exploitation destructive de la vulnérabilité, ce projet utilise BeanWrapper fourni par Spring Framework pour effectuer une vérification en lecture seule du chemin de propriété suivant :
class.module.name
Ce chemin représente :
class : accéder à l'objet Java Class correspondant à l'objet métier courantmodule : accéder au module Java auquel appartient cette classename : lire le nom du moduleLe processus de diagnostic n'appelle que les méthodes de vérification de lisibilité de la propriété et de lecture de la valeur de la propriété :
Par conséquent, ce diagnostic ne peut être utilisé que pour observer les différences d'accès au chemin de propriété interne avant et après correction, et ne peut pas prouver à lui seul qu'une exécution de code à distance a été réalisée.
L'environnement avant correction utilise :
Spring Framework 5.3.17
Chemin de propriété vérifié :
class.module.name
Résultat du diagnostic :
truenulltrue indique que l'environnement peut continuer à analyser module.name en suivant la propriété class de l'objet métier normal.
Le résultat de la lecture est null car l'application WAR fonctionne dans le module non nommé de Java, le nom du module étant vide. Cela ne signifie pas que la lecture du chemin de propriété a échoué.
L'environnement après correction utilise :
Spring Framework 5.3.18
Même chemin de propriété pour le nouveau diagnostic :
class.module.name
Résultat du diagnostic :
falseNot readableLes résultats avant et après correction forment un contraste clair :
Ce résultat montre qu'après la mise à niveau de version, l'accès au chemin de propriété de diagnostic d'origine a été restreint et que la manifestation de risque observée avant correction n'apparaît plus.
Ce projet a adopté une correction par mise à niveau de la version du framework Spring.
Configuration avant correction :
<spring.version>5.3.17</spring.version>
Configuration après correction :
<spring.version>5.3.18</spring.version>
Les opérations suivantes ont été effectuées pendant le processus de correction :
fixed-demo.Les dépendances Spring réellement déployées dans le projet après correction incluent :
spring-beans-5.3.18.jarspring-core-5.3.18.jarspring-web-5.3.18.jarspring-webmvc-5.3.18.jarCe résultat prouve que la version corrigée a été reconstruite et réellement déployée, et non seulement que le numéro de version a été modifié dans pom.xml.
Après la mise à niveau vers Spring Framework 5.3.18, accédez à nouveau à la page d'accueil du projet corrigé et soumettez les données de test suivantes :
Alice[email protected]Après soumission, la page affiche toujours normalement :
Alice[email protected]Ce résultat montre que la mise à niveau de version n'a pas affecté la fonction normale de liaison des paramètres de requête et d'affichage de la page du projet d'origine.
Le mécanisme de liaison automatique des données de Spring MVC peut accéder aux propriétés des objets Java en fonction du nom des paramètres de requête HTTP.
Les paramètres métier normaux name et email n'ont besoin d'accéder qu'aux propriétés normales correspondantes dans UserProfile.
Cependant, le mécanisme d'accès aux propriétés de Spring prend également en charge les chemins de propriétés imbriqués avec des points. Dans les versions affectées, les restrictions d'accès à certains chemins de propriétés internes ne sont pas assez strictes, ce qui permet aux paramètres externes, dans un environnement spécifique, de passer de l'objet métier normal aux objets liés à la classe Java, au module, au chargeur de classe ou au conteneur Servlet.
Lorsque ces objets internes possèdent des propriétés inscriptibles qui peuvent affecter la configuration du serveur ou le système de fichiers, et que l'application remplit simultanément les conditions JDK, Tomcat, déploiement WAR et liaison de données, un risque d'exécution de code à distance peut se former.
Cette vulnérabilité n'est pas due à un problème avec les propriétés name ou email elles-mêmes, et tous les projets utilisant Spring MVC ne sont pas nécessairement exploitables. La présence de la vulnérabilité nécessite généralement la coexistence de plusieurs conditions.
Dans les systèmes métier réels, il est recommandé de prendre les mesures suivantes :
Ce projet a réalisé dans un environnement local isolé la confirmation des conditions d'impact, le diagnostic des manifestations de risque, la correction par mise à niveau de version et le re-test après correction de la vulnérabilité CVE-2022-22965 du framework Spring.
Le projet avant correction utilisait Spring Framework 5.3.17. Dans l'environnement JDK 11, Spring MVC, Apache Tomcat 9.0.60 et le déploiement WAR traditionnel, le chemin de propriété class.module.name a été jugé lisible.
Le projet après correction a mis à niveau le framework Spring vers 5.3.18. Le même chemin de propriété est devenu illisible, tandis que la fonction normale de liaison des données du nom et de l'email reste utilisable.
Ce projet n'a pas effectué d'exploitation de code à distance complète, mais a réalisé une validation des différences avant et après correction via une méthode sécurisée et contrôlée en lecture seule.
Le projet met en évidence les capacités suivantes :