Les environnements de démonstration mal configurés se transforment en portes dérobées dans le cloud pour l’entreprise

Les tests internes, les démonstrations de produits et la formation à la sécurité sont des pratiques essentielles en matière de cybersécurité, offrant aux défenseurs et aux utilisateurs quotidiens les outils et les moyens nécessaires pour prévenir et répondre aux menaces d’entreprise.

Cependant, selon une nouvelle étude de Pentera Labs, lorsqu’ils sont laissés dans des états par défaut ou mal configurés, ces environnements de « test » et de « démonstration » constituent un autre point d’entrée pour les attaquants – et le problème affecte même les principales sociétés de sécurité et les sociétés Fortune 500 qui devraient être mieux informées.

Les chercheurs ont découvert que des applications de formation publiques populaires telles que Hackazon, Damn Vulnerable Web Application (DVWA) et OWASP Juice Shop étaient fréquemment laissées accessibles sur l’Internet public, exposant par inadvertance les principaux fournisseurs, notamment Palo Alto Networks, Cloudflare et F5.

« Il ne s’agit pas d’une recherche théorique », a écrit Noam Yaffe, chercheur principal de Pentera et chef de l’équipe de sécurité offensive, dans un article de blog technique. Son équipe a découvert des « preuves claires » que ces vecteurs d’attaque sont exploités dans la nature pour activer les mineurs de crypto, les webshells et les mécanismes de persistance. Les assaillants seraient originaires d’Europe de l’Est.

« Cette recherche prouve que le fait de qualifier quelque chose de « formation » ou de « développement » ne le rend pas invisible aux yeux des attaquants », a noté Yaffe. « Si c’est sur Internet et qu’il dispose d’informations d’identification cloud, c’est une cible. »

Exposer les joyaux de la couronne dans des laboratoires apparemment inoffensifs

Après avoir identifié une instance exposée de Hackazon, un site de test gratuit et intentionnellement vulnérable développé par Deloitte, lors d’une évaluation de routine de la sécurité du cloud pour un client, Yaffe a effectué une recherche en cinq étapes des applications exposées. Son équipe a découvert 1 926 « applications vérifiées, actives et vulnérables », dont plus de la moitié s’exécutaient sur une infrastructure appartenant à l’entreprise sur les plateformes AWS, Azure et Google Cloud.

Ils ont ensuite découvert 109 ensembles d’informations d’identification exposés, dont beaucoup sont accessibles via un environnement de laboratoire à faible priorité, liés à des rôles de gestion des accès aux identités (IAM) trop privilégiés. Celles-ci accordaient souvent « bien plus d’accès » qu’une application de « formation » ne le devrait, a expliqué Yaffe, et fournissaient aux attaquants :

• Accès de niveau administrateur aux comptes cloud, ainsi qu’un accès complet aux compartiments S3, GCS et Azure Blob Storage ;
• La capacité de lancer et de détruire des ressources de calcul et de lire et écrire dans les gestionnaires de secrets ;
• Autorisations d’interagir avec les registres de conteneurs où les images sont stockées, partagées et déployées.

Les attaquants ont maintenu un accès persistant, se sont déplacés latéralement à travers les réseaux, ont exploité les informations d’identification du cloud et d’autres informations sensibles, ainsi que l’infrastructure des victimes cryptées. De plus, les chercheurs de Pentera ont facilement découvert des secrets actifs tels que des clés Slack, des jetons GitHub et des informations d’identification Docker Hub, ainsi que des données utilisateur réelles et du code source propriétaire.

De manière alarmante, dans DVWA, 54 % des instances découvertes utilisaient toujours les informations d’identification par défaut « admin:mot de passe », et les attaquants pouvaient rétrograder les paramètres de sécurité en un seul clic (de « impossible » à « faible »), rendant chaque vulnérabilité intégrée « trivialement exploitable », a noté Yaffe.

« Ce qui a commencé comme un laboratoire inoffensif pourrait mener directement aux joyaux de la couronne d’une organisation », a-t-il déclaré.

Exploitations du monde réel

Dans un cas concret, l’équipe de Pentera a découvert une application Web boguée (bWAPP) mal configurée, liée aux comptes cloud Cloudflare exécutés sur Google Cloud Platform (GCP). bWAPP est une application Web gratuite, open source et délibérément non sécurisée, utilisée à des fins de formation. En interrogeant les services de métadonnées de GCP, les chercheurs ont pu usurper l’identité des comptes de service par défaut et obtenir un accès en lecture à des « centaines » de compartiments de stockage.

De même, un DVWA lié aux comptes cloud de F5 a été découvert en cours d’exécution sur une instance GCP, permettant là encore aux chercheurs d’accéder à de nombreux compartiments de stockage contenant des journaux et des données métriques. De plus, une application DVWA mal configurée liée à Palo Alto a été identifiée et fonctionnant sur AWS ; Yaffe et son équipe ont utilisé le rôle IAM ci-joint et les informations d’identification temporaires pour obtenir un accès administratif complet au compte AWS.

Les chercheurs ont également exfiltré les jetons OAuth pour un compte de service GCP afin d’assumer son identité, de répertorier et d’accéder au contenu spécifique du compartiment. Par exemple, un compartiment « cloud_build » stockait des fichiers .tgz que les attaquants pouvaient facilement télécharger. Le compte était géré par une adresse e-mail d’administrateur et violait le moindre privilège car il contenait une autorisation de politique, a expliqué Yaffe.

« Même s’il s’agissait d’un compte « développement »/« formation », il contenait des secrets, des informations d’identification et des jetons API très sensibles », a-t-il déclaré.

En évaluant ces applications vulnérables et mal configurées, son équipe a trouvé des « preuves claires » qu’elles étaient déjà pleinement exploitées dans la nature. Environ 20 % des instances DVWA découvertes contenaient des artefacts déployés par des acteurs malveillants, notamment :

• XMRig Crypto Miner fonctionne activement, envoie les bénéfices vers des portefeuilles contrôlés par les attaquants et est configuré pour fonctionner silencieusement à l’insu de l’utilisateur ;
• Un script de surveillance « sophistiqué » qui a maintenu sa persistance même après la découverte d’un compromis. Cela comprenait l’auto-récupération, les téléchargements automatisés, la livraison de charges utiles cryptées, la suppression des preuves et les kill switch que les acteurs malveillants pouvaient utiliser pour arrêter facilement les opérations ;
• Un webshell PHP qui donnait aux attaquants la possibilité de lire, écrire, supprimer, télécharger et télécharger des fichiers ; exécuter des commandes et des scripts du système d’exploitation (OS) sur des machines distantes ; et accédez aux informations d’identification, aux clés API et à d’autres secrets intégrés dans le code source.

Toutes les découvertes ont été divulguées de manière responsable aux organisations concernées et ont ensuite été atténuées avant leur publication, a souligné Yaffe.

« Il ne s’agissait pas d’incidents isolés ; ils représentaient une campagne d’exploitation organisée et continue », a-t-il prévenu.

Ce que les entreprises peuvent faire maintenant

Pour se défendre contre cette menace généralisée, Yaffe et son équipe ont développé SigInt, un cadre de reconnaissance autonome basé sur Python et alimenté par un grand modèle de langage (LLM). L’outil, disponible sur GitHub, génère des signatures d’empreintes digitales directement à partir d’une cible réelle ou d’un référentiel GitHub, recherche des correspondances et applique un score de confiance. Il intègre également des renseignements sur la propriété intellectuelle, la détection des fournisseurs de cloud, des données d’attribution et fournit des analyses pour étayer une enquête plus approfondie.

Au-delà de cela, Yaffe a conseillé aux entreprises de « tout inventorier » pour établir une image complète et à jour de toutes les ressources cloud, y compris les « déploiements temporaires » et « tests », d’effectuer des audits réguliers pour rechercher les services exposés et d’appliquer le moindre privilège.

« N’attachez jamais de rôles IAM étendus à des environnements de formation ou de démonstration », a-t-il déclaré.

En outre, les défenseurs doivent isoler les environnements de formation des réseaux de production et leur appliquer la même surveillance et les mêmes alertes que les environnements de production, restreindre leur accès Internet sortant, documenter et appliquer les modifications des informations d’identification par défaut avant le déploiement, et définir des contrôles qui font expirer les environnements de test temporaires après un délai spécifié. « S’il n’y a pas de date de fin, il durera pour toujours », a noté Yaffe.

En fin de compte, il a souligné : « Ce sont des problèmes réparables. Une hygiène de base… aurait évité tous les cas que nous avons trouvés. »