Ce mois d'avril commence fort avec la découverte d’une nouvelle vulnérabilité au score de 9.8 de type RCE (Remote Code Execution) sans aucune authentification préalable dans le framework opensource Java Spring.
Le contexte de l'attaque Spring4Shell
Après la bibliothèque Java Log4j, un vulnérabilité de type Zero-Day concernant le framework Java Spring a été identifiée et corrigée le 31 mars. Mais il apparaît que cette vulnérabilité est déjà activement exploitée, puisque le code le permettant ayant été rendu publiquement disponible sur le web.
Rappelons que ce framework est largement utilisé pour le développement d’applications web et son inclusion dans un grand nombre de logiciels laisse donc présager le même cauchemar que Log4Shell pour la communauté des développeurs.
Les détails techniques de la vulnérabilité
La vulnérabilité est présente dans la fonction getCachedIntrospectionResults qui expose l’ensemble de la classe de l’objet lors de l’association des paramètres.
Le mécanisme d’association des requêtes HTTP à des objets de l’application est donc impacté. Cela signifie que l’utilisateur peut forger une requête HTTP (via l’URL) afin d’obtenir en retour de la requête le détail de la classe d’objet. Ce type d’exposition peut être utilisé pour charger en retour un code malveillant qui ira modifier la classe dynamiquement, voir exécuter du code. Typiquement dans le cas observé, il s’agit de charger un webshell qui donnera à l’utilisateur distant le contrôle total de la machine, avec les droits d’exécution de la machine Java (souvent root).
Afin de comprendre l’origine de la vulnérabilité, il faut remonter au commentaire autour d’une fonction potentiellement dangereuse exposée par le framework Spring avertissant le développeur d’un risque de sécurité.
Illustration 1 : commentaire du commit autour du ticket gh-28075
C’est l’évènement déclencheur de plusieurs recherches de vulnérabilités conduites sur ce mécanisme du framework Spring qui ont rapidement abouties à la découverte de la CVE qui nous intéresse ici, Spring4Shell.
Cependant, Spring4Shell n’est que le contournement d’une ancienne vulnérabilité, la CVE-2010-1622, impactant le constructeur de la classe CachedIntrospectionResults qui a déjà été patchée.
Illustration 2 : patch du 2 juillet 2010 du framework Spring v2.5 pour la CVE-2010-1622
Illustration 3 : patch du 31 mars 2022 du framework Spring v5.3 pour la CVE-2022-22965
Versions et logiciels impactés
Il a été observé des preuves de concept sur les logiciels et SDK suivants :
- JDK 9 et supérieur ;
- le Servlet Apache Tomcat en tant que container ;
- les dépendances spring-webmvc et spring-webflux ;
- le framework Spring en versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 et les versions plus anciennes ;
- toute application Java utilisant le pack Spring Beans.
IoCs
Voici une liste d’IPs ayant tenté d’exploiter la vulnérabilité :
- 37.120.203.76
- 38.83.79.203
- 45.155.204.146
- 89.248.165.72
- 100.26.40.121
- 103.27.108.196
- 103.214.146.5
- 112.5.154.7
- 116.204.211.22
- 120.36.97.210
- 149.28.147.15
- 154.6.19.197
- 158.247.202.6
- 172.93.189.42
Les moyens de protection fournis par Stormshield
Stormshield Network Security
Une signature IPS a été publiée sur SNS, permettant de détecter et bloquer les tentatives de manipulation de la classe « classLoader » depuis une requête HTTP POST. Celles-ci fonctionnent donc via l’analyse du trafic HTTP, qui doit donc être en clair lors de son inspection. Si le flux est chiffré, le proxy SSL doit être activé (flux sortant), ou alors le déchiffrement doit se faire sur un autre équipement en amont (flux entrant). Cette signature est:
http:client:data.163 → Spring4Shell RCE attempt on HTTP POST request (CVE-2022-22925)
L’ensemble des IoCs listés sont intégrés à notre IP Reputation.
Indice de confiance de la protection proposée par Stormshield |
Indice de confiance de l’absence de faux positif |
Stormshield Endpoint Security
Les différentes versions de SES (7.2 et Evolution) étant des solutions de protection de postes et serveurs, elles ne vont pas bloquer l’exploitation de cette vulnérabilité directement. Par contre, elles pourront empêcher le payload de s’exécuter correctement et ainsi éviter tout impact. Le blocage dépendra du payload utilisé.
Quelle que soit votre version de SES (7.2 ou Evolution), il est néanmoins possible d’ajouter une règle d’audit de création de fichier *.jsp dans les dossiers du serveur pouvant être vulnérable à Spring4Shell. Ceci vous permettra d’être très rapidement alerté si un attaquant venait à déposer un fichier contenant du code Java via cette attaque.
Recommandations
Nous recommandons d’appliquer au plus vite la mise à jour Spring en version 5.3.18 and 5.2.20.
