CISA und der Leak von Zugangsdaten auf GitHub: Sechs Monate Offenlegung und ein fehlgeschlagenes Meldesystem

Einleitung

Die Cybersecurity and Infrastructure Security Agency (CISA), die US-Bundesbehörde für den Schutz kritischer Infrastrukturen, war von einem schwerwiegenden internen Sicherheitsvorfall betroffen. Ein externer Mitarbeiter (Contractor) hatte auf einem öffentlichen GitHub-Repository rund 844 MB sensible Daten veröffentlicht, darunter Administrator-Schlüssel für staatliche Cloud-Server und Klartext-Passwörter. Die Offenlegung blieb mehr als sechs Monate aktiv, obwohl das Scansystem GitGuardian neun automatische Warnmeldungen verschickte, und endete erst nach dem direkten Eingreifen des Investigativjournalisten Brian Krebs. Der Vorfall veranschaulicht auf emblematische Weise, wie selbst die Vorzeigeorganisation für Cybersicherheit über unzureichende interne Prozesse stolpern kann, auch wenn keine tatsächliche Kompromittierung stattfand.

Technische Analyse

Das inkriminierte Repository – bezeichnenderweise „Private CISA“ getauft – enthielt ungeschützte interne Dateien mit einer Gesamtgröße von 844 MB. Im Einzelnen fanden sich:

• Administrator-Zugangsdaten für drei AWS-GovCloud-Server, die Cloud-Plattform für Arbeitslasten der US-Regierung;
• eine CSV-Datei mit Dutzenden von Benutzernamen und Klartext-Passwörtern für interne CISA-Systeme.

GitGuardian, der von der Behörde genutzte Dienst zur automatischen Überwachung von Geheimnissen, hatte das Leck entdeckt und im Laufe des Halbjahres neun Benachrichtigungen gesendet. Diese landeten jedoch in einem ungeeigneten Meldekanal, der vermutlich mit Prozessen für Produktschwachstellen verknüpft war, und blieben unbeantwortet. Die Situation wurde erst im Mai 2026 entschärft, als Brian Krebs (KrebsOnSecurity) – nach Analyse des Repositories – persönlich die CISA-Führungsebene kontaktierte.

Die Eindämmungsphase dauerte nach der Benachrichtigung über 48 Stunden – eine ungewöhnlich lange Zeit, die durch das notwendige sichere Rotieren aller kompromittierten Schlüssel und die Handhabung der zahlreichen Verflechtungen mit Bundes- und Industriepartnern, die dieselben Zugangsdaten verwendeten, bedingt war. Die anschließende Untersuchung, gestützt auf umfangreiche Log-Daten und eine bereits operative Zero‑Trust-Architektur, konnte jeden nicht autorisierten externen Zugriff ausschließen und bestätigen, dass keine Missions- oder Kundendaten kompromittiert worden waren.

Auswirkungen

Obwohl kein unmittelbarer materieller Schaden entstand, wurde das potenzielle Risiko als „hoch“ eingestuft: Administrative Schlüssel für Regierungsumgebungen hätten ausgenutzt werden können, um sich lateral innerhalb der Bundesinfrastruktur zu bewegen oder sensible Daten zu exfiltrieren.

Die unmittelbarste Auswirkung war reputativer Natur. Die Agentur, die die Leitlinien für den nationalen Cyberschutz verfasst, offenbarte grundlegende Schwachstellen – Klartext-Passwörter in einem öffentlichen Repo – und, noch schwerwiegender, das Fehlen eines wirksamen Kanals für Meldungen zur eigenen internen Sicherheit. Die außerplanmäßige Rotation der Zugangsdaten verursachte zudem eine erhebliche operative Verlangsamung, was Ressourcenverbrauch und Arbeitsstunden zur Wiederherstellung des vollen Betriebs nach sich zog.

Mitigation

CISA veröffentlichte eine transparente Post‑mortem-Analyse und formulierte mehrere Empfehlungen, die weit über den behördlichen Bereich hinaus anwendbar sind:

• Kontinuierliche und integrierte Überwachung: Systeme zur Erkennung von Geheimnissen (wie GitGuardian) müssen Warnmeldungen direkt in die Incident-Response-Prozesse einspeisen, mit Metriken für Annahme und sofortige Reaktion.
• Getrennte und sichtbare Meldekanäle: Es muss klar zwischen Kontaktstellen für Produktschwachstellen und solchen für interne Vorfälle unterschieden werden. Die Informationen sind auf security.txt, in Unternehmensportalen und auf jeder öffentlichen Schnittstelle zu veröffentlichen, mit Prozessen, die Fehlleitungen unterbinden.
• Schnelle und automatisierte Schlüsselrotation: Pläne für Widerruf und Erneuerung von Zugangsdaten müssen regelmäßig getestet werden und Szenarien mit externen Partnern einbeziehen, um Reaktionszeiten zu verkürzen.
• Dedizierte Playbooks: Spezifische Verfahren für das Leaken von Zugangsdaten auf Plattformen wie GitHub definieren und in das Incident-Management-System integrieren.
• Zero‑Trust und erweitertes Logging: Die Zero-Trust-Architektur hat ihre Wirksamkeit bei der Eindämmung des Vorfalls bewiesen. Die Ausweitung der Aktivitätsprotokollierung und die Anwendung des Prinzips der minimalen Rechte bleiben eine entscheidende Verteidigung.
• Verbindliche Schulungen für Contractor: Externe Mitarbeiter müssen vertraglich zum Schutz von Geheimnissen verpflichtet und in Richtlinien zur Code-Veröffentlichung geschult werden, mit automatischen Prüfungen vor jedem Public Commit.

FAQ

1. Wie wurde der Vorfall entdeckt, obwohl GitGuardian bereits mehrere Warnmeldungen verschickt hatte?
Obwohl GitGuardian innerhalb von sechs Monaten neun Benachrichtigungen generierte, wurden diese nicht bearbeitet, weil sie in einen Kanal gelangten, der für Produktschwachstellen gedacht war, nicht für interne Vorfälle. Die tatsächliche Wahrnehmung erfolgte erst, als Journalist Brian Krebs das Repository manuell an die CISA-Führung meldete.

2. Gab es unbefugte Zugriffe auf die AWS-GovCloud-Server oder andere CISA-Systeme?
Den Untersuchungen zufolge, die durch Log-Daten und Zero‑Trust-Kontrollen gestützt wurden, wurde kein unbefugter externer Zugriff festgestellt. Missions- und Kundendaten blieben unangetastet. Allerdings hätte das sechsmonatige Zeitfenster einem Angreifer ermöglichen können, sich unbemerkt zu bewegen, wenn keine Eindämmungsmaßnahmen bestanden hätten.

3. Was wird sich bei der CISA nach diesem Vorfall ändern?
Die Behörde hat das System zur Entgegennahme externer Meldungen grundlegend überarbeitet und die Ströme für Produktschwachstellen von jenen für interne Notfälle getrennt. Zudem verstärkte sie die Richtlinien zur automatischen Überwachung, führte spezifische Playbooks für GitHub ein und machte strengere Schulungen für Contractor verpflichtend, um die versehentliche Veröffentlichung sensibler Daten zu verhindern.