Récemment, la nouvelle a annoncé que une vulnérabilité critique de type zero day a été détectée dans le module Spring Core livré dans le cadre de Spring Framework, qui permet à un attaquant distant non authentifié d'exécuter son code sur le serveur.
Selon certaines estimations, le module Spring Core utilisé dans 74% des applications Java. Le danger de vulnérabilité est réduit par le fait que seules les applications qui utilisez l'annotation "@RequestMapping" pourEn connectant des gestionnaires de requêtes et en utilisant la liaison de paramètres de formulaire Web au format « nom=valeur » (POJO, Plain Old Java Object), plutôt que JSON/XML, ils sont susceptibles d'être attaqués. On ne sait pas encore quelles applications et frameworks Java sont concernés par le problème.
Cette vulnérabilité, nommée "Spring4Shell", profite de l'injection de classe conduisant à un RCE complet et est très sérieuse. Le nom "Spring4Shell" a été choisi car Spring Core est une bibliothèque omniprésente, similaire à log4j qui a engendré la tristement célèbre vulnérabilité Log4Shell.
Nous pensons que les utilisateurs exécutant JDK version 9 et ultérieure sont vulnérables à une attaque RCE. Toutes les versions de Spring Core sont concernées.
Il existe des stratégies pour atténuer l'attaque et nous pensons que tous les serveurs Spring ne sont pas nécessairement vulnérables, en fonction d'autres facteurs discutés ci-dessous. Cela dit, nous recommandons actuellement à tous les utilisateurs d'appliquer des mesures d'atténuation ou de mettre à niveau s'ils utilisent Spring Core.
L'exploitation de la vulnérabilité n'est possible qu'avec Java/JDK 9 ou une version plus récente. La vulnérabilité bloque la mise sur liste noire des champs « classe », « module » et « classLoader » ou l'utilisation d'une liste blanche explicite des champs autorisés.
Le problème est dû à la possibilité de contourner la protection contre la vulnérabilité CVE-2010-1622, Corrigé dans Spring Framework en 2010 et associé à l'exécution du gestionnaire classLoader lors de l'analyse des paramètres de requête.
Le fonctionnement de l'exploit se réduit à l'envoi d'une requête cavec les paramètres "class.module.classLoader.resources.context.parent.pipeline.first.*", dont le traitement, lors de l'utilisation de "WebappClassLoaderBase", conduit à un appel à la classe AccessLogValve.
La classe spécifiée vous permet de configurer le logger pour créer un fichier jsp arbitraire dans l'environnement racine d'Apache Tomcat et d'écrire le code spécifié par l'attaquant dans ce fichier. Le fichier créé est disponible pour les requêtes directes et peut être utilisé comme un shell Web. Pour attaquer une application vulnérable dans l'environnement Apache Tomcat, il suffit d'envoyer une requête avec certains paramètres à l'aide de l'utilitaire curl.
Le problème à l'étude dans Spring Core à ne pas confondre avec les vulnérabilités nouvellement identifiées CVE-2022-22963 et CVE-2022-22950. Le premier problème concerne le package Spring Cloud et permet également l'exécution de code à distance (exploit). CVE-2022-22963 est corrigé dans les versions Spring Cloud 3.1.7 et 3.2.3.
Le deuxième problème CVE-2022-22950 est présent dans Spring Expression, peut être utilisé pour lancer des attaques DoS et est corrigé dans Spring Framework 5.3.17. Ce sont des vulnérabilités fondamentalement différentes. Les développeurs de Spring Framework n'ont pas encore fait de déclaration sur la nouvelle vulnérabilité et n'ont pas publié de correctif.
Comme mesure de protection temporaire, il est recommandé d'utiliser une liste noire de paramètres de requête non valides dans votre code.
Encore on ne sait pas à quel point les conséquences peuvent être catastrophiques du problème identifié et si les attaques seront aussi massives que dans le cas de la vulnérabilité dans Log4j 2. La vulnérabilité porte le nom de code Spring4Shell, CVE-2022-22965, et les mises à jour Spring Framework 5.3.18 et 5.2.20 ont été publiées. pour faire face à la vulnérabilité.
Un correctif est désormais disponible à partir du 31 mars 2022 dans les dernières versions Spring publiées 5.3.18 et 5.2.20. Nous recommandons à tous les utilisateurs de mettre à niveau. Pour ceux qui ne peuvent pas effectuer la mise à niveau, les mesures d'atténuation suivantes sont possibles :
Sur la base du message de Praetorian confirmant la présence d'un RCE dans Spring Core, l'approche actuellement recommandée consiste à corriger DataBinder en ajoutant une liste noire de modèles de champs vulnérables nécessaires à l'exploitation.
Enfin oui vous êtes intéressé à en savoir plus à propos de la note, vous pouvez vérifier les détails dans le lien suivant.