Spring4Shell : la faille Java qui fait pschitt ?
Bientôt une semaine qu’on a connaissance de Spring4Shell. Quels risques cette faille qui affecte le framework Spring semble-t-elle réellement poser ?
A-t-on surestimé le potentiel de nocivité de Spring4Shell ? Voilà bientôt une semaine qu’on a connaissance de cette faille qui touche le cœur fonctionnel de Spring (framework Java). Et qu’on cherche, non sans difficulté, des applications effectivement vulnérables.
Been keeping an eye on Sping4shell:
– Still haven’t found any off the shelf vendor solution that are actually exploitable.
– Haven’t found any open source webapp projects which default exploitable.
– Have talked to peers at IR firms, they haven’t had any Sping4shell incidents.— Kevin Beaumont (@GossiTheDog) April 2, 2022
Dans l’absolu, il s’agit d’une vulnérabilité critique (9,8 sur l’échelle CVSS) : elle peut servir à prendre le contrôle d’une machine à distance. Mais dans la pratique, les exploits dont on a connaissance nécessitent que soient réunies des conditions bien spécifiques. Le PoC de référence ne fonctionne, par exemple, qu’avec certaines versions de Spring et de JDK, avec un paramétrage particulier, des déploiements en WAR et Tomcat en back-end.
The prerequisites:
– Uses Spring Beans
– Uses Spring Parameter Binding
– Spring Parameter Binding must be configured to use a non-basic parameter type, such as POJOs
All this smells of « How can I make an app that’s exploitable » vs. « How can I exploit this thing that exists? »— Will Dormann (@wdormann) March 30, 2022
Spring4Shell
L'équipe du projet Spring résume la situation :
- Sont potentiellement affectées, les applications qui utilisent des versions de Spring et de JDK vulnérables
- Ont davantage de risque de l'être, celles qui, en plus, font appel à la fonction @RequestMapping avec des paramètres au format POJO (Plain Old Java Object)
- Sont encore plus à risque, celles qui reposent sur Tomcat
I was able to confirm that the #Spring4Shell exploit works against the "Handling Form Submission" tutorial from here: https://t.co/HCHBFy6JC0 😮
Methodology followed (thanks esell & @BobTShoplifter)https://t.co/MXNzEiH2JF pic.twitter.com/cHisyIerGi
— Colin 👨🏼💻 (@th3_protoCOL) March 31, 2022
On pourra s'appuyer sur cette hiérarchie pour prioriser les correctifs. En évitant de s'estimer à l'abri : Spring4Shell est « suffisamment générique » pour ouvrir la porte à une variété de PoC, nous explique-t-on. Même s'il peut être, entre autres, difficile, pour des attaquants, d'identifier à distance une version de Spring.
La meilleure option ? Patcher Spring. À défaut, on pourra patcher Tomcat (versions 8.5.78, 9.0.62 et 10.0.20), downgrader JDK (versions 8 et antérieures)... ou, en dernier recours, modifier la configuration de @RequestMapping.
Chez F5 comme chez Fortinet, on n'a pour le moment pas détecté de produit vulnérable. VMware, au contraire, en a identifié plusieurs dans son portefeuille Tanzu. En l'occurrence :
- Application Service (depuis la version 2.10 ; patché)
- Application Service for VMs (2.11 et ultérieures ; patché)
- Operations Manager (à partir de la 2.8 ; patché)
- Kubernetes Grid Integrated Edition (1.11 et suivantes ; pas encore patché)
