Plus de 130 000 comptes ont été créés auprès de fournisseurs de solutions de développement cloud incluant GitHub, Heroku et Togglebox par le cybergang Automated Libra de façon industrielle. Objectif : réaliser du cryptominage à grande échelle
Prévues pour les tests les offres gratuites des fournisseurs de développement cloud peuvent avoir une face plus sombre. C’est ce que vient de trouver une équipe de l’unité 42 de Palo Alto Networks à travers un gang nommé Automated Libra, potentiellement localisé en Afrique du Sud. Au travers de ces offres, ils ont créé des centaines de milliers de comptes sur GitHub (partage de code), Heroku (PaaS) et Togglebox (VPS) pour faire du cryptominage.
Au plus fort de la campagne, baptisée PurpleUrchin, en novembre, ce groupe enregistrait entre trois et cinq comptes GitHub chaque minute à l’aide de processus automatisés de neutralisation des Captcha et abuser les workloads de la plateforme CI/CD Actions de GitHub pour du cryptominage. « Chacun des comptes GitHub a ensuite été impliqué dans une stratégie de « jouer et partir », où chaque compte utiliserait des ressources de calcul, mais les acteurs de la menace n’ont pas récolté leurs fonds », ont déclaré les chercheurs dans leur rapport. « Cela semble être une procédure opérationnelle standard pour PurpleUrchin, car il est prouvé qu’ils ont créé plus de 130 000 comptes sur divers fournisseurs de serveurs privés virtuels et de services cloud ».
Du freejacking et un scénario de play and run
Sur la méthode, les experts ont observé une combinaison d’abus d’offres d’essai (freejacking) et le scénario de play and run où les frais des comptes ne sont pas payés. Ce dernier est plus difficile à réaliser car la plupart des fournisseurs de services exigent que l’utilisateur enregistre une carte de crédit ou un mode de paiement valide avant de lui donner accès aux ressources informatiques payantes. Cependant, même si l’utilisation est suivie et comptabilisée à la minute, la facture est généralement émise après une période plus longue.
Cela donne aux attaquants une fenêtre de temps pour abuser de ces services. Automated Libra semble avoir utilisé les deux méthodes, suggérant qu’ils avaient accès à des cartes de crédit volées ou au moins à des cartes qui seraient acceptées par le système même si elles étaient ensuite signalées comme volées et verrouillées par les émetteurs. Cela montre l’importance de disposer de solides systèmes de paiement anti-fraude.
Des techniques CI/CD utilisées par les pirates
PurpleUrchin fonctionne depuis 2019, et même s’ils ont souvent abusé des fournisseurs de VPS, ils ont également étendu leur fonctionnement pour cibler les plateformes d’hébergement d’applications cloud. Heroku, par exemple, en fournit une qui prend en charge plusieurs langages de programmation, tandis que Togglebox propose à la fois des services serveurs privés virtuels et d’hébergement d’applications. Les deux prennent en charge le déploiement d’apps en tant que conteneurs à l’aide de Docker et de Kubernetes, et Automated Libra en a pleinement profité. « L’architecture d’infrastructure employée par les acteurs utilise des techniques CI/CD, dans lesquelles chaque composant logiciel individuel d’une opération est placé dans un conteneur », ont déclaré les chercheurs.
Ils ajoutent « ce conteneur fonctionne dans une architecture modulaire au sein de l’exploitation de minage plus large. Les architectures CI/CD fournissent des environnements opérationnels hautement modulaires, permettant à certains composants d’une opération d’échouer, d’être mis à jour ou même d’être résiliés et remplacés, sans affecter l’environnement plus large ». Tous les conteneurs ne sont pas utilisés pour du cryptominage. Certains le sont pour automatiser la création de comptes et les tâches de déploiement, d’autres pour automatiser la vente de la cryptomonnaie extraite sur différentes plateformes de marchés et d’échanges.
Des comptes Github créés à la chaîne
GitHub Actions automatise la création et le test de code logiciel avec un service gratuit pour les référentiels publics, des minutes offertes de temps d’exécution ainsi que de l’espace de stockage pour les référentiels privés. Les workflows GitHub Actions sont des processus automatisés définis dans des fichiers .yml à l’aide de la syntaxe YAML exécutés lorsque certains déclencheurs ou événements se produisent. Ils peuvent impliquer la réalisation de scripts Bash, la génération et la copie de fichiers, etc. Il s’agit essentiellement d’une série de tâches définies par l’utilisateur exécutées sur une machine virtuelle, généralement dans le but de compiler des applications à partir de code et de les tester.
Pour automatiser la création de comptes GitHub, les attaquants ont utilisé des conteneurs déployés sur Togglebox qui contenaient un navigateur basé sur Chromium appelé Iron;xdotool, un outil servant à générer des entrées clavier et souris. Et aussi la boîte à outils ImageMagick pour convertir, éditer et composer des images numériques. Tout d’abord, le processus automatisé a ouvert la page de création de compte GitHub Iron et a ouvert une session de bureau à distance VNC sur le navigateur. Xdotool s’est connecté sur ce dernier via VNC et a automatiquement rempli et soumis le formulaire. À ce stade, le processus de création de compte présente un Captcha que l’utilisateur doit résoudre. Le défi GitHub Captcha demande à l’utilisateur de sélectionner la galaxie spirale parmi plusieurs images avec des galaxies de formes différentes. Pour le transmettre, xdotool télécharge les images et les transmet à ImageMagick, qui est ensuite utilisé pour les convertir en images complémentaires rouges, vertes et bleues (RVB).
Cela les transforme essentiellement en taches de couleurs rouge, verte et bleue sur fond blanc. Ensuite, la commande d’identification ImageMagick est utilisée pour déterminer l’asymétrie du canal rouge, et l’image avec les valeurs les plus basses a été choisie comme galaxie spirale. Tout ce processus automatisé, que les chercheurs ont réussi à récupérer à partir d’un conteneur, a été conçu spécifiquement pour un défi Captcha et il est peu probable qu’il fonctionne avec d’autres. Les chercheurs n’ont pas testé l’efficacité de cette technique, mais ont déterminé que les attaquants avaient réussi à enregistrer plus de 20 000 comptes GitHub rien qu’en novembre.
Des conteneurs pour activer la fonction de cryptominage
Une fois le compte enregistré, l’étape suivante consistait à enregistrer un jeton d’accès personnel avec des autorisations de workflows, à paramétrer des clés SSH et à utiliser l’API GitHub pour configurer un référentiel et les autorisations correspondantes. Celui-ci a ensuite été mis à jour avec un workflow généré par un script PHP pour avoir des attributs aléatoires et être unique par rapport aux workflows déployés sur d’autres comptes. Une fois exécuté, le workflow a créé 64 tâches et a utilisé repository_dispatch sous l’événement github.event.client_payload.app pour exécuter des applications hébergées en externe. Initialement, celles-ci étaient employées pour valider des scripts Bash externes, mais les attaquants sont ensuite passés à l’exécution de conteneurs qui ont installé et lancé la fonctionnalité de cryptominage.
« Il est important de noter qu’Automated Libra conçoit son infrastructure pour tirer le meilleur parti des outils CD/CI », ont déclaré les chercheurs. « Cela devient plus facile à réaliser au fil du temps, car les fournisseurs de serveurs privés virtuels traditionnels diversifient leurs portefeuilles de services pour inclure des services liés au cloud. La disponibilité de ces services liés au cloud facilite la tâche des acteurs de la menace car ils n’ont pas à maintenir l’infrastructure pour déployer leurs applications. Dans la majorité des cas, il leur suffira de déployer un conteneur ».
Alors que ce groupe abuse des ressources informatiques des fournisseurs de services cloud eux-mêmes, les mêmes pratiques de développement modernes et services d’hébergement d’applications cloud sont de plus en plus utilisés pour mettre en place une infrastructure de commande et de contrôle par différents groupes pour une variété d’attaques. Avec pour conséquence de rendre les efforts d’attribution et de démantèlement très lourds et beaucoup plus difficiles.
Une méthode récemment découverte par des chercheurs en sécurité de Claroty utilise la syntaxe JSON pour fournir des charges utiles malveillantes. Son originalité ? Rien de moins que contourner les protections SQLi des pare-feux applicatifs les plus populaires.
Les chercheurs en sécurité ont développé une technique générique d’injection SQL qui contourne plusieurs pare-feux applicatifs web (WAF). Au cœur du problème, les fournisseurs de WAF n’ajoutaient pas la prise en charge de JSON dans les instructions SQL. Les attaquants potentiels peuvent ainsi masquer facilement leurs charges utiles malveillantes. Il a été confirmé que la technique de contournement, découverte par des chercheurs de Claroty de son équipe Team82, fonctionne contre les WAF de Palo Alto Networks, Amazon Web Services (AWS), Cloudflare, F5 et Imperva. Ces fournisseurs ont publié des correctifs, les clients doivent donc mettre à jour leurs déploiements WAF. Cependant, la technique peut également fonctionner contre les solutions WAF d’autres fournisseurs. Les utilisateurs doivent donc demander à ceux-ci s’ils peuvent détecter et bloquer de telles attaques. « Les pirates utilisant cette nouvelle technique pourraient accéder à une base de données principale et utiliser des vulnérabilités et des exploits supplémentaires pour exfiltrer des informations via un accès direct au serveur ou via le cloud », ont déclaré les chercheurs de Claroty dans leur rapport. « Ceci est particulièrement important pour les plates-formes OT et IoT qui sont passées à des systèmes de gestion et de surveillance basés sur le cloud. Les WAF offrent une promesse de sécurité supplémentaire à partir du cloud ; un attaquant capable de contourner ces protections dispose d’un accès étendu aux systèmes ».
Contournement trouvé lors de l’enquête sur d’autres vulnérabilités
Les chercheurs de Claroty ont développé cette technique d’attaque tout en enquêtant sur les vulnérabilités qu’ils ont trouvées dans une plate-forme de gestion d’appareils sans fil de Cambium Networks appelée cnMaestro qui peut être déployée sur site et dans le cloud. Le service cloud exploité par Cambium fournit une instance isolée distincte du serveur cnMaestro pour chaque client et utilise AWS en backend. L’équipe a trouvé sept failles dans cnMaestro, dont une faille d’injection SQL (SQLi) qui leur permettait d’exfiltrer les sessions des utilisateurs, les clés SSH, les hachages de mots de passe, les jetons et les codes de vérification de la base de données du serveur. L’injection SQL est l’une des vulnérabilités d’application Web les plus courantes et les plus dangereuses et permet aux attaquants d’injecter des requêtes SQL arbitraires dans des requêtes que l’application exécuterait ensuite sur la base de données avec ses propres privilèges.
Après avoir confirmé que leur exploit fonctionnait contre un déploiement sur site de cnMaestro, les chercheurs l’ont tenté contre une instance hébergée dans le cloud. À partir de la réponse du serveur, ils ont réalisé que la demande était probablement bloquée par le pare-feu applicatif web d’AWS, qui l’a détectée comme malveillante. Au lieu d’abandonner, les chercheurs ont décidé d’enquêter sur la manière dont celui-ci reconnaît les tentatives d’injection SQL. Ils ont donc créé leur propre application vulnérable hébergée sur AWS et lui ont envoyé des requêtes malveillantes. Leur conclusion était que le WAF utilise deux méthodologies principales pour identifier la syntaxe SQL : rechercher des mots spécifiques dans la requête qu’il reconnaît comme faisant partie de la syntaxe SQL et tenter d’analyser différentes parties de la requête en tant que syntaxe SQL valide. « Alors que la plupart des WAF utiliseront une combinaison des deux méthodologies en plus de tout ce que le WAF fait d’unique, ils ont tous deux une faiblesse commune : ils exigent que le WAF reconnaisse la syntaxe SQL », ont déclaré les chercheurs. « Cela a suscité notre intérêt et soulevé une question de recherche majeure : et si nous pouvions trouver une syntaxe SQL qu’aucun WAF ne reconnaîtrait ? ».
Les fournisseurs WAF ont négligé JSON dans SQL
Il y a environ 10 ans, les moteurs de base de données ont commencé à ajouter la prise en charge du travail avec les données JSON (JavaScript Object Notation). JSON est une norme de formatage et d’échange de données largement utilisée par les applications Web et les API Web lorsqu’elles communiquent entre elles. Étant donné que les applications échangent déjà des données au format JSON, les créateurs de moteurs de bases de données relationnelles ont trouvé utile de permettre aux développeurs d’utiliser directement ces données dans les opérations SQL sans traitement ni modification supplémentaires. PostgreSQL a ajouté cette fonctionnalité en 2012, et d’autres moteurs de base de données majeurs ont suivi au fil des ans : MySQL en 2015, MSSQL en 2016 et SQLite en 2022. Aujourd’hui, tous ces moteurs ont le support JSON activé par défaut. Cependant, les fournisseurs de WAF n’ont pas emboîté le pas, probablement parce qu’ils considéraient encore cette fonctionnalité comme étant nouvelle et peu connue. « D’après notre compréhension de la façon dont un WAF pourrait signaler les requêtes comme malveillantes, nous sommes arrivés à la conclusion que nous devons trouver une syntaxe SQL que le WAF ne comprendra pas », ont déclaré les chercheurs de Claroty. « Si nous pouvions fournir une charge utile SQLi que le WAF ne reconnaîtrait pas comme SQL valide, mais que le moteur de base de données l’analyserait, nous pourrions en fait réaliser le contournement. Il s’avère que JSON était exactement ce décalage entre l’analyseur du WAF et le moteur de base de données. Lorsque nous avons transmis des instructions SQL valides qui utilisaient une syntaxe JSON moins répandue, le WAF n’a en fait pas signalé la demande comme malveillante ».
Après avoir confirmé que le pare-feu AWS WAF était vulnérable et qu’ils pouvaient utiliser JSON pour cacher leur exploit SQLi, les chercheurs se sont demandé si d’autres WAF pourraient avoir la même faille. Les tests des WAF de plusieurs fournisseurs majeurs ont prouvé que leurs soupçons étaient fondés et qu’ils pouvaient utiliser la syntaxe JSON pour contourner les défenses SQLi avec seulement des modifications minimes entre les fournisseurs. Les chercheurs ont signalé le problème aux fournisseurs qu’ils ont trouvés vulnérables, mais ont également contribué leur technique à SQLMap, un outil de test de pénétration open source qui automatise les attaques par injection SQL. Cela signifie que la technique de contournement est désormais accessible au public et peut être utilisée par n’importe qui. « Team82 a divulgué ses conclusions à cinq des principaux fournisseurs de WAF, qui ont tous ajouté la prise en charge de la syntaxe JSON à leurs produits », ont déclaré les chercheurs. « Nous pensons que les produits d’autres fournisseurs peuvent être affectés et que des examens de la prise en charge de JSON doivent être effectués ».