Expliquer Spring4Shell : le désastre de la sécurité Internet qui n’était pas

Le battage médiatique et l’hyperbole étaient à l’honneur cette semaine alors que le monde de la sécurité réagissait aux rapports d’un autre Log4Shell. La vulnérabilité a été révélée en décembre et est sans doute l’une des menaces Internet les plus graves depuis des années. Baptisée Spring4Shell – le nouveau bogue d’exécution de code se trouve dans le framework Spring Java largement utilisé – la menace a rapidement mis le feu au monde de la sécurité alors que les chercheurs se démenaient pour évaluer sa gravité.

L’un des premiers messages à signaler la faille était sur le site d’actualités technologiques Cyber ​​Kendra, qui a mis en garde contre les graves dommages que la faille pourrait causer à « des tonnes d’applications » et a affirmé que le bug « peut ruiner Internet ». Presque immédiatement, les sociétés de sécurité, dont beaucoup vendaient de l’huile de serpent, se sont mises à tomber sur elles-mêmes pour avertir du danger imminent auquel nous serions tous confrontés. Et tout cela avant qu’une désignation de suivi des vulnérabilités ou un avis des responsables de Spring ne soit même disponible.

Tous à bord

Le train de battage médiatique a commencé mercredi après qu’un chercheur a publié un exploit de preuve de concept qui pourrait installer à distance une porte dérobée de contrôle à distance basée sur le Web connue sous le nom de shell Web sur un système vulnérable. Les gens étaient naturellement inquiets car la vulnérabilité était si facile à exploiter et se trouvait dans un cadre qui alimente un grand nombre de sites Web et d’applications.

La vulnérabilité réside dans deux produits Spring : Spring MVC et Spring WebFlux, qui permettent aux développeurs d’écrire et de tester des applications. La faille résulte de modifications introduites dans JDK9 qui ont ressuscité une vulnérabilité vieille de dix ans identifiée comme CVE-2010-1622. Compte tenu de l’abondance de systèmes qui combinent le framework Spring et JDK9 ou version ultérieure, il n’est pas étonnant que les gens s’inquiètent, d’autant plus que le code d’exploitation était déjà dans la nature (le leaker initial a rapidement supprimé le PoC, mais il était alors trop tard).

Jeudi, la faille a finalement reçu la désignation CVE-2022-22965. Les défenseurs de la sécurité ont également reçu une description beaucoup plus nuancée de la menace qu’elle représentait. Selon les responsables de Spring, le code divulgué ne s’exécutait que lorsqu’une application développée par Spring s’exécutait sur Apache Tomcat, puis uniquement lorsque l’application était déployée en tant que type de fichier appelé WAR, abréviation d’archive Web.

« Si l’application est déployée en tant que jar exécutable Spring Boot, c’est-à-dire la valeur par défaut, elle n’est pas vulnérable à l’exploit », ont écrit les responsables de Spring. « Cependant, la nature de la vulnérabilité est plus générale et il peut y avoir d’autres moyens de l’exploiter. »

Alors que le message laissait ouverte la possibilité que l’exploit PoC puisse être amélioré pour fonctionner avec d’autres configurations, personne n’a découvert une variante qui le fasse, du moins pour l’instant.

« C’est une chose que les développeurs doivent corriger, s’ils utilisent une version affectée », a déclaré Will Dormann, analyste des vulnérabilités au CERT, dans un message privé. « Mais nous sommes toujours dans le bateau de ne pas connaître une seule application exploitable. »

Sur Twitter, Dormann a pris Cyber ​​Kendra à partie.

« Les façons dont Cyber ​​Kendra a aggravé la situation pour tout le monde », a-t-il a écrit. « 1) Article de blog sensationnel indiquant que cela va ruiner Internet (drapeau rouge !) 2) Lien vers un engagement git sur la désérialisation qui n’a absolument rien à voir avec le problème démontré par la partie d’origine. »

Un représentant de Cyber ​​Kendra n’a pas répondu à un e-mail sollicitant un commentaire. En toute honnêteté, la ligne sur la ruine d’Internet a ensuite été barrée.

SpringShell, ne pas Spring4Shell

Malheureusement, même s’il existe un consensus sur le fait que, du moins pour l’instant, la vulnérabilité ne pose rien près de la menace de Log4Shell, le nom Spring4Shell est largement resté. Cela induira probablement certains en erreur sur sa gravité. À l’avenir, Ars s’y référera par son nom plus approprié, SpringShell.

Plusieurs chercheurs disent avoir détecté des scans dans la nature qui utilisent le PoC CVE-2022-22965 divulgué ou un exploit très similaire. Il n’est pas rare que les chercheurs testent les serveurs de manière bénigne pour comprendre la prévalence d’une nouvelle vulnérabilité. Un peu plus inquiétant est un rapport publié vendredi dans lequel des chercheurs de Netlab 360 ont déclaré qu’une variante de Mirai – un logiciel malveillant capable de brouiller des milliers d’appareils IoT et de produire des attaques par déni de service paralysantes – « a remporté la course en tant que premier botnet qui a adopté ce vulnérabilité. »

Pour rendre les choses plus confuses, une vulnérabilité d’exécution de code distincte est apparue la semaine dernière qui affecte Spring Cloud Function, qui permet aux développeurs de découpler facilement la logique métier d’une application à partir d’un runtime spécifique. La faille, identifiée comme CVE-2022-22963, réside dans le langage d’expression Spring, généralement connu sous le nom de SpEL.

Ces deux vulnérabilités sont potentiellement graves et ne doivent en aucun cas être ignorées. Cela signifie mettre à jour Spring Framework vers 5.3.18 ou 5.2.20 et, par prudence, également mettre à niveau vers Tomcat 10.0.20, 9.0.62 ou 8.5.78. Ceux qui utilisent la fonction Spring Cloud doivent mettre à jour vers 3.1.7 ou 3.2.3.

Pour les personnes qui ne savent pas si leurs applications sont vulnérables à CVE-2022-22965, les chercheurs de la société de sécurité Randori ont publié un simple, script non malveillant ça peut vérifier.

Donc, par tous les moyens, testez et corrigez comme s’il n’y avait pas de lendemain, mais ne croyez pas le battage médiatique.