L'attaque Megalodon frappe 5 561 dépôts GitHub en six heures
Une attaque sur la chaîne d'approvisionnement CI/CD de GitHub, baptisée Megalodon, a établi un nouveau record en matière de compromission automatisée et à grande échelle de dépôts. En une seule fenêtre de six heures, les attaquants ont poussé 5 718 mises à jour de code malveillantes sur 5 561 dépôts GitHub, en utilisant de fausses identités pour injecter des fichiers de workflow conçus pour siphonner silencieusement des identifiants cloud, des clés SSH et des secrets présents dans le code source. La vitesse et le volume de la campagne signalent un glissement vers des attaques industrialisées sur les pipelines, qui dépassent la capacité de détection ou de réponse en temps réel de la plupart des équipes.
Comment l'attaque Megalodon a fonctionné : fausses identités et injection automatisée de workflows
Les attaquants derrière Megalodon n'ont pas eu recours à des exploits zero-day ni à des logiciels malveillants sophistiqués déployés sur les machines des utilisateurs finaux. Ils ont plutôt exploité la nature de confiance de l'infrastructure CI/CD de GitHub elle-même. En construisant de fausses identités de contributeurs, ils ont soumis des pull requests ou modifié directement des fichiers de configuration de workflow — plus précisément les fichiers YAML utilisés par GitHub Actions pour définir les pipelines automatisés de build et de déploiement.
Une fois qu'un fichier de workflow malveillant atterrit dans un dépôt, il s'exécute automatiquement dès que le pipeline se déclenche, généralement lors d'événements de push ou de fusions de pull requests. Cette exécution se produit dans l'environnement runner de GitHub lui-même, qui dispose souvent d'un accès aux secrets du dépôt, aux variables d'environnement et aux jetons d'accès aux fournisseurs cloud. Les workflows Megalodon ont utilisé cette fenêtre d'accès pour exfiltrer des données vers l'extérieur, vraisemblablement vers une infrastructure contrôlée par les attaquants, avant même qu'un responsable du dépôt ait eu l'occasion d'examiner la modification.
La caractéristique définissante de cette campagne est son automatisation. Exécuter près de 5 720 pushs de code distincts sur plus de 5 500 dépôts en six heures n'est pas une opération manuelle. Cela nécessite des outils scriptés capables d'identifier des cibles, de s'authentifier avec de fausses identités, de concevoir des modifications de workflow d'apparence plausible et de les soumettre en parallèle. Ce niveau d'automatisation signifie que la surface d'attaque s'est étendue plus vite qu'une équipe de surveillance humaine ne pouvait la suivre.
Quels identifiants ont été volés et pourquoi cela importe pour les développeurs
La charge utile de chaque workflow malveillant était la collecte d'identifiants. Les cibles incluaient des identifiants de fournisseurs cloud — le plus souvent des clés d'accès AWS, GCP et Azure stockées en tant que Secrets GitHub ou référencées dans des variables d'environnement de workflow. Les clés privées SSH utilisées pour l'accès aux serveurs ou l'authentification entre services étaient également visées, ainsi que tous les secrets en clair intégrés dans le code source ou les fichiers de configuration.
Ces types d'identifiants comportent des risques en cascade. Une clé d'accès AWS volée associée à un rôle IAM disposant de permissions étendues peut permettre à un attaquant de déployer de l'infrastructure, d'exfiltrer des données ou de se déplacer latéralement vers des services connectés en quelques minutes. Les clés SSH peuvent fournir un accès persistant aux serveurs de production longtemps après que la violation initiale a été détectée et que le dépôt GitHub a été nettoyé. La valeur de ces données s'étend bien au-delà des dépôts eux-mêmes.
Il ne s'agit pas d'un scénario de risque hypothétique. Plus tôt cette année, un prestataire de la CISA a exposé des clés AWS et des mots de passe en clair sur un dépôt GitHub public, démontrant que la mauvaise gestion des identifiants dans les environnements de développement touche même les organisations disposant de mandats dédiés à la sécurité. Megalodon a simplement industrialisé le même vecteur d'exploitation que des erreurs humaines individuelles ont déjà démontré à maintes reprises.
Il convient également de noter que les outils et pipelines de vol d'identifiants sont eux-mêmes des cibles. La récente attaque sur la chaîne d'approvisionnement du CLI Bitwarden a montré que même les outils utilisés par les développeurs pour gérer les secrets peuvent être compromis en amont, ce qui signifie que la chaîne de confiance s'étend au-delà de tout dépôt ou configuration de pipeline unique.
Défense en profondeur pour les équipes de développement : gestion des secrets, communications chiffrées et contrôles d'accès
Megalodon a exploité plusieurs failles qui sont courantes dans les dépôts open source et privés alike. Les corriger nécessite une approche multicouche plutôt qu'un contrôle unique.
Premièrement, les secrets ne doivent jamais être stockés en clair dans les fichiers de workflow, les fichiers de configuration d'environnement ou le code source. La fonctionnalité Secrets chiffrés de GitHub offre une base, mais ces secrets doivent également respecter le principe du moindre privilège. Un workflow qui déploie vers un environnement de staging n'a pas besoin des identifiants de base de données de production. Limiter la portée des secrets réduit le rayon de l'explosion en cas de compromission d'un workflow.
Deuxièmement, les règles de protection des branches et les exigences de relecteurs pour les modifications des fichiers de workflow créent un point de contrôle humain que les attaques automatisées doivent contourner. Exiger au moins une révision approuvée avant toute modification des fichiers .github/workflows/ peut ralentir ou bloquer le type d'injection automatisée rapide sur lequel Megalodon s'est appuyé.
Troisièmement, épingler les GitHub Actions tierces à des SHA de commit spécifiques plutôt qu'à des tags flottants empêche un vecteur d'attaque distinct mais connexe, dans lequel des éditeurs d'actions compromis mettent silencieusement à jour un tag pour pointer vers du code malveillant. C'est le mécanisme qui a été utilisé dans plusieurs incidents récents de chaîne d'approvisionnement GitHub Actions.
Enfin, la journalisation d'audit et la détection d'anomalies sur les exécutions de workflows peuvent révéler des connexions réseau sortantes inattendues ou des schémas d'accès inhabituels aux secrets. L'API de journal d'audit de GitHub et les outils tiers de sécurité CI/CD peuvent aider à faire remonter ces signaux.
Comment auditer vos dépôts GitHub et vos pipelines CI/CD dès maintenant
Si votre organisation maintient des dépôts GitHub avec des pipelines CI/CD actifs, quelques actions immédiates méritent d'être priorisées.
Examinez tous les fichiers sous .github/workflows/ pour détecter toute entrée récemment ajoutée ou modifiée, en particulier celles ajoutées par des contributeurs que vous ne reconnaissez pas. Consultez l'historique des commits pour les fichiers de workflow spécifiquement, pas seulement la vue de la branche par défaut.
Faites pivoter tous les secrets qui étaient actifs pendant la période de l'attaque ou que vous ne pouvez pas confirmer avec certitude comme n'ayant pas été exposés. Pour les identifiants cloud, consultez les journaux d'accès côté fournisseur pour détecter des appels d'API inhabituels durant la même fenêtre temporelle.
Vérifiez quels contributeurs et applications ont un accès en écriture aux dépôts. Les attaques par fausse identité dépendent de la capacité à pousser du code, donc restreindre les permissions des contributeurs et activer les révisions obligatoires pour les modifications de workflow supprime un point d'entrée clé.
Enfin, envisagez d'adopter un outil dédié à l'analyse de secrets qui s'exécute à chaque commit, interceptant les identifiants avant même qu'ils ne soient jamais committés dans un dépôt. Plusieurs options open source et commerciales s'intègrent directement avec GitHub.
Ce que cela signifie pour vous
La campagne Megalodon illustre concrètement pourquoi les pipelines CI/CD sont devenus une surface d'attaque principale. Les développeurs et les équipes de sécurité qui traitent la sécurité des pipelines comme secondaire par rapport à la sécurité applicative laissent un accès grand ouvert vers leurs identifiants les plus sensibles.
Commencez par un audit des secrets cette semaine. Vérifiez qui peut modifier vos fichiers de workflow, faites pivoter les identifiants que vous ne pouvez pas confirmer comme étant propres, et activez la protection des branches sur votre branche par défaut si ce n'est pas déjà fait. La vitesse de l'attaque Megalodon signifie qu'au moment où une alerte se déclenche, l'exfiltration peut déjà être terminée. La prévention et le cloisonnement des accès sont les seules défenses fiables.
