Un rapport de Salt Security insiste sur l’importance de la sécurisation de l’implémentation OAuth pour se protéger contre l’usurpation d’identité, la fraude financière et l’accès aux informations personnelles.
Le dernière bug découvert par des chercheurs dans l’implémentation OAuth sur divers sites web permet aux utilisateurs de s’authentifier avec leurs identités à partir de services tiers comme Facebook ou Google. Or, certains sites ne parviennent pas à franchir une étape importante de la chaîne d’autorisation OAuth, qui consiste à valider l’application pour laquelle un jeton d’accès a été émis par le fournisseur d’identité. En exploitant cette faille, un attaquant pourrait collecter les jetons émis pour une app ou un site web leurre, créés de toute pièce, puis les utiliser pour accéder aux comptes des victimes sur des sites vulnérables à ce problème. Les chercheurs de l’entreprise de sécurité Salt Security en ont fait la démonstration sur trois sites web populaires : le service d’aide à la saisie Grammarly, le site de streaming vidéo indonésien Vidio et la plateforme de commerce électronique indonésienne Bukalapak.
Si ces entreprises ont été informées en privé et ont corrigé le problème, les chercheurs estiment que toutes les entreprises devraient vérifier leurs implémentations pour s’assurer qu’elles n’exposent pas leurs utilisateurs à des attaques similaires. « Ces trois sites nous suffisent pour prouver notre point de vue, et nous avons décidé de ne pas chercher d’autres cibles, mais nous pensons que des milliers d’autres sites web sont vulnérables à l’attaque que nous détaillons dans cet article et mettent en danger des milliards d’internautes supplémentaires chaque jour », ont déclaré les chercheurs de Salt Security dans leur rapport.
Les jetons d’accès liés aux apps émettrices de la requête
Très populaire sur le web, la norme d’autorisation et de pseudo-authentification OAuth sert pour un site web ou une application à demander à un fournisseur d’identité comme Google, Facebook, Apple ou Microsoft de vérifier qu’un utilisateur est bien celui qu’il prétend être. Cette méthode facilite le processus d’authentification pour les utilisateurs, car ils peuvent utiliser leurs identités Facebook, Google ou Microsoft, ce qui leur évite de créer et de retenir des mots de passe distincts pour différents sites. En réalité, OAuth ne se limite pas à l’authentification. Le mécanisme offre aux utilisateurs d’accorder à des sites web externes l’accès à diverses informations de profil associées à chaque fournisseur d’identité via l’API du fournisseur. Cependant, ce problème découvert par Salt Security s’applique à la partie authentification, c’est-à-dire quand un site demande au fournisseur d’identité de confirmer que l’utilisateur est bien le propriétaire de l’identité (adresse électronique) qu’il souhaite utiliser. Et si pour leur démonstration, les chercheurs ont utilisé « Login with Facebook », elle pourrait techniquement fonctionner avec n’importe quel fournisseur d’identité.
Le processus OAuth fonctionne de la manière suivante : un utilisateur souhaite créer un compte sur un site web et choisit l’option « Login with Facebook » en fournissant une adresse électronique. Le site web redirige le navigateur de l’utilisateur vers Facebook afin d’apporter la preuve que l’utilisateur dispose bien d’un compte sous cette adresse électronique auprès du fournisseur d’identité. La première fois, pour confirmer que le site web ou l’application de tierce partie sont autorisés à accéder aux informations relatives à son compte, comme l’adresse électronique, Facebook affiche une demande d’autorisation à l’utilisateur. Ensuite, il génère un jeton secret et redirige le navigateur de l’utilisateur vers le site web demandeur, le jeton étant joint à l’URL de la requête.
Des permissions mémorisées
Le site web prend le jeton et l’utilise pour accéder à l’API Facebook Graph au nom de l’utilisateur et demande au réseau social quelle est l’adresse électronique associée au jeton. Facebook répondra avec l’adresse électronique de l’utilisateur et le site web aura la confirmation que l’utilisateur est bien celui qu’il prétend être et l’autorisera à créer son compte. Pour toute connexion ultérieure, le processus se répète, sauf que Facebook ne demandera plus à l’utilisateur de fournir un accès puisqu’il lui a déjà été accordé. L’utilisateur cliquera simplement sur « Login with Facebook », le site redirigera son navigateur vers Facebook pour obtenir un jeton, Facebook redirigera le navigateur de l’utilisateur vers le site avec le jeton attaché dans l’URL et le site utilisera le jeton pour confirmer le courriel de l’utilisateur via l’API de Facebook et le laisser entrer. Cependant, la sécurité de ce processus comporte un élément très important : Facebook, et tout fournisseur d’identité OAuth, lie le jeton à l’app ID du site web qui a demandé le jeton via le navigateur de l’utilisateur. Chaque site web ou application qui souhaite proposer la fonctionnalité « Login with Facebook » doit d’abord s’enregistrer auprès de Facebook et recevra son propre identifiant d’application unique dans la base de données de Facebook.
Le problème est qu’il incombe au site web de vérifier le jeton avant de l’accepter et de l’utiliser. Cette validation implique de vérifier que le jeton a été généré pour son propre app ID et non pour une autre application. Pour ce faire, une requête est adressée à un point de terminaison spécial de l’API de Facebook avant d’utiliser le jeton pour demander à Facebook de valider l’identité de l’utilisateur et de lui permettre d’accéder à son compte. Si cette étape est omise – et il s’avère que de nombreux sites web l’omettent – il est possible d’usurper l’identité de l’utilisateur et de s’emparer de son compte. Par exemple, un pirate peut créer un site web ou une application légitime qui fournit un service, l’enregistrer auprès de Facebook pour fournir la fonction « Login with Facebook », puis l’utiliser subrepticement pour générer et collecter des jetons OAuth auprès d’utilisateurs qui souhaitent légitimement utiliser le service. Les jetons que Facebook générera pour que les utilisateurs valident leur identité sur le site web de l’attaquant seront valides, même s’ils seront émis pour l’app ID du site web. Mais, si un autre site web ne vérifie pas l’identifiant d’application des jetons qu’il reçoit et se contente de les utiliser, l’attaquant pourrait prendre un jeton généré par un utilisateur pour son site web et l’utiliser sur un site web vulnérable pour accéder au compte de l’utilisateur sur ce site web. Si ce site est une plateforme de commerce électronique comme Bukalapak, l’utilisateur a peut-être stocké dans son profil des informations de facturation et de paiement. S’il s’agit d’un service comme Grammarly, l’utilisateur peut avoir des documents sensibles, etc.
Autres variantes et défauts d’implementation
OAuth est une norme complexe qui offre plusieurs variantes de mise en œuvre. Par exemple, au lieu d’utiliser des URL de redirection entre le site et le fournisseur d’identité, le site peut choisir d’utiliser la fonction PostMessage, mais l’attaque est toujours possible dans une telle implémentation si le jeton n’est pas validé. Le passage de jetons via des URL est potentiellement vulnérable aux attaques de type « man-in-the-middle » si un attaquant a la capacité de surveiller passivement le trafic et d’extraire le jeton OAuth de l’URL qu’il observe. Pour cette raison, OAuth propose également une approche plus sûre dans laquelle le fournisseur d’identité émet un code unique au lieu d’un jeton d’accès, puis le site web prend ce code avec un secret d’application que seuls lui-même et Facebook connaissent et échange le code en jeton à l’aide de l’API de Facebook. Grammarly a effectivement utilisé cette méthode plus sûre basée sur le code quand l’équipe de Salt Security a testé sa mise en œuvre d’OAuth. Cependant, les chercheurs ont constaté que le script OAuth de Grammarly prenait des requêtes avec le code d’entrée dans la requête et se sont demandés s’il pouvait inclure une fonction qui prendrait aussi des jetons. Ils ont donc essayé de faire des demandes en remplaçant le code par différents mots comme token, facebookToken, FBtoken et d’autres variations, jusqu’à ce qu’ils trouvent que access_token fonctionnait et était accepté.
En d’autres termes, ils ont réussi à faire passer l’implémentation de Grammarly à la variante la plus sécurisée parce que le code permettant de gérer les jetons directement à la place du code était encore laissé en option dans le script. Et il s’est avéré qu’il n’y avait pas d’étape de validation du jeton pour vérifier l’app ID. Par le passé, les chercheurs de Salt Security ont trouvé d’autres failles dans l’implémentation d’OAuth sur des sites web importants, dont certaines auraient pu permettre à des attaquants d’accéder à des comptes Booking.com. « Il est extrêmement important de s’assurer que l’implémentation d’OAuth est sécurisée », ont déclaré les chercheurs. « Le correctif se résume à une simple ligne de code. Quand OAuth sert pour fournir une authentification de service, toute faille de sécurité peut conduire au vol d’identité, à la fraude financière et à l’accès à diverses informations personnelles, y compris les numéros de cartes de crédit, les messages privés, les dossiers médicaux, et plus encore, en fonction du service spécifique attaqué », ont encore déclaré les chercheurs.
La fonction Rapid Reset du protocole HTTP/2 a été abusé pour mener des campagnes DDoS particulièrement efficaces et puissantes. Cloudflare, Google, AWS et d’autres publient des mesures d’atténuation de ce bug.
Au cours des deux derniers mois, des attaquants ont abusé d’une fonctionnalité du protocole de communication web HTTP/2 qui rend les serveurs d’applications web, les équilibreurs de charge et les proxys web vulnérables à des attaques par déni de service distribué (DDoS) d’une ampleur sans précédent. Google, AWS, CloudFlare et d’autres acteurs IT, ont travaillé sur des stratégies d’atténuation et des correctifs en privé avant de divulguer la faille.
Les attaques DDoS, baptisées HTTP/2 Rapid Reset, tirent parti de la capacité de multiplexage de flux du protocole HTTP/2. Il est capable d’envoyer plusieurs requêtes HTTP en parallèle sur la même connexion de transport TCP. Une fonction est en particulier ciblée, la réinitialisation unilatérale des flux. Les entreprises sont invitées à vérifier si leurs partenaires IT disposent de correctifs ou de recommandations d’atténuation pour cette faille répertoriée sous la référence CVE-2023-44487.
Des attaques DDoS plus efficaces
Dans l’ancienne version 1 du protocole HTTP, toujours prise en charge par la plupart des serveurs et des clients web, il est possible d’envoyer plusieurs requêtes sur une seule connexion TCP, mais cet envoi se fait en série et le serveur traite les requêtes et y répond dans l’ordre dans lequel elles ont été reçues. Dans le cas du HTTP/2, plusieurs requêtes appelées « flux » ou « streams » et composées de trames de type HEADERS ou DATA, peuvent être envoyées simultanément et dans le désordre sur une connexion TCP. En effet, dans le multiplexage de flux, chaque stream est associé à un identifiant, de sorte que le serveur sait toujours de quel flux fait partie la trame et comment y répondre.
Ce multiplexage offre une utilisation plus efficace des connexions TCP et accélère le temps de chargement des pages. Imaginons une page web moderne contenant une multitude de ressources, de scripts tiers et d’images chargées à partir de différents emplacements. Un navigateur accédant à une telle page via HTTP/2 commencera immédiatement à charger ces ressources en parallèle, en donnant la priorité à celles qui sont visibles par l’utilisateur. Si celui-ci clique immédiatement sur un bouton et quitte la page, le navigateur peut fermer les flux même si les ressources n’ont pas été entièrement chargées ou rendues sans fermer entièrement la connexion et ouvrir d’autres requêtes. « Depuis la fin 2021, la majorité des attaques DDoS de couche Layer 7 que nous avons observées sur les services de Google et les projets Google Cloud protégés par Cloud Armor sont basées sur le HTTP/2, à la fois en nombre d’attaques et en taux de requêtes maximales », ont déclaré les ingénieurs de Google dans un billet de blog expliquant la nouvelle attaque. « L’un des principaux objectifs du HTTP/2 était l’efficacité, et malheureusement, les fonctionnalités qui rendent le HTTP/2 plus efficace pour les clients légitimes peuvent également être utilisées pour rendre les attaques DDoS plus efficaces », ont ajouté les chercheurs.
Contournement des limites de flux simultanés
Étant donné qu’un serveur doit consommer des cycles de CPU et de la mémoire pour traiter chaque trame et chaque flux, les développeurs du protocole avaient conscience dès le départ qu’il serait possible d’abuser des flux simultanés pour épuiser les ressources d’un serveur, et donc de provoquer un déni de service. C’est pourquoi ils ont ajouté un paramètre appelé SETTINGS_MAX_CONCURRENT_STREAMS que le serveur communique aux clients des points terminaux lors de la première connexion via une trame SETTINGS. Par défaut, la valeur de ce paramètre est illimitée, mais les concepteurs du protocole recommandent qu’elle ne soit pas inférieure à 100 pour maintenir un parallélisme efficace. C’est pourquoi, dans la pratique, de nombreux clients n’attendent pas la trame SETTINGS et supposent simplement que la limite minimale est de 100 et envoient 100 trames dès le début. Le problème vient d’une autre fonctionnalité appelée RST_STREAM, qui signifie « reset stream » (réinitialisation du flux). Il s’agit d’un type de trame qu’un client peut envoyer à un serveur pour indiquer qu’un ID de flux précédemment ouvert doit être annulé.
Cela permet au client d’annuler les demandes de ressources à la volée qui ne sont plus nécessaires, parce que l’utilisateur a, par exemple, quitté la page avant que la ressource ne soit chargée. Elle est utile, car elle indique au serveur d’arrêter de répondre à une requête précédente et de ne pas gaspiller la bande passante. Mais il y a un hic. En envoyant une trame RST_STREAM, le flux ciblé n’est plus pris en compte dans la limite maximale de flux simultanés, de sorte que le client peut immédiatement ouvrir un nouveau flux après avoir envoyé une réinitialisation pour un flux précédent. Cela signifie que même avec une limite de 100 flux simultanés, le client peut ouvrir et réinitialiser des centaines de flux sur la même connexion TCP coup sur coup. Si bien que le serveur doit encore dépenser des ressources pour traiter les trames RST_STREAM. Même si ce n’est pas beaucoup, avec des millions de requêtes, cela s’accumule rapidement.
Des attaques DDoS plus puissantes
Grâce à cette technique, des attaquants ont réussi à lancer des attaques DDoS d’une ampleur sans précédent contre des serveurs hébergés par Google, Cloudflare et AWS. « Quand un serveur HTTP/2 est capable de traiter les trames RST_STREAM envoyées par les clients et de démanteler l’état assez rapidement, ces réinitialisations rapides ne posent pas de problème », ont expliqué les ingénieurs de Cloudflare dans leur rapport. « Les problèmes commencent à se poser en cas de retard ou de décalage dans le traitement. Le client peut envoyer tellement de requêtes qu’un arriéré de travail s’accumule, entraînant une consommation excessive des ressources sur le serveur ».
L’attaque HTTP/2 Rapid Reset la plus importante observée par Google a culminé à plus de 398 millions de requêtes par seconde (rps). À titre de comparaison, l’attaque la plus importante observée par l’entreprise en 2022 a culminé à 46 millions de requêtes par seconde. L’attaque ciblant Cloudflare en août a atteint 201 millions de requêtes par seconde, soit trois fois plus que la plus grande attaque DDoS détectée précédemment par le fournisseur. Cette attaque HTTP/2 Rapid Reset a été lancée à partir d’un botnet composé de 22 000 ordinateurs seulement, ce qui est peu par rapport à d’autres botnets.
Des mesures d’atténuation
Les stratégies d’atténuation de ces attaques ne sont pas simples, car certaines annulations RST_STREAM peuvent être légitimes, de sorte que chaque propriétaire de serveur doit décider quand il y a abus et comment adapter la réponse en fonction des statistiques de connexion et de la logique d’entreprise. Par exemple, si une connexion TCP a plus de 100 requêtes et que le client en annule plus de 50 %, la connexion peut être considérée comme abusive. Les réponses peuvent aller de l’envoi de trames GOAWAY énergiques à la fermeture immédiate de la connexion TCP. Une autre réponse pourrait consister à bloquer l’accès de l’adresse IP incriminée au service HTTP/2 et à la reléguer au seul HTTP 1.x de manière temporaire.
Le problème des filtres IP est que plusieurs clients peuvent partager la même adresse IP et qu’ils ne sont pas tous malveillants. En limitant les requêtes à HTTP 1.x, les clients non malveillants situés derrière une adresse IP filtrée pourront toujours accéder au service web, même si leurs performances s’en trouvent réduites. Les développeurs de Nginx, un reverse-proxy et équilibreur de charge très répandu, ont également proposé des mesures d’atténuation qui s’appuient sur des fonctionnalités spécifiques déjà mises en œuvre par le serveur, telles que keepalive_requests, limit_conn et limit_req. Ils livreront aussi un correctif dans les prochains jours qui limitera encore l’impact de ces attaques. Microsoft, AWS, F5 et d’autres entreprises d’infrastructure, de fournisseurs de serveurs web ou de logiciels de load balancing ont publié des mesures d’atténuation ou des correctifs. Les utilisateurs peuvent consulter régulièrement le formulaire officiel dans le CVE Tracker pour obtenir des liens avec les réponses mises à jour des fournisseurs.
Des chercheurs de Cisco ont détecté des backdoor qui se font passer pour des composants de l’agent Cortex XDR de Palo Alto Networks. La cible est un opérateur télécom pour toucher ses clients.
La série de backdoors découverte par des chercheurs en sécurité a été utilisée pour compromettre un opérateur de télécommunications au Moyen-Orient. On ne sait pas encore si ces programmes sont liés à un groupe de cyberattaques connu, mais ces dernières années, beaucoup d’acteurs étatiques ont ciblé des telcos, car leurs équipements réseaux peuvent servir de passerelles vers d’autres entreprises. C’est la première fois que les deux portes dérobées baptisées HTTPSnoop et PipeSnoop par les chercheurs de Cisco Talos sont mises en évidence, mais elles ont été créées par des attaquants ayant une bonne connaissance des rouages de Windows. Elles se font passer pour des composants du client de sécurité pour points d’extrémité Cortex XDR de Palo Alto Networks.
HTTPSnoop : un backdoor pour les serveurs ouverts sur Internet
En général, HTTPSnoop est déployé sous forme d’une DLL malveillante en utilisant des techniques de détournement de DLL, c’est-à-dire en incitant une application légitime à la charger en lui donnant un nom et un emplacement spécifiques. Une fois exécutée, elle utilise des API Windows de bas niveau pour accéder au périphérique HTTP dans le noyau et commencer à écouter les requêtes HTTP spécialement conçues. Le backdoor s’enregistre en tant que listener pour des URL spécifiques, auxquelles les attaquants peuvent ensuite envoyer des requêtes avec un mot-clé spécifique dans l’en-tête. Lorsqu’il reçoit de telles requêtes, HTTPSnoop décode le corps de la requête et en extrait un shellcode qu’il exécute ensuite sur le système. Les chercheurs de Talos ont trouvé plusieurs versions de cette porte dérobée, la seule différence résidant dans les URL qu’elles écoutent. L’une des versions s’enregistre en tant que listener d’URL HTTP qui ressemblent à celles utilisées par l’API Exchange Web Services (EWS) de Microsoft, ce qui laisse penser qu’elle a été conçue pour être déployée sur des serveurs Microsoft Exchange compromis et que les attaquants voulaient dissimuler les requêtes suspectes dans le trafic légitime.
Une autre version a écouté des URL qui ressemblaient à celles utilisées par l’application de gestion des ressources humaines OfficeTrack, anciennement appelée OfficeCore’s LBS System. Selon les chercheurs de Talos, cette application est commercialisée auprès des entreprises de télécommunications, ce qui suggère que les attaquants ont personnalisé leur porte dérobée pour chaque victime en se basant sur les logiciels qu’ils savent qu’ils exécutent sur leurs serveurs. « Les URL HTTP sont également constituées de modèles imitant les services d’approvisionnement d’une entreprise de télécommunications israélienne », ont déclaré les chercheurs. « D’après les résultats de sources ouvertes, il est possible que cet opérateur télécom ait utilisé OfficeTrack dans le passé et/ou qu’il utilise actuellement cette application. Certaines des URL de l’implant HTTPSnoop sont aussi liées à celles des systèmes de l’entreprise de télécommunications ». HTTPSnoop et sa porte dérobée sœur PipeSnoop se sont fait passer pour un fichier exécutable appelé CyveraConsole.exe, lequel appartient normalement à une application contenant l’agent Cortex XDR de Palo Alto Networks pour Windows. « Les variantes de HTTPSnoop et de PipeSnoop que nous avons découvertes présentaient des horodatages de compilation modifiés, mais elles se faisaient passer pour des agents XDR de la version 7.8.0.64264 », ont déclaré les chercheurs. « Cortex XDR v7.8 a été publié le 7 août 2022 et mis hors service le 24 avril 2023. Il est donc probable que les auteurs de la menace aient exploité ce groupe d’implants au cours de cette période ».
Les systèmes internes également ciblés par le backdoor PipeSnoop
PipeSnoop n’écoute pas les URL HTTP, mais un canal spécifique. Les canaux IPC (Inter-Process Communication) sont un mécanisme par lequel les processus locaux peuvent communiquer entre eux sur les systèmes Windows. L’utilisation de ce mécanisme comme moyen de commande et contrôle laisse penser que cette backdoor pourrait avoir été conçue pour des systèmes internes qui ne sont pas directement accessibles depuis lnternet, contrairement à HTTPSnoop. PipeSnoop ne peut pas fonctionner seul sur un système parce qu’il ne crée pas lui-même de canal spécifique, mais il en écoute seulement un. Cela signifie qu’un autre implant doit obtenir le shellcode des attaquants d’une manière ou d’une autre, puis créer un canal local spécifiquement nommé et transmettre le shellcode à PipeSnoop pour qu’il l’exécute.
Pour l’instant, les chercheurs de Talos n’ont pas encore identifié ce second composant. « Il est probable que PipeSnoop a été conçu pour fonctionner au sein d’une entreprise compromise, plutôt que sur des serveurs publics comme HTTPSnoop, et le backdoor est probablement destiné à être utilisé contre des terminaux que les opérateurs de malwares considèrent comme plus précieux ou plus prioritaires », ont déclaré les chercheurs de Talos.
Des cyberespions soutenus par l’Iran se sont servis de la méthode de pulvérisation des mots de passe pour recueillir des renseignements sur certaines industries (spatiales, défense et pharmaceutiques).
Microsoft a observé une activité suspecte autour d’un groupe de cyberespionnage nommé Peach Sandstorm, également connu dans le secteur sous les noms de Holmium, Elfin et APT33. Soutenu par l’Etat iranien, il a lancé des attaques en se servant de la technique de pulvérisation de mots de passe contre des milliers d’entreprises de différents secteurs activités (spatiales, défense et industrie pharmaceutique). « Une partie des actions post-compromission menées en 2023 par le groupe Peach Sandstorm a été furtive et sophistiquée », a déclaré Microsoft dans un rapport sur la campagne d’attaque qui s’est déroulée entre février et juillet. « Bon nombre des tactiques, techniques et procédures (TTP) basées sur le cloud et observées dans ces campagnes les plus récentes, sont matériellement plus sophistiquées que les capacités utilisées par Peach Sandstorm dans le passé ».
La pulvérisation de mots de passe, vecteur d’attaque préféré des espions
Cela fait depuis longtemps que le groupe se sert de la pulvérisation de mots de passe pour accéder à des cibles. Contrairement aux attaques par force brute où un grand nombre de combinaisons de mots de passe sont testées pour forcer l’accès à un seul compte, la méthode cible plusieurs comptes avec un seul ou un petit sous-ensemble de mots de passe courants. Il s’agit d’une attaque bruyante qui laisse des traces dans les logs et peut déclencher des mécanismes de défense, ce qui explique pourquoi ce n’est pas le seul vecteur d’accès initial utilisé par Peach Sandstorm. Quelques victimes ont été ciblées par des exploits pour des failles d’exécution de code à distance dans les produits Zoho ManageEngine et Confluence (CVE-2022-47966 et CVE-2022-26134). D’après les preuves récoltées, il semble qu’une grande partie du ciblage basé sur la pulvérisation de mots de passe était opportuniste, les attaquants visant des milliers de comptes et d’entreprises dans l’espoir de gagner l’accès au plus grand nombre possible de cibles, et de trier ensuite les victimes. Les attaques ont toujours eu lieu entre 9 heures et 17 heures, dans le fuseau horaire de l’Iran, et ont été lancées à partir d’adresses IP Tor avec un user agent de navigateur appelé « go-http-client ».
Pour une partie des comptes compromis, les attaquants ont utilisé AzureHound et ROADtools, deux frameworks open source qui peuvent être utilisés pour effectuer une reconnaissance dans les environnements Microsoft Entra ID (anciennement Azure Active Directory) en interagissant avec Microsoft Graph et les API REST dans le but d’exfiltrer des données d’intérêt du compte cloud d’une victime. « Les fonctionnalités AzureHound et Roadtools sont utilisées aussi bien par les défenseurs, les équipes rouges que par les adversaires », a fait remarquer Microsoft dans son rapport. « Les mêmes caractéristiques qui rendent ces outils intéressants pour des utilisateurs légitimes, par exemple ses capacités prédéfinies d’exploration et de vidage discret des données dans une seule base de données, en font également des options attrayantes pour les adversaires qui cherchent des informations sur ou à partir de l’environnement d’une cible », a ajouté Microsoft. Pour parvenir à la persistance, les attaquants ont mis en place des abonnements Azure sur les tenant des victimes, qui ont été utilisés pour établir une communication de commande et de contrôle avec l’infrastructure exploitée par le groupe. Ils ont aussi installé le client Azure Arc sur des appareils dans les environnements compromis et l’ont connecté à un abonnement Azure sous leur contrôle, ce qui leur a permis de prendre le contrôle à distance de ces appareils. La fonctionnalité Azure Arc permet de gérer à distance des systèmes Windows et Linux dans un environnement Azure AD.
Autres outils et techniques post-compromission
Après avoir obtenu la persistance, les attaquants de Peach Sandstorm ont déployé divers outils publics et personnalisés, dont AnyDesk, un outil commercial de Surveillance et gestion à distance (Remote monitoring and management, (RMM), et EagleRelay, un outil personnalisé de tunnelisation du trafic que les attaquants ont déployé sur des machines virtuelles créées dans les environnements des victimes. Parmi les autres techniques employées par le groupe figurent l’utilisation abusive du protocole RDP (Remote Desktop Protocol), l’exécution d’un code malveillant en détournant une DLL avec un exécutable VMware légitime et le lancement d’une attaque Golden SAML.
« Dans une attaque Golden SAML, un adversaire vole les clés privées du serveur Active Directory Federated Services (AD FS) sur site d’une cible et utilise les clés volées pour monnayer un jeton SAML approuvé par l’environnement Microsoft 365 d’une cible », a expliqué Microsoft. « En cas de succès, un acteur de la menace peut contourner l’authentification AD FS et accéder aux services fédérés comme n’importe quel utilisateur ». Microsoft recommande de traiter les serveurs AD FS comme des actifs Tier 0, car leur compromission peut donner aux attaquants le contrôle total de l’authentification des tenant Entra ID et d’autres parties de relais configurées.
Limiter les attaques par pulvérisation de mot de passe
L’entreprise recommande également de réinitialiser les mots de passe des comptes et les cookies de session pour tous les comptes ciblés par une attaque par pulvérisation de mot de passe, ainsi que d’effectuer des investigations supplémentaires si les comptes ciblés disposent d’autorisations au niveau du système. Les paramètres d’authentification multifactorielle (MFA) des comptes doivent également être examinés et toute modification apportée par les attaquants doit être révoquée.
Microsoft recommande par ailleurs :
– de créer des politiques d’accès conditionnel pour autoriser ou interdire l’accès à l’environnement en fonction de critères définis.
– de bloquer l’authentification traditionnelle avec Entra ID en utilisant l’accès conditionnel. Les protocoles d’authentification traditionnels n’ont pas la capacité d’appliquer la MFA, et le blocage de ces méthodes d’authentification empêchera les attaquants par pulvérisation de mot de passe de profiter de l’absence d’authentification multifactorielle sur ces protocoles.
– d’activer le verrouillage de l’extranet du proxy de l’application web AD FS pour protéger les utilisateurs contre la compromission potentielle par force brute du mot de passe.
– d’appliquer le principe du moindre privilège et de vérifier l’activité des comptes à privilèges dans les environnements Microsoft Entra ID afin de ralentir et d’arrêter les attaquants.
– de déployer Entra ID Connect Health pour Active Directory Federation Services (AD FS) de façon à pouvoir capturer les tentatives infructueuses ainsi que les adresses IP enregistrées dans les journaux AD FS et d’inscrire les mauvaises requêtes dans le rapport Risky IP.
– d’utiliser la protection des mots de passe Entra ID pour détecter et bloquer les mots de passe faibles connus et leurs variantes.
– d’activer la protection de l’identité dans Entra ID pour surveiller les risques liés à l’identité et créer des politiques pour les connexions à risque.
– d’utiliser l’authentification multifactorielle MFA pour limiter les attaques par pulvérisation de mot de passe ; de garder la MFA toujours active pour les comptes à privilèges et d’appliquer une MFA basée sur les risques pour les comptes normaux.
– d’envisager de basculer vers une méthode d’authentification primaire sans mot de passe, comme Azure MFA, les certificats ou Windows Hello for Business.
– de sécuriser les points d’extrémité RDP ou Windows Virtual Desktop avec la MFA pour les protéger contre les attaques par pulvérisation de mot de passe ou par force brute.
Une faille dans les fichiers configuration YAML des clusters Kubernetes est capable d’accorder des privilèges systèmes sur les hôtes Windows. La brèche a été réparée dans la dernière version de l’orchestrateur de cluster de conteneurs.
La dernière version de Kubernetes publiée le mois dernier corrige toute une classe de vulnérabilités à partir desquelles des attaquants pouvaient abuser de la propriété subPath des fichiers de configuration YAML pour exécuter des commandes malveillantes sur les hôtes Windows. « La vulnérabilité permet l’exécution de code à distance avec des privilèges SYSTEM sur tous les terminaux Windows au sein d’un cluster Kubernetes », a déclaré Tomer Peled, chercheur chez Akamai, à propos de la vulnérabilité qu’il a trouvée et qui a débouché sur la découverte de deux autres problèmes similaires. « Pour exploiter cette vulnérabilité, l’attaquant doit appliquer un fichier YAML malveillant sur le cluster », a ajouté le chercheur.
Les fichier de configuration vulnérables
Un très grand nombre d’entreprises utilisent le système d’orchestration de cluster de conteneurs Kubernetes pour automatiser le déploiement et la gestion des applications exécutées dans des conteneurs. Et c’est le langage YAML qui sert à écrire des fichiers de configuration et d’autres fichiers de gestion pour Kubernetes. Il était donc assez logique qu’il soit une cible pour les attaquants potentiels, car il offre un moyen direct d’envoyer des données utilisateur au moteur Kubernetes pour qu’elles soient analysées et interprétées. Les problèmes de parsing de YAML ont déjà conduit à des brèches dans Kubernetes. Par exemple, la CVE-2022-1471 générant dans l’analyseur SnakeYaml a eu un impact sur le client Java de Kubernetes. C’est aussi le cas de la CVE-2021-25749 capable d’inclure des noms d’utilisateur mal orthographiés dans un fichier YAML, entraînant ainsi l’exécution de charges de travail en tant que root.
Et ce n’est pas tout : deux vulnérabilités CVE-2017-1002101 et CVE-2021-25741 combinées avec des liens symboliques (symlinks) ont montré qu’il était possible d’utiliser la sous-propriété subPath d’un fichier YAML pour accéder à des fichiers en dehors du conteneur, rompant ainsi l’isolation. Ces deux dernières failles ont donné à Tomer Peled l’idée d’approfondir le sujet. Grâce à une propriété appelée « Volume », Kubernetes peut monter un répertoire depuis le système hôte à l’intérieur d’un conteneur. Cette fonctionnalité largement utilisée s’accompagne de plusieurs sous-propriétés qui définissent le chemin du répertoire sur l’hôte et celui de montage à l’intérieur du conteneur. Le mountPath possède en outre une propriété subPath qui, lorsqu’elle est fournie dans un fichier YAML, est traitée par kubelet, un service central de Kubernetes.
Le traitement des chemins d’accès pointé du doigt
Le chercheur d’Akamai a découvert que lorsque la chaîne subPath est traitée, kubelet vérifie également s’il s’agit d’un lien symbolique, conformément aux défenses mises en place pour les anciennes vulnérabilités. Sauf qu’il le fait par le biais d’une commande PowerShell invoquée par l’appel de fonction « exec.Command ». Or, un attaquant peut attacher du code PowerShell à la chaîne subPath et l’exécuter. « Avec PowerShell, les utilisateurs sont capables d’évaluer les valeurs à l’intérieur des chaînes avant qu’elles ne soient utilisées », a précisé le chercheur. « Cela peut se faire en ajoutant $() à la chaîne […]. N’importe quelle commande PowerShell peut être insérée entre les parenthèses et sera évaluée – comme $(Start-Process cmd), $(Invoke-Expression exp), et autres traitements PowerShell ».
Fichier YAML avec injection de commande dans le paramètre subPath. (Crédit Photo : Akamai)
Ainsi, par exemple, si un attaquant fournit un fichier YAML à un nœud Kubernetes qui fonctionne sous Windows avec un sous-chemin qui inclut $(Start-Process cmd), celui-ci sera envoyé à PowerShell par kubelet pendant le processus de validation du chemin et sera exécuté avec les privilèges Windows du service kubelet – SYSTEM. Cette faille est désormais répertoriée avec la référence CVE-2023-3676 et a été corrigée dans Kubernetes 1.28, mais elle a également conduit à la découverte et à la correction de deux autres brèchess similaires d’injection de commande référencées CVE-2023-3955 et CVE-2023-3893. La faille a un impact sur Kubernetes sous Windows dans sa configuration par défaut, mais l’attaquant doit obtenir des privilèges d’application sur un nœud.
Atténuer la vulnérabilité basée sur YAML
« L’équipe Kubernetes a choisi de corriger cette classe de vulnérabilités en passant des paramètres à partir de variables d’environnement plutôt qu’à partir d’entrées utilisateur », a observé Tomer Peled. « En transmettant les valeurs de cette manière, les paramètres sont traités comme des chaînes de caractères – par conséquent, ils ne seront pas évalués comme des expressions par PowerShell. S’ils ne peuvent pas mettre à jour immédiatement la version corrigée, les administrateurs peuvent désactiver l’utilisation de Volume.Subpath, mais cela désactivera également une fonctionnalité couramment utilisée. Une autre option consiste à utiliser l’Open Policy Agent (OPA), un agent open source qui peut prendre des mesures basées sur des politiques en fonction des données reçues.
Les administrateurs peuvent créer des règles pour bloquer la mise en œuvre de certains fichiers YAML à l’aide du langage Rego dans l’OPA, et Akamai fournit un exemple d’une telle règle de blocage dans son article de blog. Le chercheur recommande enfin d’utiliser le contrôle d’accès basé sur les rôles (Role-based Access Control, RBAC) pour limiter le nombre d’utilisateurs pouvant effectuer des actions sur un cluster.
Un groupe de cybercriminels compromet des serveurs Microsoft SQL pour livrer le ransomware FreeWorld et l’outil Cobalt Strike.
La société Securonix, spécialisée dans la sécurité, a observé une campagne d’attaques nommée DB#JAMMER. Particularité de cette offensive, les cybercriminels arrivent à compromettre des serveurs Microsoft SQL et déployer à la fois l’outil Cobalt Strike et le ransomware FreeWorld (un dérivé de Mimic). Pour cela, ils se servent de plusieurs outils, dont « des logiciels d’énumération de répertoire et de vol d’identifiants, des payload RAT et de ransomware ».
Accès initial aux serveurs Microsoft SQL et persistance de l’attaque
Les attaquants utilisent des techniques de force brute pour deviner les informations d’identification des serveurs Microsoft SQL ciblés, mais les chercheurs ne savent pas très bien si ces tentatives sont basées sur le dictionnaire ou sur un essaimage de mots de passe. Dans ce dernier cas, ils s’appuient généralement sur des combinaisons de noms d’utilisateur et de mots de passe obtenues à la suite d’autres fuites de bases de données. Après l’accès initial, les attaquants ont parcouru la base de données en listant tous les utilisateurs y ayant accès et vérifié si une fonction appelée xp_cmdshell était activée. Cette instruction Transact-SQL offre aux utilisateurs de bases de données d’exécuter des commandes shell sous Windows et de renvoyer la sortie sous forme de texte. Les attaquants ont largement utilisé xp_cmdshell, d’abord pour recueillir des informations sur le système et l’environnement réseau en invoquant des outils Windows comme wmic.exe, net.exe et ipconfig.exe, puis pour apporter des modifications aux comptes Windows et à la base de registre du système. « Trois nouveaux utilisateurs ont été créés sur l’hôte victime, à savoir windows, adminv$ et mediaadmin{{%%ltplaceholder%%}}nbsp;», ont encore expliqué les chercheurs de Securonix. « Chaque utilisateur a été ajouté aux groupes ‘utilisateurs distants’ (remote desktop users) et ‘administrateurs’ (administrators). « Il est intéressant de remarquer que les attaquants ont tenté d’exécuter une grande ligne de commande qui créerait les utilisateurs et modifierait l’appartenance aux groupes. Cependant, plusieurs variantes de la commande ont été exécutées pour tenir compte de la langue des groupes : « anglais, allemand, polonais, espagnol et catalan ».
D’autres modifications ont été apportées aux utilisateurs récents afin que leurs mots de passe et leurs sessions de connexion n’expirent jamais. Les modifications apportées au registre étaient également importantes et comprenaient l’activation du service RDP (Remote Desktop Protocol), la désactivation des restrictions de contrôle d’accès des utilisateurs et le masquage des utilisateurs connectés à distance sur l’écran de connexion local. L’objectif était de permettre aux attaquants de contrôler le système à distance par une méthode plus fiable et plus difficile à détecter que les commandes xp_cmdshell de la base de données. Cependant, l’un des problèmes rencontrés était que les connexions RDP entrantes étaient bloquées par le pare-feu du réseau, de sorte qu’ils ont tenté de déployer un proxy inverse et une solution de tunneling appelée Ngrok.
Un ransomware dérivé de Mimic
Les cybercriminels ont aussi mis en place un partage SMB à distance vers un serveur sous leur contrôle afin de monter localement un répertoire contenant un grand nombre de leurs outils et charges utiles. Il s’agissait en particulier d’un agent de commande et de contrôle Cobalt Strike enregistré sous le nom srv.exe et d’une version du logiciel de bureau à distance AnyDesk. Un scanner de ports réseau et les outils de dumping d’identifiants Mimikatz ont également été déployés pour tenter un mouvement latéral vers d’autres systèmes sur le réseau.
Enfin, quand les pirates ont considéré que le système était entièrement sous leur contrôle, ils ont déployé un fichier appelé 5000.exe qui était un dropper pour un programme de ransomware que les attaquants appellent FreeWorld, mais qui est en fait une variante plus récente du ransomware connu Mimic. Les deux utilisent une application annexe appelée Everything.exe, qui sert à localiser les fichiers à chiffrer. Ceux-ci sont stockés avec une extension .FreeWorldEncryption et le ransomware dépose un fichier contenant des instructions sur la manière de payer la rançon, appelé FreeWorld-Contact.txt.
Défenses contre les attaques basées sur Microsoft SQL
Selon un rapport publié en juillet par l’entreprise de sécurité Trustwave, Microsoft SQL est de loin le système de gestion de bases de données relationnelles le plus ciblé et la plupart des attaques procèdent à des techniques de force brute pour deviner les mots de passe. Il est donc essentiel de disposer de mots de passe uniques et complexes pour les bases de données MSSQL exposées à Internet. Comme le montre également cette attaque, la procédure xp_cmdshell peut présenter un risque sérieux et devrait être limitée autant que possible sur les systèmes. Sans cette procédure, les attaquants auraient eu beaucoup plus de mal à obtenir l’exécution de codes à distance sur les systèmes. Les chercheurs de Securonix conseillent par ailleurs d’utiliser si possible des tunnels VPN pour accéder aux serveurs MSSQL au lieu de les exposer directement à Internet, de surveiller les répertoires de stockage de logiciels malveillants courants tels que « C:WindowsTemp » et de déployer une journalisation au niveau du processus comme Sysmon et PowerShell.
Des chercheurs ont démontré la capacité pour des attaquants à se servir de la synchronisation inter tenant d’Azure Active Directory pour accéder à des applications Microsoft et tierces.
Depuis longtemps, les techniques de mouvement latéral jouent un rôle essentiel dans la compromission des réseaux traditionnels. Elles sont utilisées par les groupes de ransomware pour atteindre les contrôleurs de domaine et déployer leurs attaques paralysantes et hautement perturbatrices. Elles sont tout autant utilisées par les groupes de cyber-espions pour gagner en persistance et accéder aux systèmes abritant la propriété intellectuelle sensible. Ces procédés sont aussi prisés des groupes de cybercriminels pour naviguer dans un réseau sensible et atteindre des guichets automatiques et autres systèmes financiers.
CTS, une fonction importante pour les grands comptes
Avec l’accélération du déploiement de réseaux hybrides combinant des infrastructures sur site et dans le cloud, les attaquants recherchent d’autres tactiques pour réaliser des mouvements latéraux dans ces environnements. L’une de ces méthodes, récemment imaginée et documentée par des chercheurs de l’entreprise de sécurité Vectra AI, consiste à abuser d’une fonctionnalité d’Azure Active Directory (AD) appelée cross-tenant synchronization (CTS) ou synchronisation inter-locataire. Celle-ci offre aux entreprises de synchroniser les utilisateurs et les groupes à travers différentes instances Azure AD pour qu’ils puissent accéder aux applications Microsoft et tierces liées à différents tenants.
Cette fonction est utile pour les grands comptes et les sociétés disposant de filiales ou succursales disposant de plusieurs tenants Azure AD. Certains utilisateurs ont besoin d’accéder aux applications ou aux ressources d’une autre succursale ou d’une filiale. « Ce vecteur offre à un attaquant opérant dans un tenant compromis d’abuser d’une mauvaise configuration de synchronisation entre les tenants et d’accéder à d’autres tenants connectés ou de déployer une configuration CTS malveillante pour maintenir la persistance au sein de l’instance », ont déclaré les chercheurs de Vectra AI dans leur rapport. « Nous n’avons pas observé l’utilisation de ce procédé dans la nature, mais étant donné l’abus historique d’une fonctionnalité similaire, nous présentons la technique en détails pour que les défenseurs comprennent comment se passerait une telle attaque et comment surveiller son exécution », ont-ils ajouté.
Des politiques d’accès et de configuration vulnérables
Dans le détail, la fonction CTS synchronise les droits et les permissions des utilisateurs d’un tenant source vers une instance cible. Ce rapprochement s’effectue par le biais de requêtes push depuis le tenant source et sur la base des politiques d’accès interlocataires (Cross-Tenant Access, CTA) configurées dans les deux tenants. Ces derniers doivent avoir une politique d’accès similaire et réciproque. Comme pour toutes les techniques de mouvement latéral, l’abus de CTS implique la compromission supposée d’identifiants privilégiés au sein d’une instance.
Pour qu’une attaque fonctionne, les deux tenants doivent disposer de licences Azure AD Premium P1 ou P2 incluant l’usage de la CTS. L’attaquant doit avoir accès à un compte avec un rôle d’administrateur de sécurité pour configurer les politiques d’accès interlocataires, un rôle d’administrateur d’identité hybride pour modifier la configuration de synchronisation interlocataires, ou un rôle d’administrateur cloud ou d’application pour assigner des nouveaux utilisateurs à une configuration CTS existante. Ainsi, en fonction des politiques d’accès et de la configuration CTS existantes dans un tenant, et donc des privilèges obtenus par l’attaquant, il existe différentes façons d’abuser de cette situation pour un mouvement latéral ou une persistance. Le PoC de Vectra AI suppose que le tenant dispose déjà des politiques d’accès configurées pour d’autres tenants. Dans un premier temps, l’attaquant utilisera la commande shell admin pour lister tous les instances avec lesquels le tenant actuel a des politiques d’accès. Ensuite, il examinera chacune des politiques afin d’en identifier un pour lequel une politique de sortie existe. Cela signifie que le locataire actuel est configuré pour synchroniser les utilisateurs avec ce locataire cible.
Backdoor et persistance
L’étape suivante consisterait à localiser l’identifiant de l’application exécutée dans le tenant compromis, responsable de la synchronisation, pour pouvoir modifier sa configuration. Les chercheurs de Vectra ont créé et publié un script PowerShell qui automatise l’ensemble du processus. « Il n’y a pas de moyen direct de trouver l’application de synchronisation CTS liée au tenant cible », ont déclaré les chercheurs. « L’attaquant peut énumérer les principaux services du tenant en essayant de valider les identifiants avec le tenant cible pour finalement trouver l’application qui héberge le travail de synchronisation avec le locataire cible. Il peut le faire à l’aide d’un simple module comme celui-ci ». Après avoir identifié l’application de synchronisation, l’attaquant peut ajouter le compte compromis pour lequel il possède déjà des identifiants à la synchronisation étendue ou il peut examiner la synchronisation étendue de l’application, qui pourrait, par exemple, indiquer que tous les utilisateurs d’un groupe particulier sont synchronisés dans le locataire cible. Ils peuvent alors essayer d’ajouter directement ou indirectement leur utilisateur compromis à ce groupe.
Outre l’utilisation d’un locataire compromis comme source de mouvement latéral, la synchronisation interlocataire CTS peut également être utilisée comme porte dérobée pour maintenir la persistance au sein d’une instance compromise. Par exemple, l’attaquant pourrait créer une politique d’accès croisé entrant dans le locataire victime pour permettre à un locataire externe sous son contrôle de synchroniser les utilisateurs dans ce locataire. Il pourrait ensuite activer l’option « consentement automatique de l’utilisateur » afin que l’utilisateur synchronisé ne soit pas invité à donner son accord. Le résultat serait que l’attaquant pourrait synchroniser de nouveaux utilisateurs de son locataire externe avec le locataire victime à tout moment dans le futur pour accéder aux ressources, même s’il perd l’accès au compte initial qu’il a compromis.
Quelles parades ?
Étant donné que cette technique suppose qu’un compte existant a été compromis, les entreprises doivent appliquer des pratiques de sécurité strictes et surveiller les comptes, en particulier ceux qui ayant des privilèges d’administration. Les locataires pour lesquels la CTS est activée doivent éviter les politiques d’accès interlocataires entrantes qui synchronisent tous les utilisateurs, groupes ou applications d’un locataire source. « Déployez une configuration Cross-Tenant Access (CTA) entrante moins inclusive, en définissant par exemple explicitement les comptes (si possible) ou les groupes qui peuvent obtenir un accès via la CTS », recommandent les chercheurs de Vectra AI. « Combinez la politique d’accès interlocataires CTA avec d’autres politiques d’accès conditionnel pour empêcher les accès non autorisés ».
Technique de détournement de la bande passante des entreprises, le proxyjacking connait une recrudescence dans le monde des cybercriminels. Plusieurs campagnes ont été détectées par Akamai qui se servent notamment de conteneurs Docker.
Baptisé à un moment proxyware (par Cisco Talos en 2021) ou proxyjacking, ce procédé consiste à payer un utilisateur pour pouvoir se servir d’une partie de la bande passante inutilisée. Une technique encore plus rémunératrice si elle se fait sur le réseau de l’entreprise, mais parfaitement illégale et dangereuse. Si le concept n’est pas nouveau, « la possibilité de le monétiser facilement par des affiliés de groupes connus l’est », souligne un rapport d’Akamai. « Comme il offre un moyen facile de gagner de l’argent, ce vecteur représente une menace pour le monde de l’entreprise, comme pour le grand public, d’où la nécessité d’accroître la sensibilisation à ce problème et espérons-le son atténuation », ajoute le spécialiste du CDN.
Plusieurs campagnes détectées
Dans plusieurs campagnes sur lesquelles l’équipe d’Akamai a récemment enquêté, les attaquants ont utilisé des identifiants SSH compromis pour déployer une série de scripts qui ont transformé les serveurs en clients proxy sur les réseaux Peer2Profit et Honeygain. Ces deux services, présentés comme des outils de revenus passifs, permettent aux utilisateurs de partager leur bande passante et leur adresse IP inutilisées dans le cadre d’un réseau partagé de serveurs proxy, réseau utilisé ensuite par des entreprises payantes pour la collecte de données, la publicité et d’autres activités.
Pour ces services basés sur le volontariat, les personnes doivent installer une application client sur leur ordinateur ou leur téléphone portable. « La situation est complètement différente si une application est déployée à l’insu ou sans le consentement de l’utilisateur, et qu’elle sert à exploiter ses ressources », ont déclaré les chercheurs d’Akamai. « C’est à ce moment-là que l’usage apparemment anodin de ces services bascule dans la cybercriminalité. En réquisitionnant plusieurs systèmes et leur bande passante, l’attaquant augmente effectivement les gains potentiels qu’il peut tirer du service, et cela, aux dépens des victimes », ont-ils ajouté. Dans le concept, cette attaque est proche du cryptojacking, qui consiste à utiliser les ressources informatiques d’une machine pour miner des crypto-monnaies à l’insu ou sans l’accord du propriétaire du système.
Proxyjacking via des conteneurs Docker
Dans les attaques observées par Akamai via ses pots de miel, les attaquants se sont d’abord connectés via SSH et ont exécuté un script Bash codé en Base64. L’objectif de ce script est de se connecter à un serveur contrôlé par l’attaquant et de télécharger un fichier appelé csdark.css. Or ce fichier est une version compilée de curl, un outil de ligne de commande Linux très utilisé pour télécharger des fichiers. L’exécutable n’est détecté par aucun moteur antivirus sur VirusTotal car il s’agit d’une version légitime et non modifiée de curl, qui figure probablement sur la liste blanche des outils système. Une fois curl déployé sur le système, le script Bash change le répertoire de travail en un répertoire temporaire, généralement accessible en écriture et exécutable par tous les utilisateurs, tel que /dev/shm ou /tmp. Il procède ensuite au téléchargement d’une image de conteneur Docker préchargée et préconfigurée avec les clients Peer2Profit ou Honeygain, ainsi qu’avec l’identifiant d’affilié de l’attaquant sur les réseaux, afin que les systèmes détournés soient enregistrés sous leur compte.
Avant de déployer l’image de conteneur Docker téléchargée sous le nom de postfixd, le script vérifie si d’autres conteneurs concurrents, éventuellement déployés par d’autres attaquants, sont en cours d’exécution et arrête ceux qu’il trouve. Postfix est un agent de transfert de courrier électronique très répandu sous Linux. Les attaquants ont donc choisi ce nom suivi de d (daemon) pour que leur conteneur soit moins visible dans la liste des processus du système. Peer2Profit et Honeygain fournissent tous deux des images Docker publiques pour leurs clients et avec plus d’un million de téléchargements, elles sont assez populaires, de sorte que les attaquants n’ont pas eu grand-chose à faire pour mettre en place l’environnement et les outils. Il semble que le serveur web sur lequel les attaquants hébergent leur exécutable curl rebaptisé a été piraté et qu’il contient un outil de cryptomining. Il est donc probable que les attaquants à l’origine de ces campagnes de proxyjacking se livrent également au cryptojacking. « Dans cette campagne particulière, le SSH a été utilisé pour accéder à un serveur et installer un conteneur Docker, mais dans les campagnes précédentes, les pirates ont aussi exploité des vulnérabilités web », ont déclaré les chercheurs d’Akamai. « Si, après vérification des services Docker locaux en cours d’exécution, l’équipe IT trouve un partage de ressources indésirable sur un système, elle doit enquêter sur l’intrusion, déterminer comment le script a été téléchargé et exécuté, et effectuer un nettoyage complet », ont recommandé les chercheurs.
Selon des enquêtes, au moins une vingtaine d’entreprises sont tombées dans les mailles du filet du groupe Clop. Le ransomware se sert de l’exploit dans l’outil de transfert de fichiers Moveit Transfer.
La menace grandit autour de l’exploitation d’une faille critique dans un outil managé de transfert de fichier reconnu, Moveit Transfer. En effet, le groupe de ransomware Clop en fait un usage massif contre plusieurs entreprises. Un rapport de SentinelOne a listé une vingtaine d’entreprises tombées dans la nasse du gang. Plusieurs secteurs sont concernés : l’aviation, le transport, la logistique, le divertissement, les services financiers, l’assurance, la santé, les produits pharmaceutiques, le manufacturing, les médias, l’IT et les services publics.
Dans les revendications du groupe Clop sur son site, il explique avoir effacé les données exfiltrées appartenant à des gouvernements, des municipalités ou des services de police. La raison indiquée est qu’ »il n’a aucun intérêt à exposer de telles informations ». Un moyen certainement d’éviter de s’attirer les foudres de certains Etats, en particulier des Etats-Unis.
Un groupe très actif et techniquement avancé
Le gang Clop, également connu sous le nom TA505 dans le secteur de la sécurité, est impliqué dans la distribution de ransomware et l’extorsion depuis 2019. Selon un avis de la CISA, à ce jour, le groupe a compromis plus de 3 000 entreprises aux États-Unis et plus de 8 000 dans le monde. Outre l’exploitation du ransomware-as-a-service Clop, le groupe a aussi agi en tant que courtier d’accès initial (Initial Access Broker, IAB), vendant l’accès aux réseaux d’entreprise compromis à d’autres groupes, et a exploité un vaste botnet spécialisé dans la fraude financière et le phishing. Le développement de trois exploits de type « zero-day » pour les dispositifs Accellion File Transfer Appliance (FTA) en 2020 et 2021, les serveurs Fortra/Linoma GoAnywhere MFT au début de 2023, et maintenant l’application Moveit, témoignent des compétences techniques et des ressources du groupe.
Celui-ci a par ailleurs développé une boîte à outils de malwares diversifiée et des webshells personnalisés pour ces attaques au lieu de s’appuyer sur des outils open-source prêts à l’emploi comme d’autres groupes d’extorsion ciblant les serveurs web. « Les acteurs de l’extorsion axés sur le cloud, comme Bianlian et Karakurt, utilisent des outils de gestion de fichiers polyvalents comme Rclone et Filezilla », ont expliqué les chercheurs de SentinelOne. « Un webshell sur mesure conçu pour voler des fichiers Azure par le biais de requêtes SQL spécifiques à l’environnement ciblé représente un écart notable par rapport à cette pratique établie et suggère que l’outil a probablement été développé et testé bien avant les attaques ITW (In-the-Wild) menées dans le monde réel », ont-ils ajouté.
Des campagnes de repérage très précoces
SentinelOne note une tendance à l’exploitation des failles de type « zero-day » et « N-day » dans les applications de transfert de fichiers gérées par les entreprises, un autre exemple étant l’exploitation d’une faille de désérialisation dans le logiciel de partage de fichiers IBM Aspera Faspex en mars qui a conduit au déploiement du ransomware IceFire. « Il existe vraisemblablement un écosystème de développement d’exploits abondant axé sur les applications de transfert de fichiers d’entreprise », ont conclu les chercheurs dans leur rapport. Plus inquiétant encore, parmi les cibles de l’exploit Moveit, SentinelOne a trouvé des MSP et des MSSP, des fournisseurs de services IT ou de sécurité managés. Ce genre d’entreprises sont des cibles de grande valeur pour les groupes de ransomware car ils détiennent potentiellement des données utiles pour accéder à de nombreuses autres entreprises.
En surveillant ses pots de miel, la société de cyberassurance Coalition a constaté un pic de trafic le 15 mai sur le chemin légitime /human.aspx des déploiements de Moveit Transfer, ce qui indique que les attaquants étaient probablement en train de faire de la reconnaissance pour établir une liste de cibles. Selon Caitlin Condon, responsable de la recherche en sécurité chez Rapid7, la première attaque confirmée a été enregistrée le 27 mai, soit quatre jours avant que l’exploit ne soit rendu public, les attaquants disposant généralement d’un délai de 24 à 48 heures pour exfiltrer les données. Depuis la divulgation publique, Rapid7 a constaté une augmentation des correctifs et un ralentissement du nombre de tentatives d’exploitation. Le rapport SentinelOne contient des requêtes de recherche de menaces que les entreprises peuvent utiliser pour rechercher des activités associées à ces attaques dans leurs environnements, et l’avis CISA contient des règles de détection YARA et des indicateurs de compromission.
La preuve de concept étant disponible publiquement, certaines vulnérabilités corrigées par Cisco pourraient conduire à la compromission complète de l’appareil.
La semaine dernière, Cisco a corrigé plusieurs vulnérabilités affectant divers modèles de commutateurs pour petites entreprises qui peuvent permettre la prise de contrôle total des appareils à distance par des attaquants. Les failles sont toutes situées dans l’interface de gestion web des appareils et peuvent être exploitées sans authentification. Même si l’équipementier n’a fourni aucune information sur les composants spécifiques de l’interface web dans lesquels se trouvent les failles, l’avis indique que les vulnérabilités ne sont pas dépendantes les unes des autres et peuvent être exploitées de manière indépendante. Étant donné que les failles peuvent être exploitées sans authentification, on peut en déduire qu’elles se trouvent probablement dans des fonctionnalités qui ne nécessitent pas d’authentification ou pour lesquelles le mécanisme d’authentification peut être contourné.
La première hypothèse semble la plus probable, car aucune des failles n’est décrite comme un contournement de l’authentification. Si pour l’instant Cisco n’a constaté aucune exploitation malveillante de ces failles, l’entreprise a fait remarquer qu’un code d’exploitation de preuve de concept était déjà disponible publiquement pour ces vulnérabilités. Les attaquants doivent avoir accès à l’interface de gestion web, ce qui est possible, soit directement, si l’interface de gestion est exposée à Internet, soit indirectement, après l’intrusion dans un réseau interne utilisant un commutateur vulnérable.
Compromission complète, déni de service et fuite de données
Quatre des failles sont décrites comme des débordements de mémoire tampon et peuvent être exploitées pour exécuter un code arbitraire avec des privilèges d’administrateur (root). Il en résulte généralement une compromission complète de l’appareil. Ces quatre failles sont répertoriées sous les références CVE-2023-20159, CVE-2023-20160, CVE-2023-20161 et CVE-2023-20189. Toutes ont un score de 9,8 sur 10 sur l’échelle de gravité Common Vulnerability Scoring System (CVSS). Quatre autres failles sont également décrites comme des conditions de débordement de la mémoire tampon, mais elles ne peuvent conduire qu’à un déni de service contre les appareils vulnérables lors du traitement de requêtes malveillantes.
Ces failles sont répertoriées sous les références CVE-2023-20156, CVE-2023-20024, CVE-2023-20157 et CVE-2023-20158 et ont un score de 8,6 sur l’échelle de gravité CVSS. La dernière faille est décrite comme une erreur de lecture de configuration et peut permettre à des attaquants de lire des informations non autorisées à partir d’un appareil affecté sans authentification. Cette faille, répertoriée sous la référence CVE-2023-20162, a un score de gravité de 7.5 (élevé).
Mettre à jour vers le dernier firmware
Les vulnérabilités affectent la version 2.5.9.15 et les versions antérieures du firmware de Cisco pour les commutateurs Smart Switches de la série 250, les Managed Switches de la série 350, les Stackable Managed Switches de la série 350X et les Stackable Managed Switches de la série 550X, ainsi que la version 3.3.0.15 et les versions antérieures du firmware des Smart Switches de la série Business 250 et des Smart Switches de la série Business 350. L’équipementier a livré les versions 2.5.9.16 et 3.3.0.16 du firmware, respectivement.
Les Smart Switches de la série Small Business 200, les Managed Switches de la série Small Business 300 et les Stackable Managed Switches de la série Small Business 500 sont également concernés, mais ils ne recevront pas de mise à jour de leur firmware car ils sont arrivés en fin de vie. Cisco indique par ailleurs que toutes les versions de firmwares concernées ne sont pas affectées par toutes les vulnérabilités, ce qui laisse penser que certaines failles pourraient être spécifiques à une version. Néanmoins, les clients devraient mettre à jour vers la dernière version du firmware dès que possible, car il n’y a pas de solution de contournement connue et les attaquants ont déjà ciblé des appareils Cisco par le passé.