Les cybercriminels s’intéressent de plus en plus au cloud au fur et à mesure de l’adoption de ce dernier. Une campagne d’extorsion compromettant les ressources AWS par le biais d’informations d’identification collectées à partir de fichiers d’environnement (.env) a été découverte par les chercheurs de l’Unité 42 de Palo Alto. Ces fichiers étaient stockés de manière non sécurisée sur des serveurs web. Ils comprenaient des clés d'accès à AWS, des identifiants pour des bases de données et des comptes de réseaux sociaux, des clés API pour des applications SaaS et des services de messagerie, ainsi que des tokens d'accès à divers services cloud de l'hyperscaler.

L'opération a été découverte alors que les chercheurs enquêtaient sur un environnement AWS compromis qui était utilisé de manière abusive pour lancer des analyses automatisées contre d'autres domaines. Les spécialistes ont déterminé que les attaquants avaient collecté des fichiers .env provenant d'environ 110 000 domaines, ce qui a conduit à l'exposition de plus de 90 000 variables d'environnement uniques, dont 7 000 correspondant à des services cloud utilisés par des entreprises. « Toutes les fuites ne contenaient pas nécessairement des comptes utilisateurs ou des secrets, mais elles ont toutes révélé des détails sur l'infrastructure interne de la victime ou sur sa configuration », indiquent les experts dans le rapport. Parmi les exemples d'informations d'identification divulguées figurent 1 185 clés d'accès uniques à AWS, 333 tokens PayPal OAuth, 235 tokens GitHub, 111 clés API HubSpot, 39 webhooks Slack et 27 tokens DigitalOcean.

Une mauvaise configuration expose les variables d’environnement

De nombreux framework de développement et applications web stockent des données de configuration importantes dans des fichiers .env. Les serveurs web devraient être configurés pour empêcher l'accès aux fichiers . (dot) par défaut, car ils sont censés être des fichiers cachés qui ne sont jamais destinés à être accessibles au public. Cependant, des erreurs de configuration se produisent régulièrement. Un autre exemple est le dossier .git qui stocke des informations de configuration importantes pour le système de contrôle de version du code source git.

L'exposition accidentelle de fichiers .env ou .git est un problème connu, souvent mis en exergue par d’autres chercheurs. Il n'est donc pas inhabituel pour les attaquants de lancer des robots scannant le web à la recherche de tels fichiers exposés dans le dossier racine des domaines. Toutefois, l'ampleur de l'opération découverte par l'unité 42 de Palo Alto Networks suggère que de telles erreurs de configuration restent très répandues.

Des mouvements latéraux dans les environnements AWS

Entre les mains de pirates compétents, les secrets divulgués peuvent être très dangereux. Après avoir obtenu une clé d'accès AWS, les attaquants l'ont utilisée pour exécuter un appel API GetCallerIdentity afin de vérifier l'identité ou le rôle attribué à l'identifiant exposé. Ils ont également effectué d'autres actions de reconnaissance en appelant ListUsers pour rassembler une liste d'utilisateurs IAM (gestion des accès et des identités) dans le compte AWS et ListBuckets pour identifier tous les buckets S3 existants.

Dans l'environnement AWS compromis étudié, les attaquants ont réalisé que le rôle dans l’IAM AWS exposé qu'ils avaient obtenu ne disposait pas de privilèges administrateurs sur toutes les ressources. Cependant, il avait la permission de créer de nouveaux rôles IAM et d'attacher des politiques spécifiques aux rôles existants. Ils ont alors procédé à la création d'un autre rôle appelé lambda-ex et y ont attaché la politique AdministratorAccess, réalisant ainsi une élévation des privilèges. « Suite à la création réussie du rôle IAM privilégié, l'attaquant a tenté de créer deux piles d'infrastructure différentes, l'une utilisant les ressources Amazon Elastic Cloud Compute (EC2) et l'autre avec AWS Lambda », ont déclaré les chercheurs. « En effectuant ces tactiques d'exécution, les acteurs n'ont pas réussi à créer un groupe de sécurité, une paire de clés et une instance EC2, mais ils ont créé avec succès plusieurs fonctions lambda avec le rôle IAM nouvellement créé attaché. »

230 millions de cibles uniques

AWS Lambda est une plateforme serverless conçue pour provisionner automatiquement les ressources cloud en fonction de l’application fournie par l'utilisateur. Elle a déjà été utilisée de manière abusive par des attaquants pour le minage de crypto-actifs avec des mineurs écrits en Go, mais dans ce cas, les pirates l'ont utilisée pour déployer un script bash qui analyse d'autres domaines à la recherche de fichiers .env exposés, en extrait les informations d'identification et les télécharge vers un bucket S3 public qu'ils ont précédemment compromis.

Ce script particulier recherche des informations d'identification pour la plateforme d'envoi de courriels Mailgun, mais en accédant à l'espace de stockage S3 publiquement exposé des attaquants, les chercheurs ont été en mesure de comprendre toute l'étendue de la campagne. « Nous avons identifié plus de 230 millions de cibles uniques que l'acteur de la menace analysait à la recherche de fichiers d'environnement mal configurés et exposés. Au moment de l'accès à ce bucket S3 public, nous estimons que plusieurs comptes AWS compromis étaient la cible de cette analyse malveillante dans le cadre d'une opération automatisée de compromission. »

Exfiltration de données, extorsion et des conseils

Chaque fois qu'ils parvenaient à obtenir des informations d'identification sur les buckets S3, les attaquants se servaient d’un outil Windows appelé S3 Browser pour interagir avec l'API S3 et exfiltrer toutes les données qu'ils contenaient. Une fois tous les fichiers téléchargés, ils les ont supprimés et ont laissé un fichier de rançon informant le propriétaire qu'ils ont désormais accès à ses informations sensibles et qu'ils prévoient de les vendre s'ils ne sont pas payés. Les cybercriminels ont accédé aux comptes AWS et aux buckets S3 depuis le réseau Tor, les VPN publics ou depuis l'intérieur de l'infrastructure AWS elle-même en utilisant d'autres comptes compromis. Cependant, les chercheurs ont détecté deux cas où les attaquants se sont connectés directement à partir d'adresses IP attribuées à des FAI en Ukraine et au Maroc.

Ils conseillent aux organisations d'activer la journalisation S3 ou CloudTrail pour les événements des buckets S3 afin de pouvoir mener des investigations en cas d'incident. Ces paramètres ne sont pas activés par défaut et peuvent augmenter le coût de l'environnement cloud car ils mobilisent des ressources, mais ils en valent la peine pour pouvoir évaluer avec précision ce qui s'est passé en cas de compromission. « En fonction des services AWS utilisés, les entreprises devront s'assurer qu'elles activent la journalisation spécifique à ce service », ont déclaré les chercheurs. Une fois qu’elles ont mis en place la journalisation et la conservation appropriées de ces données (une conservation minimale de 90 jours est recommandée), l'accent doit être mis sur la surveillance ». Le service GuardDuty d'AWS propose ainsi des fonctions d'alerte en cas d'abus d'identifiants et de ressources EC2. Les entreprises peuvent créer leurs propres alertes en cas d'activité anormale dans les données de journal.

Pour terminer, les experts déconseillent fortement d'utiliser des clés d'accès IAM à long terme dans les applications et de s'appuyer plutôt sur les rôles IAM qui ne fournissent qu'un accès temporaire. Le principe du moindre privilège doit être respecté lors de la configuration de l'accès aux ressources IAM. L'accès aux régions AWS non utilisées devrait également être désactivé afin que les attaquants ne puissent pas déployer des ressources dans des régions supplémentaires.