La méthodologie de collecte des secrets comprend différentes phases, ce qui vous permet d'identifier à terme des informations classifiées avec un haut degré de confiance. Illustration d'un travail scientifiqueGitHub et les plates-formes similaires pour la publication open source sont devenus aujourd'hui des outils standard pour les développeurs. Cependant, un problème se pose si ce code open source fonctionne avec des jetons d'authentification, des clés API privées et des clés cryptographiques privées. Pour assurer la sécurité, ces données doivent être gardées secrètes. Malheureusement, de nombreux développeurs ajoutent des informations sensibles au code, ce qui entraîne souvent des fuites d'informations accidentelles.
Une équipe de chercheurs de l'Université de Caroline du Nord a mené une
étude à grande échelle sur les fuites de données classifiées sur GitHub.
Ils ont scanné des milliards de fichiers, qui ont été collectés par deux méthodes complémentaires:
- Près de six mois de GitHub public commit scans en temps réel
- aperçu des référentiels publics couvrant 13% de tous les référentiels sur GitHub, soit environ 4 millions de référentiels.
Les conclusions sont décevantes. Les scientifiques ont non seulement découvert que les fuites sont répandues et affectent plus de 100 000 référentiels. Pire encore, des milliers de nouveaux «secrets» uniques arrivent chaque jour sur GitHub.
Le tableau répertorie les API des services populaires et les risques associés à la fuite de ces informations.
Les statistiques générales sur les objets secrets trouvés montrent que le plus souvent les clés API Google tombent dans le domaine public. Les clés privées RSA et les identifiants Google OAuth sont également courants. En règle générale, la grande majorité des fuites se produisent via des référentiels à propriétaire unique.
| Secret | Total | Unique | %, un propriétaire |
|---|
| Clé API Google | 212 892 | 85 311 | 95,10% |
| Clé secrète RSA | 158 011 | 37 781 | 90,42% |
| ID Google OAuth | 106 909 | 47 814 | 96,67% |
| Clé privée régulière | 30,286 | 12 576 | 88,99% |
| ID de clé d'accès Amazon AWS | 26 395 | 4648 | 91,57% |
| Jeton d'accès Twitter | 20 760 | 7953 | 94,83% |
| Clé privée EC | 7838 | 1584 | 74,67% |
| Jeton d'accès Facebook | 6367 | 1715 | 97,35% |
| Clé privée PGP | 2091 | 684 | 82,58% |
| Clé API MailGun | 1868 | 742 | 94,25% |
| Clé API MailChimp | 871 | 484 | 92,51% |
| Clé API standard Stripe | 542 | 213 | 91,87% |
| Clé API Twilio | 320 | 50 | 90,00% |
| Jeton d'accès carré | 121 | 61 | 96,67% |
| Secret Square OAuth | 28 | 19 | 94,74% |
| Jeton d'authentification Amazon MWS | 28 | 13 | 100,00% |
| Jeton d'accès Braintree | 24 | 8 | 87,50% |
| Clé API Picatic | 5 | 4 | 100,00% |
| Total | 575,456 | 201 642 | 93,58% |
La surveillance en temps réel des validations a permis de déterminer la quantité d'informations sensibles supprimées des référentiels peu après leur arrivée. Il s'est avéré que le premier jour, un peu plus de 10% des secrets sont supprimés et les jours suivants, quelques pour cent, cependant, plus de 80% des informations privées restent dans les référentiels deux semaines après l'ajout, et cette proportion ne diminue pratiquement pas dans les suivantes.
Parmi les fuites les plus notables figurent un compte AWS d'une agence gouvernementale dans l'un des pays d'Europe de l'Est, ainsi que 7 280 clés RSA privées pour accéder à des milliers de VPN privés.
L'étude montre qu'un attaquant, même avec des ressources minimales, peut compromettre de nombreux utilisateurs de GitHub et trouver une tonne de clés privées. Les auteurs notent que de nombreuses méthodes de protection existantes sont inefficaces contre la collecte d'informations classifiées. Par exemple, des outils comme TruffleHog ne montrent qu'une efficacité de 25%. La limite GitHub intégrée sur le nombre de demandes d'API est également facilement contournée.
Cependant, de nombreux secrets découverts ont des modèles clairs qui facilitent la tâche
leur recherche. Il est logique de supposer que ces mêmes modèles peuvent être utilisés pour surveiller les fuites d'informations classifiées et avertir les développeurs. Probablement, de tels mécanismes devraient être implémentés côté serveur, c'est-à-dire sur GitHub. Un service peut émettre un droit d'avertissement lors d'une validation.
GitHub a récemment implémenté une version bêta de l'analyse des jetons (fonction d'
analyse des jetons ), qui analyse les référentiels, recherche les jetons et avertit les fournisseurs de services de toute fuite d'informations. À son tour, le vendeur peut annuler cette clé. Les auteurs pensent que grâce à leurs recherches, GitHub peut améliorer cette fonctionnalité et augmenter le nombre de fournisseurs.