Les chercheurs ont découvert une campagne soutenue utilisant les API publiques et les comptes fantômes de GitHub pour profiler les environnements logiciels d’entreprise tout en se fondant dans l’activité normale des développeurs.
GitHub continue d’être une cible scintillante pour les attaquants car il se situe au milieu de la chaîne d’approvisionnement des logiciels et offre aux acteurs de la menace trois choses dont ils ont envie : le code source, les secrets et les pipelines automatisés dans lesquels se déchaîner.
Datadog Security Research a suivi ce qu’il appelle un « modèle soutenu » d’abus de l’API GitHub au cours des derniers mois, dans le but de cartographier les organisations et leurs membres. Même si individuellement ces requêtes sont « banales », elles deviennent dangereuses lorsqu’elles se déplacent d’un environnement à l’autre pendant des semaines et, pire encore, lorsqu’elles progressent vers un clonage complet. Le plus grand défi est qu’ils s’intègrent dans les modèles normaux d’utilisation des API.
GitHub est une mine d’or pour les criminels cherchant à pirater les organisations, car de nombreux cycles de développement ne sont pas sécurisés, a déclaré David Shipley de Beauceron Security. En règle générale, les acteurs malveillants recherchent des clés API et des secrets cloud.
« Maintenant que tout le monde est poussé à faire plus, plus vite, grâce au codage des agents d’IA, le trésor de secrets est probablement encore plus grand », a-t-il déclaré. « En bref, pour reprendre une phrase d’une précédente ruée vers l’or de l’ère analogique, ‘il y a de l’or dans ces collines’. »
Scott Miserendino, CTO de la société de sécurité et de conformité DataBee, est d’accord. « Github est le référentiel de code source le plus populaire pour les projets open source et d’entreprise », a-t-il déclaré. « Son grand nombre de projets, ainsi que le fait qu’il héberge certains des logiciels les plus populaires et les plus utilisés, en font une cible. »
Il a noté que le vol de propriété intellectuelle, tel que le clonage non autorisé de référentiels privés, peut être utilisé pour utiliser des logiciels propriétaires ou trouver des vulnérabilités pouvant être exploitées.
Une deuxième attaque populaire consiste à rechercher des référentiels contenant les informations d’identification par défaut des logiciels populaires. En les utilisant, les attaquants peuvent développer et tester des attaques sur des comptes présents dans les environnements de production ou installés par défaut sur certaines appliances.
Et Julie Agnes Sparks, ingénieure de sécurité senior chez Datadog, a écrit dans un article de blog : « L’activité n’est pas le fait d’un seul acteur. Il s’agit plutôt d’un mélange d’outils d’analyse automatisés personnalisés, d’abus opportunistes de fuites d’informations d’identification et de réseaux coordonnés de comptes brûleurs (fantômes). »
Un moyen simple mais efficace de cartographier les utilisateurs de GitHub
Sparks a expliqué qu’une « grande part » de la surface de l’API de GitHub peut être atteinte sans authentification ; il est public par conception. Les requêtes adressées aux API produisent généralement des réponses HTTP 200 standard.
Cela signifie qu’un acteur malveillant peut créer des cartes détaillées des organisations, de leurs référentiels publics, de leurs membres, des personnes qu’ils suivent, de leurs dépôts favoris et des projets avec lesquels ils interagissent. Ce trafic se fond dans l’utilisation normale de l’API et ne semble donc pas suspect, a-t-elle déclaré.
De plus, GitHub ne collecte des données de géolocalisation que lorsqu’un utilisateur interagit avec des référentiels privés, enregistrant qui il est et quel jeton d’accès il a utilisé, et non lorsqu’il interagit avec des ressources externes. Cela limite la géolocalisation et l’attribution basée sur VPN/proxy.
En règle générale, les auteurs de menaces effectuent un scraping automatisé avec des agents utilisateurs personnalisés ou d’apparence légitime, tirant parti des comptes « fantômes » GitHub, des profils créés il y a entre deux et cinq ans et laissés inactifs.
Il s’agit d’une méthode intéressante car, a noté Sparks, « un compte avec un historique de plusieurs années se lit comme plus légitime qu’un compte enregistré la semaine même où il commence à être supprimé ».
En règle générale, ces comptes sont utilisés pendant une « rafale » d’une à trois semaines seulement dans plusieurs entreprises à la fois, puis leur utilisation s’arrête. Les chercheurs ont identifié plus de 50 comptes fantômes répartis sur plusieurs agents utilisateurs, regroupés en familles portant des noms tels que , , ou .
Certaines campagnes ont utilisé les comptes légitimes d’utilisateurs de GitHub qui avaient publié par inadvertance leurs jetons OAuth ou leurs jetons d’accès personnel (PAT), ou dont les points de terminaison avaient été compromis ou exposés d’une autre manière.
Les attaquants utilisent un mélange d’agents d’exfiltration de données portant des noms tels que et, conçus pour se fondre dans le trafic normal d’analyse de données. La majeure partie des requêtes ciblent le langage de requête open source, qui est « bien adapté » aux requêtes groupées auprès des entreprises, des utilisateurs et des référentiels, a noté Sparks. Les points de terminaison REST normaux sont utilisés pour le mappage organisationnel.
L’objectif des campagnes était « étroit et cohérent » et la préoccupation « réside dans l’ensemble », a déclaré Sparks. Isolées, les requêtes ciblent les référentiels publics sans authentification et renvoient des réponses réussies. Cela produit rarement un « accès significatif » aux référentiels d’une entreprise.
Mais un groupe de comptes synchronisés sur des comptes GitHub partagés avec des outils personnalisés et versionnés sur une période de plusieurs semaines représente un comportement plus troublant et systématique. Elle a cité un événement au cours duquel des dizaines de comptes d’utilisateurs GitHub distincts, légitimes mais compromis, ont adressé des requêtes API à une seule organisation en quelques minutes seulement, bien que dans ce cas, l’attaque ait échoué, car ils ciblaient les chemins de validation du référentiel privé.
Comment les entreprises peuvent protéger leurs environnements GitHub
Sparks a souligné que ces comportements peuvent être recherchés et détectés « si vous surveillez les bons champs », tels que ceux identifiant l’agent utilisateur, le type de jeton, le numéro de système autonome (ASN) ou la tentative d’action.
« Les agents utilisateurs, l’activité des événements et les noms des acteurs sont des indices essentiels d’activités non autorisées dans votre environnement », a souligné Sparks. Elle a suggéré d’examiner le comportement inhabituel des agents utilisateurs dans les journaux d’audit de GitHub, en particulier pour ceux qui s’étendent aux référentiels privés où la plateforme capture également l’adresse IP, le nom de l’acteur et le type d’accès programmatique.
Les entreprises doivent également activer la diffusion en continu des journaux d’audit GitHub, des agents utilisateurs de base et effectuer une recherche proactive des menaces. Plus important encore, a-t-elle déclaré, ils devraient développer des détections uniques à leur organisation GitHub, notant : « Il est important de savoir à quoi ressemble la normale dans votre environnement. »
En termes simples, a ajouté Miserendino, les entreprises devraient suivre les meilleures pratiques de sécurité, notamment en activant l’authentification multifacteur (MFA) sur tous les comptes, en effectuant des contrôles périodiques des accès des utilisateurs, en supprimant tous les comptes inutilisés ou inutiles et en analysant les référentiels pour rechercher les informations d’identification stockées en texte brut plutôt que dans un magasin secret.
