Spring4Shell : ce que nous savons sur la vulnérabilité RCE Java

Vous connaissez déjà Spring4Shell ? Passez directement à la section Mesures correctives pour Spring4Shell de cet article ou lisez notre analyse approfondie de Spring4Shell pour comprendre le fonctionnement de cette exécution de code à distance (RCE) zero-day.

Très tôt le matin du 30 mars (pour moi), mon collègue DeveloperSteve a publié un message « Hé, vous avez vu ça ? » dans notre canal Slack. Il s’agissait d’un « avertissement préalable » concernant une « probable » exécution de code à distance (RCE) dans le framework Java Spring, extrêmement populaire. J’ai appris par la suite que, encore plus tôt, l’équipe Snyk Security avait commencé à enquêter sur une éventuelle RCE dans Spring après avoir vu un tweet qui a depuis été supprimé.

Au départ, les informations semblaient floues. Un tweet contenant des captures d’écran avait été supprimé. Des références à une pull request (PR) circulaient : celle-ci avait en fait été créée le 18 février, mais n’avait été fusionnée que le 29 mars.

Divers acteurs tentaient d’imposer le surnom « Spring4Shell » (ou parfois simplement SpringShell), tandis que les responsables de Spring Core ajoutaient des commentaires à la PR indiquant qu’aucune RCE n’était connue.

Alors, que se passait-il au juste, et qu’en est-il aujourd’hui ?

Alors, qu’est-ce que Spring4Shell ?

Si vous avez utilisé l’annotation @Autowired ou tiré parti de l’injection par constructeur, vous avez déjà rencontré l’injection de dépendances dans l’écosystème Spring.

Dans les versions affectées, il est possible d’obtenir une RCE en manipulant le ClassLoader au moyen d’une requête HTTP POST soigneusement conçue.

À ce jour, l’exploitation n’est réputée possible qu’avec un environnement d’exécution Java (JRE) en version 9 ou ultérieure ET Tomcat en version 9 ou ultérieure.

Par excès de prudence et pour ne pas agir sur la base d’informations incomplètes, les chercheurs en sécurité de Snyk ont consacré la journée du 30 mars à examiner la situation.

À ce jour, notre conclusion est qu’il existe une menace RCE crédible dans le package spring-beans de Spring Core. Qu’on l’apprécie ou non, Spring4Shell est le nom officiel. C’est logique, puisqu’il existe déjà un projet légitime appelé Spring Shell dans l’écosystème Spring.

Nous continuerons à publier des mises à jour dans notre base de données des vulnérabilités à mesure que la situation évolue.

Mesures correctives pour Spring4Shell

De nouvelles versions du framework Spring ont été publiées et ne sont pas affectées par l’exploit actuel. Il s’agit des versions 5.2.20et 5.3.18. Et si vous utilisez Spring Boot, les versions 2.5.12 et 2.6.6 ont été publiées aujourd’hui même. Elles intègrent les modifications apportées au framework Spring et à spring-beans.

Voici les mesures correctives que vous pouvez prendre, par ordre de préférence :

• Si vous utilisez directement le framework Spring, passez à la version 5.2.20 ou 5.3.18

• Si vous utilisez Spring Boot, passez à la version 2.15.12 ou 2.6.6

• Si vous ne pouvez pas mettre à niveau votre version de Spring pour le moment, utilisez un JRE en version 8 et/ou un conteneur Tomcat pour atténuer le problème.

Il faut savoir que d’autres mises à jour de Spring seront probablement publiées à mesure que d’autres vulnérabilités (potentiellement différentes) seront découvertes. C’est souvent ce qui se produit lorsqu’un problème de gravité élevée, comme celui-ci, attire une grande attention (Log4Shell, ça vous dit quelque chose ?).

Les outils de Snyk ont déjà été mis à jour pour vous avertir si votre projet est vulnérable !

Rendez-vous sur Snyk pour créer un compte gratuit. Vous pourrez ensuite, sur le site ou en ligne de commande, tester votre projet afin de vérifier s’il est vulnérable à Spring4Shell.

Nous prévoyons de mettre à jour cet article et de créer un dépôt de code PoC pour illustrer la RCE sur les versions 9 et ultérieures du JRE et de Tomcat. Revenez ici pour suivre les mises à jour.

Retour sur la confusion initiale autour de Spring4Shell

L’un des premiers articles de blog signalés à notre équipe aux premières heures du 30 mars a depuis été supprimé. Cet article renvoyait à un tweet qui a également été supprimé. Malgré cette double suppression, une référence vérifiable à un commit de Spring Core lié à la désérialisation (une fonctionnalité Java qui a déjà entraîné des RCE — Log4Shell, ça vous dit quelque chose ?) avait bien été publiée.

Le commentaire associé à ce commit indique :

1Since SerializationUtils#deserialize is based on Java's serialization
2mechanism, it can be the source of Remote Code Execution (RCE)
3vulnerabilities.

Au fil de la journée, les rumeurs se sont multipliées (sans guère de faits vérifiables pour les étayer) : nous étions peut-être face à une RCE dans Spring Core.

Plus bas dans les commentaires, un responsable de Spring Core a confirmé un autre commentaire indiquant que ce commit n’avait rien à voir avec une RCE connue.

Et, en fait, si vous consultez la PR à laquelle le commit est associé, vous verrez qu’elle a été ouverte le 18 février.

Mais voici le hic : pendant tout ce temps, la Toile confondait ce problème en cours d’évolution avec un autre problème connu dans un projet totalement différent : Spring Cloud Function. Pour ne pas ajouter à la confusion, je ne vais pas entrer dans les détails de cette vulnérabilité. Retenez simplement que si vous lisez des informations sur des vulnérabilités dans Spring Cloud, vous faites fausse route pour en savoir plus sur Spring4Shell (peut-on lui donner un autre nom, s’il vous plaît ?).

En bref

Protégez-vous de Spring4Shell en appliquant les mesures correctives recommandées ci-dessus. Créez gratuitement un compte Snyk pour commencer à corriger le problème.