ArticleInfrastructure & Cloud
Des buckets S3 inutilisés ouvrent la voie à des attaques
Des chercheurs en sécurité ont identifié près de 150 buckets S3 d'AWS laissés à l'abandon mais remplis de fichiers malveillants prêts à être exécutés à l'insu de nombreuses entreprises. Avec à la clé des risques allant de la simple injection de code dans un site web jusqu'à la prise de contrôle d'un compte AWS.

Les codes de référence [aides au diagnostic aidant à déterminer l'origine d'un incident matériel ou logiciel, ndlr] relatifs à des ressources cloud inexistantes continuent de poser des risques de sécurité importants et le problème ne fait que s'aggraver. Des recherches récentes ont permis d'identifier environ 150 anciens buckets S3 [unité de stockage contenant des données sous forme d'objets, ndlr] chez AWS utilisés par différents projets logiciels pour héberger des scripts sensibles, des fichiers de configuration, des mises à jour logicielles et d'autres artefacts binaires qui étaient automatiquement téléchargés et exécutés sur les systèmes des utilisateurs. Comme ces espaces de stockage n'existent plus, les attaquants peuvent les réenregistrer et envoyer des fichiers malveillants aux applications et aux outils qui les recherchent, ce qui peut entraîner l'exécution de codes à distance et d'autres risques de sécurité.
Pour déterminer l'ampleur de ce phénomène, des chercheurs en sécurité de Watchtowr ont créé un outil pour rechercher sur Internet des références à des buckets S3 dans le code source, la documentation logiciel et les instructions de déploiement, et vérifier s'ils existent toujours ou s'il est possible de les enregistrer. Les chercheurs ont trouvé environ 150 buckets S3 de ce type et ont surveillé les demandes qui leur ont été adressées sur une période de deux mois avant de les transmettre à l'équipe d'AWS pour empêcher de les ré-enregistrer. Au cours de cette période, environ 8 millions de requêtes HTTPS de toutes sortes ont été émises vers ces buckets, incluant des fichiers provenant d'adresses IP enregistrées auprès d'agences gouvernementales de plusieurs pays, dont les États-Unis et le Royaume-Uni, de réseaux militaires, d'entreprises du Fortune 500, de réseaux de cartes de paiement, de fabricants de produits industriels, de banques et d'autres organismes financiers, d'universités, d'éditeurs de logiciels et même d'entreprises spécialisées dans la cybersécurité.
Des attaques de grande ampleur évitées
Les fichiers demandés dans les buckets comprenaient des mises à jour logicielles, des binaires Windows, Linux et macOS précompilés et non signés, des images entières de machines virtuelles, des fichiers JavaScript, des modèles AWS CloudFormation, des configurations de serveurs SSLVPN, et bien plus encore. « Nous pensons qu'entre de mauvaises mains, les recherches que nous avons effectuées auraient pu conduire à des attaques sur la chaîne d'approvisionnement qui auraient dépassé en ampleur et en impact tout ce que nous avons vu jusqu'à présent en tant qu'industrie - ou plus clairement, nous aurions mis Cozy Bear dans l'embarras et fait passer leurs aventures avec SolarWinds pour de l'amateurisme et de l'insignifiance », ont écrit les chercheurs dans leur rapport.
En fonction du type de fichiers demandés à partir d'un bucket S3, les risques et les implications en matière de sécurité peuvent aller de la simple injection de code dans un site web à la prise de contrôle d'un compte AWS et de l'infrastructure qu'il gère, en passant par la compromission totale d'un environnement de développement de logiciels qui peut ensuite entraîner d'autres compromissions tout au long de la chaîne d'approvisionnement. Le problème des buckets S3 abandonnés n'est pas nouveau. En 2023, d'anciennes versions d'un paquetage NPM populaire appelé bignum ont été compromises parce qu'elles contenaient un code permettant de télécharger un fichier binaire préconstruit lors de l'installation à partir d'un bucket S3. Cette pratique a été arrêtée dans les versions plus récentes, de sorte que cette ancienne unité de stockage a fini par expirer, mais quelqu'un d'autre l'a alors enregistré et a commencé à pousser un fichier malveillant aux utilisateurs des anciennes versions de ce paquet. Ce que les chercheurs de Watchtowr viennent de découvrir est similaire, mais à une échelle beaucoup plus grande. L'impact est également plus étendu parce que les cas d'utilisation du stockage de buckets S3 identifiés varient énormément : des projets open source, aux logiciels commerciaux voire même des produits de sécurité.
D'autres risques de sécurité observés
Dans un cas, les chercheurs ont vu des demandes pour un fichier JavaScript associé à un projet open source appelé Echochamber.js qui ajoutait un simple formulaire de commentaire aux sites web. Dans un autre, ils ont trouvé des demandes pour un correctif de sécurité pour 7T Termis, un logiciel utilisé pour la gestion des réseaux d'énergie de quartier, qui était apparemment hébergé dans un bucketS3 et dont le lien figurait dans un avis CISA de la communauté des systèmes de contrôle industriel (ICS) datant de 2012. Ils ont aussi découvert qu'un fournisseur d'antivirus avait hébergé des mises à jour pour son agent Linux dans un bucket S3 qu'il avait ensuite laissé expirer. Heureusement, le téléchargement s'effectuait via apt, un gestionnaire de paquets pour Linux qui vérifie les signatures numériques des fichiers. Dans deux autres cas, les chercheurs ont trouvé que deux fournisseurs distincts d'appliances SSLVPN avaient utilisé des buckets S3 pour héberger des modèles de déploiement CloudFormation permetant aux utilisateurs de provisionner et de déployer automatiquement l'appliance de machine virtuelle sur leurs propres instances AWS dans le cloud.
« Comme vous pouvez l'imaginer, un attaquant qui peut servir ce fichier est dans une position extrêmement privilégiée puisqu'il peut ordonner à CloudFormation d'exécuter n'importe quelle tâche qu'il définit », écrivent les chercheurs. « L'exposition va au-delà de la machine virtuelle construite ; en tant que template CloudFormation, il est capable de faire bien plus que la simple création d'instances. Un attaquant pourrait, théoriquement : définir de nouveaux rôles IAM, déployer n'importe quel objet cloud et accorder l'accès à des comptes externes, supprimer des entrées des journaux système, accéder à d'autres stockages cloud non liés, s'abonner à des produits cloud coûteux, déployer des logiciels malveillants de type ransomware basés sur le cloud, et bien plus encore. »
Le pire à portée de main
Dans un autre cas, les chercheurs ont observé des requêtes provenant d'un outil appelé Vagrant essayant de construire une machine virtuelle à partir d'une simple image de VM censée être hébergée dans le bucket. « Bien que nous n'ayons aucune idée de l'utilisation prévue de la machine virtuelle résultante, nous ne pouvons pas vraiment tirer de conclusions sur les conséquences de cette requête - mais étant donné que Watchtowr possédait ce bucket, nous aurions techniquement pu le découvrir », écrivent les chercheurs.
Dans une autre unité de stockage, les chercheurs ont observé des requêtes pour appcast.xml provenant d'un outil appelé Sparkle, un framework de mise à jour logicielle pour MacOS que les développeurs d'applications peuvent inclure dans leur logiciel. De ce fait, Sparkle effectue des mises à jour logicielles pour une variété d'applications MacOS, mais comme il utilise une vérification de signature numérique, envoyer un fichier appcast.xml malveillant pointant vers une mise à jour non signée ne fonctionnera pas. Cependant, appcast.xml permet aux développeurs d'afficher les notes de version avant de télécharger la mise à jour, et cette fonction peut potentiellement être utilisée pour lancer une attaque par ingénierie sociale qui trompe l'utilisateur afin de télécharger manuellement une version malveillante du logiciel. Dans certains cas, les développeurs ont décidé de lier directement des versions non signées de leur logiciel hébergées dans le même bucket, contournant ainsi totalement le moyen le plus sûr pour télécharger Sparkle. « Malheureusement, l'étude de ces enregistrements a révélé que les choses étaient encore pires qu'il n'y paraissait - nous avons vu des occurrences de sources résidant dans des plages d'adresses IP appartenant au gouvernement, ainsi que dans des plages d'adresses militaires », ont écrit les chercheurs. « Être à deux doigts de compromettre un hôte détenant une IP .mil n'est pas quelque chose que l'on voit tous les jours. »
Une variété de scénarios d'exploitation
Enfin, l'un des exemples les plus remarquables, a été la découverte de plus d'un million de requêtes pour des fichiers .pom dans leurs buckets S3. Ces fichiers sont utilisés pour définir les dépendances logicielles conçues à partir du référentiel Java Maven et aussi par un outil de développement logiciel populaire appelé Gradle. L'un des buckets voyait passer des requêtes pour de nombreux fichiers pom fabric-artifacts-private, qui s'avère être associé à fabric.io, un outil de signalement de pannes autrefois populaire mais aujourd'hui obsolète, intégré dans de nombreux paquets. « L'aspect le plus dangereux de ce cas est en particulier le nombre de paquets qui l'utilisent », écrivent les chercheurs. « Ignorant les centaines de serveurs d'intégration continue affectés, l'élément significatif ici est que chacun d'entre eux construit un package logiciel, probablement pour être distribué à des utilisateurs finaux peu méfiants, ou (pire) être fourni à d'autres développeurs en vue d'une distribution encore plus large. » Les chercheurs ont aussi observé de nombreuses requêtes issues de plusieurs scripts et outils qui tentaient de télécharger simplement des fichiers .exe à partir de leurs buckets S3. Une situation qui peut déboucher là encore sur de l'exécution de code distant. Les chercheurs ont même essayé de déterminer le moment où certains des buckets S3 ont été abandonnés pour comprendre la fenêtre d'exploitation possible. Dans un cas, leur expiration remontait à 2015, mais continuait pourtant de recevoir jusqu'en début d'année des requêtes pour des fichiers dangereux.
Selon Watchtowr, cette étude met en évidence les dangers d'une mentalité « ça va ça vient » lorsqu'il s'agit de l'infrastructure Internet. « Dans un monde où l'enregistrement d'un nom de domaine ne coûte que quelques dollars, et où l'enregistrement d'une ressource internet comme un bucket S3 coûte encore moins, il suffit de très peu pour s'engager par inadvertance à maintenir une ressource limitée », écrivent les chercheurs. « Ce que nous commençons à peine à voir, cependant, c'est que toutes ces ressources qui ont été négligemment acquises ne sont pas comme prévu seulement des actifs, mais qu'elles amènent également leurs propres contraintes. »


