De nombreux chercheurs en cybersécurité ainsi que votre serviteur ont récemment détecté une campagne « massive » exploitant les configurations Git exposées pour récupérer des identifiants sensibles, cloner des référentiels privés et extraire des informations d’identification cloud directement du code source.
Une collecte de données d’envergure
Surnommée EMERALDWHALE, cette opération aurait permis de collecter les données de plus de 10 000 référentiels privés, stockées dans un compartiment de stockage Amazon S3 appartenant à une victime antérieure. Ce compartiment contenait environ 15 000 identifiants volés, démantelés depuis par Amazon.
« Les identifiants volés sont issus de plusieurs fournisseurs de services cloud (CSP), de services de messagerie électronique, et d’autres services divers, » a indiqué l’entreprise de cybersécurité Sysdig sécurité dans son rapport. Selon les chercheurs, les identifiants semblent destinés principalement à des attaques de phishing et de spam.
Une opération aux multiples techniques
Malgré une sophistication limitée, l’opération EMERALDWHALE s’appuie sur un arsenal d’outils spécifiques permettant de voler les informations d’identification, de récupérer les fichiers de configuration Git, les fichiers d’environnement Laravel (.env), ainsi que des données web non protégées. Aucun acteur ou groupe de menace précis n’a encore été identifié derrière cette campagne.
Un ciblage massif des configurations Git exposées
Les serveurs possédant des configurations Git mal sécurisées sont visés par EMERALDWHALE, qui utilise de larges plages d’adresses IP pour identifier des hôtes vulnérables et extraire leurs informations d’identification. Ces identifiants sont ensuite utilisés pour cloner des référentiels, privés comme publics, afin d’accéder à davantage de secrets intégrés dans le code source. L’ensemble des données collectées est ensuite transféré dans un compartiment S3.
Des outils et des méthodes utilisés
Pour atteindre ses objectifs, EMERALDWHALE utilise principalement deux programmes : MZR V2 et Seyzo-v2. Disponibles sur des marchés clandestins, ces programmes permettent de traiter des listes d’adresses IP afin de scanner et exploiter des référentiels Git exposés. Les adresses IP sont souvent compilées grâce à des outils tels que Google Dorks, Shodan, ou MASSCAN, facilitant la détection des cibles vulnérables.
Une analyse menée avec soin révèle également
qu’une liste de 67 000 URL incluant le chemin « /.git/config » exposé est actuellement vendue sur Telegram ( réseau groupé privé) pour un prix avoisinant les 100 dollars, ce qui prouve que le marché existe et explose pour les fichiers de configuration Git.
Rappel, un fichier de configuration complet permet un accès quasi immédiat à un dépôt GitHub.
Un marché clandestin en pleine expansion
En plus des fichiers Git, EMERALDWHALE cible également les fichiers d’environnement Laravel (.env), qui renferment des informations critiques telles que les identifiants de services cloud et de bases de données. « Le marché noir des identifiants pour les services cloud est en pleine croissance, et cette attaque démontre que la gestion des secrets seule ne suffit pas pour sécuriser un environnement, ».
Si un de vos dépôts a été compromis et copié, il est essentiel d’agir rapidement pour minimiser les risques de sécurité et rétablir l’intégrité de votre infrastructure.
Voici les étapes recommandées par webmaster67 pour réagir face à ce type de violation :
1. Révocation et rotation immédiate des identifiants exposés
- Révocation des clés d’API et des mots de passe : Identifiez et révoquez toutes les clés API, mots de passe et identifiants inclus dans le dépôt copié.
- Rotation des identifiants sensibles : Modifiez toutes les informations sensibles (par ex., jetons d’authentification, identifiants de services cloud, bases de données, etc.) qui pourraient avoir été exposées.
2. Analyse des journaux d’accès et audit de sécurité
- Vérification des journaux d’accès : Consultez les journaux des accès au dépôt et aux services associés pour identifier toute activité suspecte ou non autorisée.
- Audit des permissions : Revoyez les permissions des utilisateurs pour ce dépôt et limitez les accès aux personnes strictement nécessaires.
- Audit de sécurité : Effectuez un audit complet pour vérifier la présence d’autres vulnérabilités potentielles et appliquer des correctifs si nécessaire.
3. Mise à jour des bonnes pratiques de gestion des secrets
- Suppression des secrets dans le code source : Si des informations sensibles sont stockées directement dans le code source, déplacez-les vers un gestionnaire de secrets sécurisé comme AWS Secrets Manager, HashiCorp Vault, ou un autre outil de gestion des secrets.
- Utilisation de variables d’environnement : Pour les applications déployées, configurez les secrets via des variables d’environnement plutôt que dans le code source.
4. Revalidation de la configuration Git
- Sécurisation des configurations de dépôt : Assurez-vous que les dépôts sont configurés correctement, en vérifiant que les fichiers sensibles (tels que
.git/configet.env) ne sont pas accessibles publiquement. - Configuration des protections d’accès : Activez l’authentification à plusieurs facteurs (MFA) pour tous les utilisateurs et imposez des politiques de mots de passe robustes.
5. Surveillance et alerte des activités suspectes
- Mise en place de monitoring : Activez la surveillance en temps réel des activités dans vos dépôts pour détecter tout comportement anormal.
- Détection de fuites potentielles : Utilisez des outils d’analyse de sécurité, comme Trufflehog ou Gitleaks, pour détecter automatiquement les secrets dans vos dépôts.
6. Sensibilisation de l’équipe de développement
- Formation sur la gestion des identifiants : Organisez une formation pour sensibiliser les développeurs à ne jamais inclure de secrets dans le code source et les encourager à utiliser des pratiques sécurisées.
- Documentation des bonnes pratiques : Mettez en place une documentation interne sur les pratiques sécurisées de gestion des dépôts, y compris les règles de commit et l’utilisation des gestionnaires de secrets.
7. Notification des parties prenantes
- Informer les utilisateurs et partenaires : Si des informations d’identification de clients, partenaires, ou d’autres parties sont concernées, il peut être nécessaire de les informer et de leur conseiller de prendre des mesures.
- Communication de crise : Préparez un plan de communication pour informer les parties prenantes de la situation et des mesures mises en place pour protéger les données.
En suivant ces étapes, vous limiterez l’impact de la compromission et renforcerez la sécurité de vos dépôts pour éviter de futures violations. Une approche proactive avec une gestion rigoureuse des identifiants et des configurations est essentielle pour sécuriser durablement vos projets.