Nilaa Maharjan, Logpoint Global Services & Security Research
Cet article de blog vous présente les recherches menées sur la famille émergente de vulnérabilités SpringShell – un exploit basé sur une exécution de code à distance (RCE : Remote Code Execution), et présent dans Spring, le framework JAVA bien connu. Cet article vous propose également de découvrir le rapport Logpoint intitulé ‘Emerging Threats Protection’, couvrant les méthodes de détection, les playbooks d’investigation, les réponses recommandées ainsi que les meilleures pratiques.
Suite à la vulnérabilité Log4Shell, une nouvelle série d’attaques de type RCE s’est développée et a commencé à semer massivement la terreur dans le cybermonde. Le 29 mars 2022, une série de tweets (maintenant supprimés) a révélé ce nouvel exploit zero-day avant qu’une CVE ne soit publiée. Nommée Spring4Shell, cette vulnérabilité très sérieuse a été détectée dans le framework Spring, un framework JAVA populaire, en espérant qu’elle aurait un impact aussi important que Log4Shell, plus tôt cette année. Elle a été identifiée comme étant un contournement du correctif pour la vulnérabilité CVE-2010-1622. Cette attaque qui cible le Spring Core est désormais associée à une CVE (CVE-2022-22965). Selon Spring, le problème a d’abord été signalé à VMware. Ces derniers ont ensuite immédiatement publié un patch alors qu’Internet relayait massivement cet incident avec la divulgation en ligne de tous les détails.
En raison de sa nature propre qui est multifactorielle, cette nouvelle vague n’a pas atteint le niveau des vulnérabilités précédentes. Le terme Spring4Shell a, par la suite, été modifié en SpringShell. Néanmoins, ce constat ne signifie pas que la menace ne soit pas réelle. En effet, tous les secteurs qui utilisent le framework Spring avec le déploiement vulnérable doivent restés vigilants car une telle attaque est susceptible de causer des dommages sans précédent et doit donc être prise très au sérieux. Chez Logpoint, dans un souci de prudence et de proactivité, nous avons analysé cette menace et recherché les moyens de protéger nos clients.
Depuis sa première découverte, la vulnérabilité SpringShell constitue à présent une famille de vulnérabilités à part entière, étant donné le nombre important de personnes qui s’y sont intéressées. Une vulnérabilité RCE similaire dans Spring Cloud Function a été découvert peu de temps après, avec une dénomination très peu créative : « not Spring4Shell » ou « not SpringShell ».
Il s’agit d’une vulnérabilité distincte de SpringShell, mais le nom est utilisé de manière interchangeable en raison de sa cible et de sa découverte coïncidant avec les vulnérabilités précédentes. Cependant, il est important de faire la distinction car il s’agit d’une TTP très différente qui s’appuie sur une variante en termes de vecteur d’attaque et sur des modules différents. Etant donné l’existence de CVE-2022-22963, cette attaque utilise désormais Spring Cloud Function.
Suis-je concerné ?
Malgré une éventuelle prise de contrôle complète du serveur, l’attaque nécessite un ensemble de conditions très particulières, signifiant ainsi que tout le monde n’est pas nécessairement en danger. Pour que l’exploitation réussisse, le système cible doit avoir rempli tous les critères suivants :
- Kit de développement Java version 9 ou ultérieure
- Apache Tomcat configuré en tant que conteneur de servlets
- Format de fichier WAR (Web Application Resource) au lieu du JAR par défaut
- Dépendances sur spring-webmvc ou spring-webflux
- Versions du framework Spring : 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 ou antérieures.
Cependant, il peut y avoir d’autres options d’exploitation encore inconnues, et la même vulnérabilité pourrait être exploitée d’une autre manière.
Les deux CVE ont divers POC accessibles au public sur Internet, néanmoins, un rapport de Palo Alto Networks montre que plus de 80 % des attaques utilisent la même TTP. Ainsi, les équipes Security Research and Global Services de Logpoint ont publié un rapport donnant un aperçu détaillé de la vulnérabilité et de la manière de détecter et de se défendre contre les attaques à l’aide des capacités SIEM et SOAR de Logpoint.
Mesures de mitigation immédiates
Les correctifs sont disponibles via Spring.io :
- Spring Framework : versions 5.3.18 et 5.2.20
- Spring Boot : versions 2.5.12 et 2.6.6
- Versions Tomcat 10.0.20, 9.0.62 et 8.5.78
Le principal conseil en cas d’utilisation du framework Spring est de passer aux versions sécurisées 5.3.18 ou 5.2.20.
L’Apache Software Foundation a également publié des versions corrigées d’Apache Tomcat 10.0.20, 9.0.62 et 8.5.78, dans lesquelles le vecteur d’attaque est fermé du côté de Tomcat.
Les développeurs de Spring ont également publié des versions corrigées des extensions Spring Boot 2.5.12 et 2.6.6 qui dépendent de la version corrigée de Spring Framework 5.3.18.
Si, pour une raison quelconque, vous ne pouviez pas mettre à jour le logiciel mentionné ci-dessus, utilisez alors l’une des solutions de contournement publiées sur le site Web officiel de Spring.
Pour une analyse détaillée de cette vulnérabilité et des techniques de détection et prévention proposées par Logpoint, veuillez consulter le rapport ci-dessous. Les équipes Security Research et Global Services continueront d’informer les clients Logpoint avec des nouvelles règles, méthodologies de détection et playbooks afin de s’assurer que votre solution SIEM+SOAR soit bien à jour et puisse assurer la sécurité de votre infrastructure.
