Spring4Shell (CVE-2022-22965) est une vulnérabilité d’exécution de code à distance (RCE) qui affecte Spring Core, un framework complet destiné aux applications d’entreprise basées sur Java.
Spring4Shell tire son nom de la vulnérabilité Log4Shell, l’une des menaces zero-day les plus critiques jamais découvertes, qui affectait un composant logiciel Java appelé Log4j et permettait aux pirates de prendre le contrôle de serveurs web et de réseaux.
Spring4Shell est une vulnérabilité critique pour les applications web et les services cloud. Toute RCE constitue une menace sérieuse, et GitHub regorge déjà de POC (preuves de concept) qui divulguent publiquement l’exploit, de sorte que les cybercriminels ne peuvent pas passer à côté.
Les vulnérabilités telles que Spring4Shell et Log4Shell seront rapidement la cible d’attaques, et les pirates trouveront probablement d’autres moyens de les exploiter, en contournant peut-être les solutions de contournement et les mesures d’atténuation. La vigilance est donc de mise.
Une étude récente a révélé que 78 % des entreprises sont exposées à une compromission chaque fois qu’une nouvelle technique RCE est découverte. Les professionnels de la sécurité doivent donc accorder une attention particulière aux vulnérabilités RCE zero-day.
Voir les principaux outils de gestion des vulnérabilités.
Popularité de Spring Core
Le framework Spring Core est l’un des frameworks Java les plus populaires, notamment dans les entreprises. Celles-ci l’utilisent pour accélérer le développement, comme alternative aux applications Java EE.
Cet outil est entièrement orienté objet et fournit des fonctionnalités avancées pour créer des applications basées sur Java. Par exemple, Spring permet de lier et d’extraire des paramètres à partir des requêtes, ce qui permet aux programmeurs de les manipuler facilement.
Autrement dit, il peut extraire des informations précieuses des requêtes HTTP et les mapper sous forme de paires clé-valeur ou d’objets Java utilisés par l’application. C’est plus pratique pour les développeurs.
Les pirates peuvent exploiter Spring4Shell pour écraser des informations et téléverser des web shells qui permettent finalement l’exécution de code à distance. Pour cela, ils transmettront probablement une charge utile malveillante via une requête HTTP afin de manipuler les objets Java ciblés et d’obtenir le contrôle total du système visé.
Les exploits Spring4Shell expliqués
L’exploit semble nécessiter plusieurs composants :
- JDK (Java Development Kit) 9++
- spring-webmvc ou spring-webflux
- Versions du framework Spring 5.2.0 à 5.2.19, 5.3.0 à 5.3.17, ou versions antérieures
- Apache Tomcat pour servir l’application
- Construit sous forme de fichier WAR (Web Application Resource) — et non JAR
Cependant, Microsoft a déclaré que « tout système utilisant JDK 9.0 ou une version ultérieure, ainsi que le framework Spring ou des frameworks dérivés, doit être considéré comme vulnérable ».
La plupart des POC exploitaient une API REST qui accepte les requêtes HTTP (GET, POST, etc.) et les charges utiles. L’idée principale consiste à détourner certaines fonctions qui s’appuient sur l’annotation de mappage des requêtes et sur des paramètres Plain Old Java Object (POJO) au sein du framework Spring (voir la capture d’écran ci-dessous) :
Les attaquants peuvent envoyer des requêtes HTTP spécialement conçues pour créer un fichier .jsp malveillant dans le répertoire racine du service (source : Microsoft) :
Autrement dit, il est possible, dans certaines conditions (par exemple avec la fonctionnalité de mappage des requêtes de Spring), de modifier des variables internes depuis le côté client.
Comme le framework dispose d’une fonctionnalité de mappage des requêtes, les pirates peuvent prédire quelles méthodes seront appelées en fonction d’un URI donné. En outre, la liaison des paramètres et des propriétés est pratique pour les développeurs, car elle renseigne automatiquement certains champs en fonction des paramètres de l’URI. Mais elle est également très prévisible et susceptible d’entraîner des enchaînements indésirables.
En utilisant l’getClassLoader() comme accesseur, les pirates peuvent manipuler les propriétés de l’objet AccessLogValve dans le pipeline de Tomcat. C’est ainsi que le journal d’accès d’un serveur web Tomcat vulnérable peut se transformer en shell inversé.
Un tel accès non autorisé au shell peut entraîner les pires conséquences, du vol d’identifiants à l’escalade vers les privilèges root, selon la configuration du serveur et les politiques de sécurité appliquées lors du déploiement.
Bien que l’exploit puisse sembler très technique, les POC publics et la mise à disposition clandestine du code source en open source en faciliteront considérablement l’exploitation. J’ai vu de nombreux scripts Python capables d’automatiser l’attaque.
Les pirates exploitent déjà la vulnérabilité
CISA a ajouté la vulnérabilité à son catalogue et Checkpoint a mis en évidence plusieurs chiffres clés :
- Environ 37 000 tentatives d’exploitation de la vulnérabilité Spring4Shell
- Au cours des quatre premiers jours, 16 % des organisations dans le monde ont été touchées par des tentatives d’exploitation
- Les éditeurs de logiciels constituent le secteur le plus touché : 28 % des organisations ont été affectées
- L’Europe est la région la plus touchée, avec environ 20 % d’organisations affectées
Microsoft a signalé un « faible volume de tentatives d’exploitation dans les services cloud visant les vulnérabilités Spring Cloud et Spring Core » et a vivement encouragé les utilisateurs à vérifier leur configuration actuelle.
Comment détecter Spring4Shell et s’en protéger
Comme la vulnérabilité permet l’exécution de code à distance, la surveillance des activités suspectes, notamment des connexions sortantes, peut aider à détecter l’exploit.
Plus précisément, Microsoft a indiqué qu’un test rapide permettait de déterminer si vous êtes vulnérable à Spring4Shell :
curl host:port/path?class.module.classLoader.URLs%5B0%5D=0Toute réponse HTTP 400 confirme la vulnérabilité !
Les entreprises qui s’appuient sur les versions 5.2 et 5.3 du framework Spring doivent rapidement effectuer la mise à niveau vers les versions 5.2.20 et 5.3.18.
Il est également possible d’appliquer un correctif à Apache Tomcat avec les versions suivantes : 8.5.78, 9.0.62, 10.0.20.
Le projet Spring a publié une série de mesures d’atténuation et de recommandations. Les organisations qui ne peuvent pas effectuer la mise à jour pour le moment peuvent par exemple revenir à Java 8 ou désactiver la liaison avec certains champs.
VMware a également publié des avis détaillés. La gravité est jugée critique pour tous ses produits affectés par Spring4Shell. À ce stade, aucune mesure corrective n’est disponible pour l’ensemble des produits. L’enquête se poursuit, mais les utilisateurs peuvent appliquer des solutions de contournement pour atténuer la menace.
À lire ensuite : SANS présente les mesures de sécurité des infrastructures critiques alors que la Russie et les États-Unis s’échangent des cybermenaces.