Das Token läuft ab. Der Key nicht.
Die Authentifizierung von GitHub Apps basiert auf einem private key, der ein JSON Web Token (JWT) mit einer maximalen Lebensdauer von 10 Minuten generiert. Dieses JWT fordert dann ein Installations-Zugriffstoken an, das bis zu einer Stunde gültig ist. GitHub erzwingt diese nachgelagerten Token-Ablaufzeiten strikt, was die Illusion eines vorübergehenden Zugriffs erzeugt.
Der Root-private-key, die Quelle dieser Anmeldedaten, besitzt jedoch keine native Time-to-Live (TTL). Er kann dauerhaft neue Token erstellen, bis er explizit widerrufen wird. Diese grundlegende architektonische Entscheidung bedeutet, dass ein kompromittierter oder vergessener Key eine dauerhafte Bedrohung bleibt, im Gegensatz zu den kurzlebigen Token, die er produziert.
Während einige argumentieren, dass dies dem Verhalten von SSH-Keys entspricht, denen ebenfalls häufig eine plattformseitig erzwungene Ablaufzeit fehlt, erhöht der Umfang der GitHub App-Berechtigungen das Risiko drastisch. Apps verfügen oft über weitreichenden Zugriff auf mehrere Repositories, einschließlich:
- Administrative Privilegien für Organisationen
- Schreibzugriff auf privaten Code
- Kontrolle über selbst gehostete Runner und Workflow-Ausführungen
Die Untersuchung von GitGuardian ergab 474 aktive Keys, von denen 44 volle Org-Admin-Rechte gewährten. Ein Key, der mit der US CDC verknüpft war, ermöglichte 17 Monate nach seinem Leak Schreibzugriff auf privaten Code. Dies verdeutlicht, warum nicht verwaltete GitHub App-Keys ein erhebliches, dauerhaftes Governance-Risiko darstellen, das weit über das eines typischen SSH-Keys hinausgeht.
474 geleakte Keys öffneten weiterhin Tür und Tor
Die aktuelle Untersuchung von GitGuardian deckte eine harte Realität auf: Von über 500.000 exponierten RSA-Keys waren 4.802 mit einer GitHub App ID verknüpft. Erschreckende 474 dieser Keys authentifizierten sich weiterhin, was 440 verschiedenen Apps entspricht, obwohl sie öffentlich zugänglich waren. Dies zeigt eine kritische Schwachstelle in der Sicherheitskette.
Die Auswirkungen dieser dauerhaften Expositionen sind schwerwiegend. Vierundvierzig gültige Apps hatten vollen Organisations-Admin-Zugriff, während 72 % private Repositories lesen konnten. Darüber hinaus besaßen 207 Apps Schreibberechtigungen, was Tür und Tor für willkürliche Code-Injektionen und Pipeline-Manipulationen öffnete – ein erhebliches Risiko für die Sicherheit der Lieferkette.
Die Persistenz des Problems ist beunruhigend. Ein Crusher.dev-Key war seit 2020 öffentlich und blieb aktiv. Ein mit der US CDC verknüpfter Key blieb Berichten zufolge 17 Monate nach seiner Exposition gültig. Eine weitere weit verbreitete App, "Access Tokens for GitHub Actions", leakte im Januar 2024 einen private key, was etwa 300 Organisationen betraf, darunter den Verteidigungsauftragnehmer Sierra Nevada Corp.
Diese Beispiele unterstreichen die Gefahr von GitHub App private keys: Im Gegensatz zu den kurzlebigen JWTs und Installations-Zugriffstoken, die sie erstellen, haben die Root-private-keys selbst kein natives Ablaufdatum. Dieses architektonische Versäumnis verwandelt ein einzelnes Leak in eine dauerhafte Sicherheitsbedrohung, die sofortige Aufmerksamkeit und robuste Strategien zur Key-Rotation erfordert.
Eine vergessene App kann zu einem Einfallstor für die Lieferkette werden
Eine vergessene App stellt ein erhebliches Einfallstor für die Lieferkette dar. Geleakte Keys können es einem Angreifer ermöglichen, privaten Code zu lesen, in Repositories zu schreiben, Workflows zu manipulieren oder selbst gehostete Runner zu verwalten. Ein solcher Zugriff erleichtert direkt die Manipulation von Code, die Kompromittierung von CI/CD und letztendlich die Übernahme der Organisation.
Veraltete Integrationen werden leicht übersehen. GitGuardian stellte fest, dass 59 % der 440 verschiedenen Apps mit aktiven Schlüsseln nur eine Installation aufwiesen, oft für Ad-hoc-Automatisierungen. Wenn Ingenieure das Unternehmen verlassen oder Projekte aufgegeben werden, geht die Zuständigkeit für diese Apps häufig verloren, was eine dauerhafte Sicherheitslücke hinterlässt. Der App-Schlüssel von Crusher.dev, der seit 2020 offengelegt war, blieb noch Jahre nach Einstellung der Projektwartung aktiv.
Die US-Gesundheitsbehörde Centers for Disease Control and Prevention (CDC) hatte beispielsweise einen geleakten privaten Schlüssel mit Schreibzugriff auf private Repositories, der 17 Monate lang bestand und den Zugriff auf ihre Microsoft Azure-Infrastruktur vermittelte. Ähnlich verhielt es sich bei der weit verbreiteten App "Access Tokens for GitHub Actions", bei der ein privater Schlüssel geleakt wurde, was etwa 300 Organisationen gefährdete.
Obwohl ein gültiger Schlüssel nicht automatisch eine aktive Ausnutzung beweist, bedeutet er eine dauerhafte Gefährdung. Angreifer können, sobald sie einen gültigen Schlüssel erhalten haben, jederzeit mit den erteilten Berechtigungen der App agieren. Weitere Details zu diesen anhaltenden Bedrohungen finden Sie in der Untersuchung von GitGuardian: GitHub App Private Keys: 474 Leaked Keys Still Work. Dies unterstreicht die dringende Notwendigkeit einer strengen Verwaltung von GitHub App private keys und den damit verbundenen Berechtigungen, um supply-chain risks zu mindern.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Rotieren ohne Ausfallzeiten – und stilllegen, was niemandem gehört
App-Besitzer müssen eine robuste Strategie zur Schlüsselrotation implementieren. Generieren Sie einen neuen private key, stellen Sie ihn bereit, überprüfen Sie seine Funktionalität und widerrufen Sie dann den alten. GitHub erlaubt bis zu 25 aktive private Schlüssel pro App, was eine gestaffelte Rotation ohne Dienstunterbrechung ermöglicht.
Etablieren Sie einen dokumentierten Rotationsrhythmus, sichere Protokolle zur Schlüsselspeicherung und integrieren Sie secret scanning in allen Repositories, einschließlich der von Entwicklern erstellten öffentlichen Forks. Erzwingen Sie das Prinzip der geringsten Rechte (Least-Privilege-Zugriff) und beschränken Sie die App-Berechtigungen nur auf die Repositories und Aktionen, die für ihre Funktion unbedingt erforderlich sind. Dies minimiert den Schadensradius bei einer möglichen Kompromittierung.
Organisationsadministratoren stehen vor der kritischen Aufgabe, installierte Apps zu prüfen. Identifizieren und benennen Sie verantwortliche Eigentümer für jede Integration. Entfernen Sie umgehend verlassene oder nicht gewartete Apps, da diese zu Hauptzielen für Angreifer werden, die einen dauerhaften Fuß in der Tür suchen.
Stellen Sie abschließend sicher, dass alle verbleibenden Apps mit den absolut minimal erforderlichen Berechtigungen arbeiten. Die Überprüfung und Verschärfung dieser Zugriffskontrollen verringert die Angriffsfläche und verhindert, dass eine vergessene App zu einem offenen Tor für die sensibelsten Vermögenswerte Ihres Unternehmens wird.
Häufig gestellte Fragen
Laufen private Schlüssel für GitHub Apps automatisch ab?
Nein. Private Schlüssel für GitHub Apps haben kein eingebautes Ablaufdatum, daher müssen Besitzer sie rotieren und widerrufen.
Wie kann ein nicht abgelaufener GitHub App-Schlüssel verwendet werden?
Er kann ein kurzlebiges JWT signieren, das gegen ein Installations-Zugriffstoken ausgetauscht werden kann, das bis zu einer Stunde gültig ist.
Wie viele private Schlüssel für GitHub Apps können gleichzeitig aktiv sein?
GitHub erlaubt bis zu 25 private Schlüssel für eine App, was es Teams ermöglicht, einen Ersatz bereitzustellen, bevor der alte Schlüssel gelöscht wird.
Was sollte eine Organisation bei Apps tun, die niemand wartet?
Prüfen Sie installierte GitHub Apps, entfernen Sie veraltete oder herrenlose Integrationen und schränken Sie die Berechtigungen und Repositories für die verbleibenden Apps ein.