Die Methode zum Sammeln von Geheimnissen umfasst verschiedene Phasen, mit denen Sie Verschlusssachen letztendlich mit einem hohen Maß an Sicherheit identifizieren können. Illustration aus einer wissenschaftlichen ArbeitGitHub und ähnliche Plattformen für Open Source Publishing sind heute Standardwerkzeuge für Entwickler. Ein Problem tritt jedoch auf, wenn dieser Open Source-Code mit Authentifizierungstoken, privaten API-Schlüsseln und privaten kryptografischen Schlüsseln funktioniert. Um die Sicherheit zu gewährleisten, müssen diese Daten geheim gehalten werden. Leider fügen viele Entwickler dem Code vertrauliche Informationen hinzu, was häufig zu versehentlichen Informationslecks führt.
Ein Forscherteam der University of North Carolina führte eine
groß angelegte Studie zu klassifizierten Datenlecks auf GitHub durch.
Sie scannten Milliarden von Dateien, die mit zwei sich ergänzenden Methoden gesammelt wurden:
- Fast sechs Monate dauernde öffentliche Commit-Scans von GitHub in Echtzeit
- Momentaufnahme der öffentlichen Repositorys, die 13% aller Repositorys auf GitHub abdecken, insgesamt etwa 4 Millionen Repositorys.
Die Schlussfolgerungen sind enttäuschend. Wissenschaftler haben nicht nur entdeckt, dass Lecks weit verbreitet sind und mehr als 100.000 Repositories betreffen. Schlimmer noch, täglich kommen Tausende neuer, einzigartiger „Geheimnisse“ zu GitHub.
In der Tabelle sind die APIs beliebter Dienste und die mit dem Verlust dieser Informationen verbundenen Risiken aufgeführt.
Allgemeine Statistiken zu den gefundenen geheimen Objekten zeigen, dass Google API-Schlüssel am häufigsten gemeinfrei sind. Private RSA-Schlüssel und Google OAuth-Kennungen sind ebenfalls häufig. In der Regel tritt die überwiegende Mehrheit der Lecks über Repositorys mit einem Eigentümer auf.
| Geheimnis | Insgesamt | Einzigartig | %, ein Eigentümer |
|---|
| Google API-Schlüssel | 212 892 | 85 311 | 95,10% |
| RSA Geheimschlüssel | 158 011 | 37,781 | 90,42% |
| Google OAuth ID | 106 909 | 47.814 | 96,67% |
| Normaler privater Schlüssel | 30,286 | 12.576 | 88,99% |
| Amazon AWS Access Key ID | 26 395 | 4648 | 91,57% |
| Twitter-Zugriffstoken | 20.760 | 7953 | 94,83% |
| Privater Schlüssel EC | 7838 | 1584 | 74,67% |
| Facebook-Zugriffstoken | 6367 | 1715 | 97,35% |
| PGP Private Key | 2091 | 684 | 82,58% |
| MailGun API-Schlüssel | 1868 | 742 | 94,25% |
| MailChimp-API-Schlüssel | 871 | 484 | 92,51% |
| Stripe Standard API Key | 542 | 213 | 91,87% |
| Twilio API-Schlüssel | 320 | 50 | 90,00% |
| Square Access Token | 121 | 61 | 96,67% |
| Geheimer Platz OAuth | 28 | 19 | 94,74% |
| Amazon MWS Auth Token | 28 | 13 | 100,00% |
| Braintree-Zugriffstoken | 24 | 8 | 87,50% |
| Picatic API-Schlüssel | 5 | 4 | 100,00% |
| Insgesamt | 575,456 | 201 642 | 93,58% |
Durch die Echtzeitüberwachung von Commits konnte festgestellt werden, wie viele vertrauliche Informationen kurz nach ihrer Ankunft aus den Repositorys entfernt wurden. Es stellte sich heraus, dass am ersten Tag etwas mehr als 10% der Geheimnisse gelöscht werden und an den nächsten Tagen einige Prozent jedoch zwei Wochen nach der Hinzufügung mehr als 80% der privaten Informationen in den Repositories verbleiben, und dieser Anteil nimmt in der Folge praktisch nicht ab.
Zu den auffälligsten Lecks zählen ein AWS-Konto einer Regierungsbehörde in einem der osteuropäischen Länder sowie 7.280 private RSA-Schlüssel für den Zugriff auf Tausende privater VPNs.
Die Studie zeigt, dass ein Angreifer selbst mit minimalen Ressourcen viele GitHub-Benutzer gefährden und eine Menge privater Schlüssel finden kann. Die Autoren stellen fest, dass viele bestehende Schutzmethoden gegen die Erfassung von Verschlusssachen unwirksam sind. Beispielsweise weisen Tools wie TruffleHog nur einen Wirkungsgrad von 25% auf. Das integrierte GitHub-Limit für die Anzahl der API-Anforderungen kann ebenfalls leicht umgangen werden.
Viele entdeckte Geheimnisse haben jedoch klare Muster, die es einfach machen
ihre Suche. Es ist logisch anzunehmen, dass dieselben Muster verwendet werden können, um den Verlust von Verschlusssachen zu überwachen und Entwickler zu warnen. Wahrscheinlich sollten solche Mechanismen auf der Serverseite implementiert werden, d. H. Auf GitHub. Ein Dienst kann während eines Commits ein Warnrecht ausgeben.
GitHub hat kürzlich eine Beta-Version des Token-Scannens (
Token-Scan- Funktion) implementiert, mit der Repositorys gescannt, nach Token gesucht und Dienstanbieter über Informationslecks informiert werden. Der Anbieter kann diesen Schlüssel wiederum stornieren. Die Autoren glauben, dass GitHub dank ihrer Forschung diese Funktion verbessern und die Anzahl der Anbieter erhöhen kann.