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.

Partager sur

[juiz_sps buttons="facebook, twitter, linkedin, mail"]
Notre équipe de Threat Intelligence remplit deux missions principales : étudier les menaces cyber pour les comprendre et améliorer en continu les protections des produits de Stormshield. Le tout, dans l’optique de contribuer à l’effort de la communauté de la cybersécurité pour faire face aux menaces cyber.
À propos de l'auteur
Edouard Simpere Responsable Cyber Threat Intelligence, Stormshield

Doté d'une forte appétence pour l'humour noir, les pâtisseries de chefs étoilés et l'environnement Windows, Edouard est un mordu de cybersécurité, un vrai. Étendard vivant de la mobilité interne chez Stormshield, il a fait ses premières, deuxièmes et troisièmes armes autour du produit Stormshield Endpoint Security Evolution, comme développeur, architecte et Technical Leader. Puis, il a pris la tête de l'équipe de Threat Intelligence de l'entreprise, en charge de la recherche et du maintien du niveau de protection de l'ensemble des produits de l'entreprise. Un sacré programme pour un sacré couteau suisse, parisien de naissance et lyonnais d'adoption.