Ayant un peu de temps devant lui en plein confinement lié à la situation sanitaire, un chercheur en sécurité a profité de l'occasion pour tenter une expérience. Craig Hays s'est ainsi mis en tête de divulguer un nom d'utilisateur et un mot de passe (SSH) dans un référentiel GitHub et voir si un attaquant pourrait le trouver. Au départ, il pensait qu'il devrait attendre quelques jours, peut-être une semaine, avant que quelqu'un ne s'en aperçoive. Mais la réalité s'est avérée plus brutale : la première connexion non autorisée s'est ainsi produite dans les 34 minutes. « La plus grande révélation pour moi a été la rapidité avec laquelle ce référentiel a été exploité », a indiqué Craig Hayes à notre confrère CSO. Au cours des 24 premières heures, six adresses IP différentes se sont connectées neuf fois au total à son honeypot. Un attaquant a tenté d'installer un client botnet, un autre d'utiliser le serveur pour lancer une attaque par déni de service. Le chercheur s'est également rendu compte qu'une personne voulait voler des informations sensibles sur le serveur tandis qu'une autre commençait à mettre son nez un peu partout.

Cette expérience a montré à Craig Hayes que les acteurs de la menace scannent constamment GitHub et d'autres référentiels de code publics à la recherche de données sensibles laissées par les développeurs. Le volume de secrets, comprenant noms d'utilisateur, mots de passe, clés Google, outils de développement ou clés privées, ne cesse d'augmenter à mesure que les entreprises passent des applications sur site au cloud et que de plus en plus de développeurs travaillent à domicile. Rien que cette année, la hausse des secrets exposés par rapport à l'année précédente devrait être d'au moins 20%, selon Eric Fourrier, co-fondateur de la start-up française de sécurité GitGuardian, qui analyse les référentiels publics pour identifier les données dont les attaquants pourraient tirer parti.

Comment les hackers trouvent les secrets GitHub

Les pirates savent que GitHub est un endroit idéal pour trouver des informations sensibles. Des organisations telles que les Nations Unies, Equifax, Codecov, Starbucks et Uber en ont d'ailleurs fait les frais. Certaines entreprises pourraient prétendre qu'elles ne courent aucun risque parce qu'elles ne fonctionnent pas avec du code open source, mais la vérité est plus nuancée, car les développeurs utilisent souvent leur référentiel personnel pour des projets professionnels. Selon le rapport State of Secrets Sprawl sur GitHub, 85% des fuites se produisent ainsi sur les référentiels personnels des développeurs et seulement 15% dans les référentiels appartenant à des organisations. On y trouve dessus des historiques de commandes shell, des fichiers d'environnement et du contenu protégé par des droits d'auteur. Parfois, ils font des erreurs parce qu'ils essaient de rationaliser leurs processus. Par exemple, ils peuvent inclure, à des fins d'aide au débogage, leurs informations d'identification lorsqu'ils écrivent du code. Ils peuvent aussi oublier de le supprimer. Même s'iproblèmesuent un commit de suppression plus tard ou une action pour effacer les secrets, ces informations privées sont souvent toujours accessibles dans l'historique Git.

« Je trouve beaucoup de mots de passe dans les anciennes versions de fichiers qui ont été remplacés par des versions plus récentes et plus propres sans les mots de passe », explique Craig Hays. « L'historique des commits Git se souvient de tout, à moins que vous ne le supprimiez délibérément et explicitement ». Les développeurs juniors et seniors peuvent faire des erreurs. « Même si vous êtes un grand développeur et que vous êtes éduqué sur le problème, à un moment donné, lorsque vous codez tard dans la nuit, vous pouvez faire une erreur et des choses se produisent », poursuit Eric Fourrier. « La fuite de secrets est une erreur humaine ».

Alors que tout développeur est sujet aux erreurs, ceux qui viennent d'entrer sur le marché du travail divulguent généralement le plus de secrets. Il y a de nombreuses années, alors qu'elle était étudiante en génie logiciel, Crina Catalina Bucur a créé un compte AWS à des fins de développement et a reçu une facture de 2 000 $... alors qu'elle ne devait payer pas plus d'un centime pour ce service. « Mon projet était une plateforme de gestion de fichiers agrégée pour une dizaine de services de stockage cloud, dont le S3 d'Amazon », a-t-elle déclaré. « C'était avant que GitHub ne propose des référentiels privés gratuits, donc ma clé d'accès AWS et la clé secrète correspondante ont été publiées avec le code dans mon référentiel public. Je ne pensais pas alors que j'aurai dû y accorder plus d'attention ». Quelques jours plus tard en effet, elle a commencé à recevoir des e-mails d'AWS l'avertissant que son compte était compromis, mais elle ne les a pas lus avec attention jusqu'à ce qu'elle reçoive la facture. Heureusement pour elle, le support AWS a supprimé les frais supplémentaires. Les erreurs de Crina Catalina ont été exploitées par des pirates, notamment le codage en dur des clés par commodité et leur publication dans un référentiel de code public.

Des ressources supplémentaires pour exploiter les erreurs

Aujourd'hui, les pirates qui veulent trouver des erreurs comme celles-ci ont besoin de peu de ressources, explique Craig Hays. Chasseur de bug pour toucher des primes pendant son temps libre, il s'appuie souvent sur des informations open source (OSINT) que tout le monde peut trouver sur le Web pour peu de savoir chercher un peu. « Ma méthode de prédilection consiste à rechercher manuellement à l'aide de l'interface standard Github.com », a-t-il déclaré. « J'utilise des opérateurs de recherche pour restreindre à des types de fichiers, des mots-clés, des utilisateurs et des organisations particuliers, en fonction des entreprises que je cible ».

Certains outils peuvent rendre le processus plus rapide et plus efficace. « Les attaquants exécutent des robots automatisés qui récupèrent le contenu GitHub et extraient des informations sensibles », explique Gabriel Cirlig, chercheur en sécurité chez Human. Ces robots peuvent fonctionner en permanence, ce qui signifie que les pirates peuvent détecter les erreurs en quelques secondes ou minutes. Une fois qu'un secret est trouvé, les attaquants peuvent facilement l'exploiter. « Par exemple, si vous trouvez une clé AWS, vous avez accès à toute l'infrastructure cloud de l'entreprise », explique Eric Fourrier. « C'est très simple de cibler des développeurs travaillant pour une entreprise spécifique et d'essayer d'examiner certains des actifs de l'entreprise. » Selon la nature des secrets, les pirates peuvent faire beaucoup de choses, y compris lancer des attaques de chaîne d'approvisionnement et compromettre la sécurité des clients d'une entreprise.

Comment les entreprises peuvent protéger les secrets des fuites de GitHub

À mesure que le volume de secrets augmente, les entreprises doivent mieux les détecter avant qu'il ne soit trop tard. GitHub possède son propre « programme partenaire d'analyse secrète », qui trouve des chaînes de texte qui ressemblent à des mots de passe, des clés SSH ou des jetons d'API. GitHub s'est associé à plus de 40 fournisseurs de services cloud pour corriger automatiquement les clés API exposées dans les référentiels publics. « Nous cherchons continuellement à mettre un terme à ces problemes pour mieux protéger l'écosystème », a déclaré un porte-parole de GitHub à CSO. « Nous révoquons actuellement plus de 100 clés d'API GitHub exposées chaque jour, introduisant souvent en toute sécurité les nouveaux développeurs à l'importance de la sécurité des informations d'identification. »

Craig Hays a déclaré que le « programme partenaire de numérisation secrète » est un pas dans la bonne direction, car il rend plus difficile la tâche des attaquants de trouver des informations d'identification valides. Mais l'initiative n'est pas parfaite pour autant : « cela laisse encore un vide lorsque les gens vérifient accidentellement leurs propres clés SSH, mots de passe, jetons ou tout autre élément sensible », dit-il. « C'est beaucoup plus difficile à détecter et à gérer car il n'y a pas de fournisseurs d'informations d'identification partenaires pour poser des questions telles que « Est-ce réel ? Voulez-vous le révoquer ? L'un de nous devrait-il en informer le propriétaire ? ». Il conseille aussi aux développeurs de prendre conscience de la façon dont ils écrivent et déploient leur code.

« L'une des premières choses à faire est d'ajouter les paramètres corrects à un fichier .gitignore », a-t-il déclaré. « Ce fichier indique à Git et donc à GitHub.com quels fichiers ne doivent pas être suivis et téléchargés sur Internet ». Certaines start-ups de la sécurité tentent également proposer une solution. C'est le cas de GittyLeaks, SecretOps, gitLeaks et GitGuardian avec quelques couches de protection supplémentaires pour les utilisateurs professionnels et indépendants. Certains détectent ainsi les secrets divulgués en quelques secondes, permettant aux développeurs et aux entreprises de prendre des mesures immédiates. « Nous scannons tout votre code sur votre logiciel tout au long du cycle de développement, le conteneur Docker, différents types de données », explique Fourrier. « Nous trouvons les secrets et essayons de les révoquer ». Idéalement, cependant, la meilleure stratégie consiste à ne pas divulguer du tout - ou le moins possible - de secrets et pour cela la sensibilisation à certainement un rôle à jouer pour y parvenir. « Former les développeurs à l'écriture de code sécurisé et à l'arrêt proactif des bots est toujours mieux que de risquer de trop en dévoiler », déclare Cirlig.