Comptes fantômes et jetons exposés : la cartographie de masse silencieuse qui profite de l'API GitHub

Sécurité de Datadog Labs a identifié des campagnes coordonnées qui utilisent l'API GitHub pour cartographier les organisations, les dépôts et les comptes utilisateurs à des fins de reconnaissance de masse. Bien qu'une grande partie de l'activité profite des paramètres publics, les attaquants ont combiné des outils automatisés, des vieux comptes apparemment inactifs - ce que j'appellerai comptes fantômes- et les jetons légitimes qui se sont engagés à mener l'enquête au-delà de ce qui serait normalement attendu de la démolition occasionnelle.

La principale tactique est délibérément simple et efficace: utiliser des comptes créés il y a des années et sans activité continue pour émettre des demandes d'API qui ne réveillent pas les soupçons immédiats. Lors de l'exploitation avec agents d'utilisation crédibles et les jetons exposés, le trafic est mélangé avec une utilisation légitime. Les consultations périodiques comprennent la liste des dépôts publics d'une organisation, l'exploration des adeptes, suivie par les utilisateurs, la liste des gistes et des étoiles, et l'envoi de consultations de GraphQL pour extraire des métadonnées. Dans certains cas signalés, des dépôts privés ont été clonés après avoir trouvé des justificatifs avec des permis suffisants.

Cela pose un double problème : d'une part, le grand espace public de l'API GitHub facilite la reconnaissance automatisée ; d'autre part, l'utilisation d'anciens comptes et de jetons légitimes rend difficile la détection basée sur des signatures simples ou le rejet automatique de nouveaux comptes. Le risque réel est l'accumulation de données: des centaines ou des milliers de demandes qui permettent à un attaquant de cartographier les structures internes du projet, les relations des contribuables et les vecteurs potentiels d'attaques ultérieures.

Les implications sont larges. Au-delà de l'exposition directe au code ou à la propriété intellectuelle, l'information agrégée peut faciliter les attaques ciblées du génie social, compromettre la chaîne d'approvisionnement en identifiant les dépôts avec des dépendances critiques, ou permettre des mouvements latéraux si les justificatifs sont découverts avec des permis inadéquats. Même si la plupart des demandes consomment des données publiques, le passage au clonage de dépôts privés montre qu'un petit nombre de références filtrées peuvent avoir un impact plus important.

La détection de ces campagnes nécessite des approches qui mettent l'accent sur un comportement accru plutôt que sur des signaux isolés. Les signes d'avertissement comprennent plusieurs comptes qui mènent des consultations similaires et synchronisées contre plusieurs organisations, des habitudes de rémunération intensives, l'utilisation répétitive de certains utilisateurs-agents apparemment légitimes et des pics de clone ou de téléchargement simultanés. Il est essentiel d'examiner les dossiers d'audit et de les corréler avec des sources externes pour identifier ce comportement avant qu'il n'entraîne une infiltration.

Concrètement, les organisations peuvent et doivent prendre des mesures concrètes pour réduire la zone exposée. Parmi les actions les plus efficaces figurent: activer l'authentification multifacteur et SAML / SSO requis pour les membres de l'organisation, imposer des politiques pour l'expiration et la rotation des jetons, appliquer le principe de privilège mineur au moyen de jetons à portée restreinte (PAT à grain fin) et révoquer l'accès inutile ou les comptes inactifs. En outre, il est recommandé d'activer la numérisation des secrets et la protection des succursales, et de limiter l'accès aux applications OAuth de tiers par des examens réguliers.

D'un point de vue de la surveillance, les entreprises devraient intégrer le journal de GitHub à leur SGI, établir des alertes pour les modèles d'inscription de masse et les clones de dépôts sensibles, et évaluer l'adoption d'outils qui détectent la synchronisation inhabituelle entre plusieurs comptes. Il convient également de vérifier régulièrement les listes des membres et des partenaires externes et d'utiliser des dépôts d'orge contrôlés pour mesurer les activités suspectes sans exposer les actifs réels.

Pour les développeurs et les équipements techniques, les recommandations spécifiques passent en ne stockant pas de jetons dans les dépôts ou dans l'historique, en utilisant des variables d'environnement et des gestionnaires secrets, en préférant les méthodes d'authentification avec simple expiration et révocation, et en définissant des autorisations minimales pour les actions GitHub et pour chaque workflow. Examiner les intégrations et les applications autorisées et limiter les webhooks publics réduit les vecteurs d'exploitation.

Ce type de menace rappelle que la sécurité sur les plateformes collaboratives nécessite à la fois des contrôles techniques et une gouvernance continue : des politiques d'accès claires, des examens périodiques et la télémétrie pour voir les tendances globales. Pour approfondir les bonnes pratiques de sécurité à GitHub et comment gérer les jetons et l'authentification, consultez la documentation officielle de GitHub à https: / / docs.github.com / fr / authentification / gardant votre compte et vos données sécurisés et l'analyse des menaces et les publications de Datadog Security Labs en https: / / www.datadoghq.com / blog / catégorie / sécurité / fournir un contexte supplémentaire et des exemples techniques.