Zero-Day SQLi de MOVEit (CVE-2023-34362) exploité par le groupe de ransomware CL0P
par Ori David, Sam Tinklenberg, Maxim Zavodchik et Ophir Harpaz
Synthèse
Le 31 mai 2023, Progress Software a alerté ses clients d'une vulnérabilité inconnue jusqu'alors dans les logiciels MOVEit Transfer et MOVEit Cloud. La vulnérabilité d'injection SQL (SQLi), désignée par CVE-2023-34362, a été exploitée de manière active par des pirates.
Selon un rapport de Mandiant, des tentatives d'exploitation de cette vulnérabilité avaient déjà été détectées le 27 mai 2023. Dans la même journée, les chercheurs d'Akamai ont détecté des tentatives d'exploitation contre l'un des clients du secteur financier d'Akamai, une attaque qui a été bloquée par le moteur de sécurité adaptatif d'Akamai.
La campagne d'attaque aurait été menée par un groupe de ransomware baptisé CL0P. Ce groupe, vraisemblablement basé en Russie ou en Europe de l'Est,poursuit des objectifs financiers et est connu pour faire chanter ses victimes par l'exfiltration de données.
Les auteurs de l'attaque ont exploité la vulnérabilité SQLi pour déployer un shell Web ASP.NET personnalisé (LEMURLOOT) afin d'obtenir une certaine persistance sur les réseaux des victimes et de permettre d'autres attaques.
Actuellement, les détails complets de l'exploitation ne sont pas disponibles publiquement. Cependant, l'analyse du groupe Security Intelligence d'Akamai ainsi que la collaboration avec l'équipe de sécurité de Progress confirment que l'Adaptive Security Engine a protégé nos clients contre les tentatives d'exploitation.
Chronologie
Figure 1 : Chronologie des événements de la campagne d'exploitation MOVEit
Le 31 mai 2023, Progress Software a publié un bulletin d'information pour alerter ses clients de l'existence d'une vulnérabilité zero-day dans MOVEit Transfer et MOVEit Cloud. Cette vulnérabilité était activement exploitée par des pirates pour compromettre des serveurs Internet (Figure 1).
L'alerte a été émise après l'identification d'une campagne d'exploitation massive qui s'est appuyée sur cette vulnérabilité pour exfiltrer des fichiers sensibles stockés sur des serveurs vulnérables. Selon Mandiant, des tentatives d'exploitation de la vulnérabilité ont été observées dès le 27 mai 2023. Huntress a effectué une analyse technique de la vulnérabilité, laquelle a montré que la vulnérabilité pouvait en fait conduire à une exécution complète du code à distance sur le serveur.
Microsoft a officiellement attribué cette attaque au groupe Lace Tempest le 2 juin 2023, et cette information a finalement été confirmée le 5 juin lorsque CL0P a publié une déclaration concernant cette campagne sur son blog (Figure 2).
Figure 2 : Le groupe de ransomware CL0P reconnaît sa participation à la campagne MOVEit
Portée des attaques
Au moment où l'attaque était déjà connue et faisait l'objet d'une enquête, Shodan a identifié environ 2 500 serveurs Internet exécutant MOVEit (Figure 3).
Figure 3 : Une requête Shodan montre que plus de 2 500 serveurs Internet exécutent une version vulnérable de MOVEit
Progress Software a affirmé que tous les serveurs exécutant MOVEit étaient vulnérables et qu'aucun correctif n'existait au moment de l'attaque massive. On peut donc supposer que le nombre de victimes est important. Plusieurs entreprises ont déjà confirmé avoir été victimes d'une violation, et de nombreuses autres feront probablement surface dans les jours à venir.
Chaîne d'exploitation
De nombreuses informations ont été publiées sur cette vulnérabilité. Cependant, les détails de l'exploitation n'ont pas encore été rendus publics. À partir des informations accessibles au public, de l'analyse effectuée par le groupe Security Intelligence d'Akamai et des données figurant dans nos journaux, nous avons une idée précise de la manière dont moveitisapi.dll est utilisé pour effectuer des opérations SQLi.
En outre, notre équipe a rencontré l'équipe de sécurité de Progress dans le cadre d'une session de partage d'informations au cours de laquelle nous avons transmis notre analyse et d'autres informations relatives aux indicateurs d'infection (IOC). À la suite de cette réunion, nous sommes en mesure de confirmer que l'Akamai Adaptive Security Engine a protégé et continue de protéger nos clients mutuels contre cette attaque.
Nous pourrons publier plus de détails sur notre analyse et notre chaîne d'exploitation une fois qu'il se sera écoulé suffisamment de temps pour permettre l'application de correctifs.
Dissimulation de l'opération
Le groupe CL0P a tenté à plusieurs reprises de rester indétectable et de compliquer l'analyse.
Tout d'abord, le nom du shell Web mis en ligne était « human2.aspx », ce qui est très similaire au fichier MOVEit légitime mettant en œuvre l'interface Web : nommé « human.aspx ».
Ensuite, l'accès au shell Web impliquait l'envoi d'un mot de passe par l'intermédiaire de l'en-tête « X-siLock-Comment ». Si cet en-tête manquait ou si le mot de passe était incorrect, le shell Web renvoyait une réponse « 404 Not Found » (404 Page non trouvée). Souvent, la manière la plus simple de trouver un shell Web est d'envoyer une simple requête GET. Si la page n'existe pas, une réponse 404 est renvoyée. La réponse 404 renvoyée par le shell Web ne fait que bloquer le moyen le plus simple de découvrir le problème. Avec quelques étapes supplémentaires, vous pouvez comparer la réponse 404 du shell Web à la réponse 404 normale du serveur et voir la différence entre les deux réponses.
Troisièmement, les en-têtes utilisés pour contrôler le shell Web et envoyer des exploitations utilisent des noms très similaires aux noms d'en-têtes originaux de MOVEits. Par exemple, « X-siLock-Comment » est utilisé pour transmettre le mot de passe du shell Web. D'autres informations de la base de données MOVEit ont été exfiltrées par le biais d'en-têtes portant des noms similaires : « X-siLock-Step2 » et « X-siLock-Step3 ».
Détection de l'exploitation
Les tentatives d'exploitation peuvent être identifiées de plusieurs manières.
Indicateurs d'infection connus (IOC)
Progress Software et la communauté de la sécurité ont publié de nombreux indicateurs d'infection basés sur l'hôte et le réseau, notamment les adresses IP, les hachages de fichiers et les règles YARA.
Les administrateurs réseau peuvent inspecter le trafic réseau et les journaux IIS, et analyser les ressources du réseau pour trouver les IOC connus et ainsi identifier les machines exploitées.
Les clients d'Adaptive Security Engine ont la possibilité d'inspecter les journaux de leur WAF à la recherche de signes d'exploitation. Si leurs hôtes MOVEit ont été ciblés, des déclencheurs de groupe d'attaque SQLi ciblant « /moveitisapi/moveitisapi.dll » devraient apparaître.
Recherche des menaces
Les serveurs qui exécutent le logiciel vulnérable doivent être examinés et analysés à la recherche de comportements anormaux, même si des IOC connus n'ont pas été détectés sur ces serveurs. Par exemple, après avoir inspecté la charge utile utilisée par les pirates, nous avons pu constater qu'elle a entraîné l'envoi d'un shell Web aspx dans le répertoire racine du serveur de <Driveletter> : \MOVEitTransfer\wwwroot\Le shell Web déployé dans la campagne d'attaque initiale était nommé human2.aspx, mais cet indicateur pourrait facilement changer.
Au lieu de vous fier uniquement à des IOC statiques, nous vous recommandons d'employer des méthodes de recherche de menaces basées sur les anomalies sur les serveurs vulnérables. Dans ce cas précis, une approche pourrait consister à vérifier le répertoire racine du serveur MOVEit pour trouver tout fichier aspx récemment créé. Les fichiers aspx sont relativement statiques par nature et ne sont généralement pas modifiés ou créés, de sorte qu'un nouvel ajout pourrait être suspect et devrait faire l'objet d'une enquête. D'autres chemins d'accès à des fichiers suspects ont été publiés dans l'avis initial de Progress et dans un récent avis #StopRansomware de la CISA.
Les clients d'Akamai Guardicore Segmentation peuvent utiliser la requête Insight illustrée dans la Figure 4 pour localiser ces fichiers.
Figure 4 : Une requête Insight pour trouver tous les fichiers aspx récemment créés
Remarque : la lettre du lecteur (C:\) et le chemin d'installation peuvent varier ; cette requête ne couvre que le chemin d'installation par défaut.
Akamai Hunt, le service de recherche de menaces géré par Akamai, a effectué des analyses approfondies des environnements des clients afin de détecter les ressources vulnérables, les tentatives d'exploitation et les IOC associés à la campagne d'attaque. Dans les cas où des composants MOVEit ont été découverts, les chercheurs de Hunt ont informé les équipes concernées et ont aidé à atténuer la menace immédiatement (Figure 5).
Figure 5 : Une alerte Hunt concernant une tentative d'exploitation de MOVEit détectée dans l'environnement d'un client
Protection
Malheureusement, les vulnérabilités logicielles sont inévitables, mais les entreprises peuvent faire beaucoup pour se protéger contre ce type de violations.
Cartographie des serveurs Internet
Avant de pouvoir atténuer l'attaque, les défenseurs doivent d'abord identifier les applications sensibles sur Internet. Dans le cas de MOVEit, tous les clients exposés ont été informés de la vulnérabilité par Progress. Cependant, il est toujours essentiel de connaître le champ d'attaque extérieur et d'identifier toutes les applications sensibles qui sont exposées sur Internet. Une fois ces applications identifiées, les mesures d'atténuation suivantes peuvent réduire le risque que ces applications soient compromises.
Limiter l'accès à Internet
La réduction de la surface d'attaque doit être une priorité absolue. Si aucune raison ne justifie l'accès non autorisé à une application Internet, celle-ci doit être protégée par des contrôles d'accès basés sur l'utilisateur grâce à Zero Trust Network Access (ZTNA) ou à des produits VPN traditionnels.
Si un accès non autorisé à Internet est nécessaire pour certains cas d'utilisation, nous vous recommandons d'utiliser un serveur d'application externe distinct, de limiter les données qui y sont stockées ou accessibles et de le séparer autant que possible du réseau interne. De cette façon, même si le serveur d'application est attaqué, le rayon d'action sera limité.
Bloquer l'exploitation avec un WAF
Les applications dotées d'interfaces Web doivent être protégées par un WAF. En effet, celui-ci peut bloquer les requêtes anormales et suspectes et potentiellement bloquer l'exploitation de vulnérabilités de type « zero-day » inconnues jusqu'alors.
Conformément à nos connaissances actuelles et à notre compréhension de la chaîne d'exploitation, Akamai Adaptive Security Engine fournit une protection contre cette attaque avec le groupe d'attaque SQLi. Plus précisément, nous avons identifié des cas où Adaptive Security Engine a empêché les pirates d'exploiter la vulnérabilité SQLi. Les requêtes bloquées provenaient des adresses IP répertoriées dans les IOC connus.
Empêcher les mouvements latéraux grâce à la segmentation
Les serveurs Internet sont souvent le point d'entrée des auteurs d'attaques dans le réseau. Par conséquent, ces serveurs doivent être protégés et maintenus dans un segment séparé, afin de limiter la capacité du pirate à effectuer des mouvements latéraux à l'intérieur du réseau.
Par exemple, une règle peut être créée pour bloquer toutes les connexions sortantes des serveurs Internet sur les ports de gestion (Figure 6).
Figure 6 : Un exemple de règle dans Akamai Guardicore Segmentation permettant de bloquer les tentatives de mouvement latéral
Ainsi, si un pirate parvenait à pénétrer dans le serveur, il lui serait impossible d'effectuer un mouvement latéral par l'intermédiaire de ces ports. Des règles supplémentaires couvrant les applications sensibles et d'autres ports de gestion doivent être créées pour limiter autant que possible la surface d'attaque de ces serveurs. Gardez à l'esprit que ces règles peuvent également perturber le fonctionnement normal du réseau. Vous devez donc faire preuve de discernement lorsque vous les créez et que vous ajoutez des exclusions au trafic existant nécessaire au fonctionnement quotidien.
Quelle est la prochaine étape ?
MOVEit est un autre cas d'exploitation d'une vulnérabilité de type « zero-day » d'un service de transfert de fichiers géré (MFT). Le groupe de ransomware CL0P est désormais bien connu pour ce type d'activité. En effet, il a déjà exploité des vulnérabilités dans les applications GoAnywhere SolarWinds Serv-Uet Accellion pour dérober des données et faire chanter ses victimes, mais il a également exploité d'autres vulnérabilités dans d'autres applications Internet.
En réalité, si l'une des principales solutions MFT est installée sur votre réseau, il y a fort à parier qu'au moment où vous lisez cette phrase, un pirate hautement qualifié et motivé, quelque part dans le monde, étudie ces applications et tente de trouver leurs failles de sécurité. Le lancement d'une nouvelle campagne d'exploitation par le groupe CL0P n'est apparemment qu'une question de temps, et d'autres groupes ne tarderont sans doute pas à suivre.
