CISA-Administrator leakte AWS-GovCloud-Schlüssel auf GitHub

• Ein von einem CISA-Vertragspartner betriebendes öffentliches Private-CISA-Repository legte hochprivilegierte AWS-GovCloud-Konten und Zugangsdaten für interne Systeme offen
• Auf dem GitHub-Konto fanden sich Spuren dafür, dass Standardeinstellungen zum Verhindern der Veröffentlichung von Geheimnissen deaktiviert wurden, sowie Klartext-Passwörter, Tokens und Logs
• Die offengelegte Datei importantAWStokens enthielt Administrator-Zugangsdaten für drei AWS-GovCloud-Server, eine CSV-Datei enthielt Anmeldedaten für interne Systeme
• Seralys sah, dass sich mit den offengelegten Schlüsseln mit hohen Berechtigungen authentifizieren ließ und dass interner artifactory-Zugriff das Risiko von Package-Backdoors und lateraler Bewegung erhöht
• Kurz nach der Benachrichtigung von CISA ging das Konto offline, doch die AWS-Schlüssel blieben weitere 48 Stunden gültig; CISA erklärte, es gebe keine Hinweise auf eine Kompromittierung

---

In einem öffentlichen GitHub-Repository offengelegte interne CISA-Zugangsdaten

• Ein öffentliches GitHub-Repository, das von einem CISA-Vertragspartner betrieben wurde, legte mehrere hochprivilegierte AWS GovCloud-Konten sowie Zugangsdaten für interne CISA-Systeme offen
• Das Repository hieß Private-CISA und enthielt sogar Dateien dazu, wie CISA intern Software baut, testet und bereitstellt
• Das Repository enthielt in großem Umfang Cloud-Schlüssel, Tokens, Klartext-Passwörter, Logs und weitere sensible CISA-Ressourcen
• Guillaume Valadon von GitGuardian entdeckte das Repository, als er kontinuierlich öffentliche Code-Repositories auf offengelegte Geheimnisse scannte und Kontoinhaber automatisch benachrichtigte
• Valadon erklärte, der Eigentümer des Repositories habe nicht reagiert und die offengelegten Informationen seien so sensibel gewesen, dass er KrebsOnSecurity kontaktierte

Deaktivierte GitHub-Geheimniserkennung und zentrale offengelegte Dateien

• Valadon sieht in der Offenlegung der CISA-Zugangsdaten ein typisches Beispiel für mangelhafte Sicherheitshygiene
• In den Commit-Logs des betreffenden GitHub-Kontos fanden sich Spuren dafür, dass ein CISA-Administrator GitHub-Standardeinstellungen deaktiviert hatte, die verhindern sollen, dass SSH-Schlüssel oder andere Geheimnisse in öffentlichen Code-Repositories veröffentlicht werden
• Valadon sagte, es habe „Passwörter, die im CSV im Klartext gespeichert waren, Backups in Git und explizite Befehle zum Deaktivieren der GitHub-Geheimniserkennungsfunktion“ gegeben
• Die offengelegte Datei importantAWStokens enthielt Administrator-Zugangsdaten für drei Amazon-AWS-GovCloud-Server
• Eine weitere Datei, AWS-Workspace-Firefox-Passwords.csv, enthielt Klartext-Benutzernamen und -Passwörter für Dutzende interne CISA-Systeme
• Laut Philippe Caturegli gehörte dazu auch LZ-DSO, offenbar die Abkürzung für „Landing Zone DevSecOps“, die sichere Code-Entwicklungsumgebung der Behörde

Hohe Berechtigungen und Risiken durch Zugriff auf interne Systeme

• Philippe Caturegli, Gründer des Sicherheitsberatungsunternehmens Seralys, sagte, er habe nur geprüft, ob die AWS-Schlüssel noch gültig seien und auf welche internen Systeme die offengelegten Konten zugreifen könnten
• Caturegli verifizierte, dass sich mit den offengelegten Zugangsdaten auf drei AWS-GovCloud-Konten mit hohen Berechtigungsstufen authentifizieren ließ
• Das Archiv enthielt auch Klartext-Zugangsdaten für das interne artifactory von CISA
• Dieses artifactory ist ein Repository für Code-Pakete, das CISA beim Bau von Software verwendet, und könnte für Angreifer ein attraktives Ziel sein, wenn sie eine dauerhafte Präsenz in CISA-Systemen etablieren wollen
• Caturegli zufolge eignet sich diese Stelle sehr gut für laterale Bewegung, und wenn man Software-Pakete mit Backdoors versieht, könnten diese Backdoors anschließend mit jeder neu gebauten Software verteilt werden

Nutzung des Repositories und verantwortliche Stelle

• Caturegli zufolge ähnelte dieses GitHub-Konto eher einem Arbeitsnotizbuch oder einem Synchronisationsmittel für eine einzelne Person als einem aufgeräumten Projekt-Repository
• Es wurden sowohl mit CISA verknüpfte E-Mail-Adressen als auch persönliche E-Mail-Adressen verwendet, was darauf hindeutet, dass das Repository möglicherweise in unterschiedlich konfigurierten Umgebungen genutzt wurde
• Caturegli erklärte, allein anhand der verfügbaren Git-Metadaten lasse sich nicht belegen, welche Endpunkte oder Geräte verwendet wurden
• Eine Prüfung des GitHub-Kontos und der offengelegten Passwörter ergab, dass das Private-CISA-Repository von einem Mitarbeiter des Regierungsauftragnehmers Nightwing in Dulles, Virginia, verwaltet wurde
• Nightwing lehnte eine Stellungnahme ab und verwies Anfragen an CISA

Reaktion von CISA und Dauer der Offenlegung

• Ein CISA-Sprecher erklärte, die Behörde sei über die gemeldete Offenlegung informiert und untersuche die Situation weiter
• CISA teilte mit, es gebe derzeit keine Hinweise darauf, dass durch diesen Vorfall sensible Daten kompromittiert worden seien
• CISA erklärte außerdem, dass von Teammitgliedern ein hohes Maß an Integrität und operativem Bewusstsein verlangt werde und zusätzliche Schutzmaßnahmen zur Verhinderung eines erneuten Vorfalls vorbereitet würden
• Auf Fragen zur möglichen Dauer der Datenoffenlegung antwortete CISA nicht
• Laut Caturegli wurde das Private-CISA-Repository am 13. November 2025 erstellt, das GitHub-Konto des betreffenden Vertragspartners entstand im September 2018
• Kurz nachdem KrebsOnSecurity und Seralys CISA über die Offenlegung informiert hatten, ging das GitHub-Konto mit dem Repository Private-CISA offline
• Caturegli erklärte, die offengelegten AWS-Schlüssel seien danach auf schwer erklärbare Weise noch weitere 48 Stunden gültig geblieben

Leicht zu erratende Passwörter und Risiko einer Ausweitung eines Einbruchs

• Im inzwischen geschlossenen Private-CISA-Repository fanden sich auch Spuren davon, dass für mehrere interne Ressourcen leicht zu erratende Passwörter verwendet wurden
• Viele Zugangsdaten nutzten Passwörter in der Form des jeweiligen Plattformnamens gefolgt vom aktuellen Jahr
• Caturegli sieht in einer solchen Praxis selbst dann eine ernste Sicherheitsbedrohung für jede Organisation, wenn sie nicht nach außen offengelegt wird
• Angreifer erweitern ihren Zugriff häufig, nachdem sie einen ersten Zugang zu einem Zielsystem erlangt haben, indem sie zentrale Zugangsdaten nutzen, die im internen Netzwerk offengelegt sind
• Caturegli vermutet, dass der CISA-Vertragspartner GitHub genutzt haben könnte, um Dateien zwischen einem Arbeitslaptop und einem Heimcomputer zu synchronisieren, da seit November 2025 regelmäßig Commits in dieses Repository erfolgt seien
• Caturegli zufolge ist dies für jedes Unternehmen ein peinliches Leak, in diesem Fall aber besonders problematisch, weil es sich um CISA handelt

Organisatorischer Hintergrund

• CISA arbeitet derzeit nur mit einem Teil des regulären Budgets und Personalbestands
• Seit dem Beginn der zweiten Trump-Regierung hat CISA nahezu ein Drittel seiner Belegschaft verloren
• Dieser Personalabbau wird damit erklärt, dass in mehreren Bereichen der Behörde Frühverrentungen, buyouts und Kündigungen erzwungen wurden
• Verwandter Bericht: CISA has lost nearly a third of its workforce

[GN⁺]

Hacker-News-Kommentare

• Der Grund, warum Valadon Kontakt aufnahm, war wohl, dass der Eigentümer nicht reagierte und die offengelegten Informationen äußerst sensibel waren; dass ein CISA-Auftragnehmer Zugangsdaten geleakt hat, ist schon absurd, aber nach der Benachrichtigung nicht zu reagieren, ist noch gravierender
  Außerdem soll AWS-Workspace-Firefox-Passwords.csv Benutzernamen und Passwörter im Klartext für Dutzende interne CISA-Systeme enthalten haben
  Ich verstehe und bedaure, dass CISA zusammengestrichen wird, aber eine passwords.csv mit schwachen Passwörtern ist unentschuldbare Inkompetenz, und ein Passwort-Manager erfordert kein großes Budget

  • Der gesuchte Ausdruck ist grobe Fahrlässigkeit
  • Ich will diese Person nicht verteidigen, aber es gibt deutliche Anzeichen dafür, dass GitHub wie ein Dateisynchronisierungstool benutzt wurde
    Firefox-passwords.html und firefox-bookmarks.html waren Dateien, die man exportiert und wieder importiert hat, bevor man auf einen neuen Computer umgezogen ist; das war die alte Methode aus der Zeit vor Firefox Sync
    Das steht auch im Artikel, aber es sticht genug hervor, um es eigens zu erwähnen
  • Auf der einen Seite wird CISA verkleinert, auf der anderen Seite wächst die Rhetorik über Cybersicherheit, nationale Interessen und kritische Infrastruktur immer weiter
  • Die meisten Bekannten, die ich bei CISA hatte, wurden während der DOGE-Kampagne von Januar bis März 2025 entlassen
    Ohne Vorwarnung nach dem Motto: „Wir sind in unseren Zwanzigern und wissen nicht, was du machst, also bist du gefeuert“
    Das Team, das sich mit Sicherheitslücken in Diebold-Wahlsystemen und dem Hacken ausländischer Implantate befasste, ist ebenfalls verschwunden
  • Das erste „Hacking“, das ich jemals gemeldet habe, war das Finden einer Klartext-Passwortdatei in einem Computernetzwerk meiner Highschool, und das war 1987
    Manche Dinge ändern sich nie

• Eines der Dinge, die meiner Meinung nach unterschätzt werden, ist, wie viele Geheimnisse an OpenAI, Anthropic und OpenRouter gesendet werden, wenn man .env-Dateien oder Secrets auf der Festplatte im Repository hat, auch wenn sie nicht committed wurden
  Ein LLM liest bereitwillig ganze Dateien und könnte sie anschließend ohne jede Warnung in die Trainingsdaten von ChatGPT übernehmen
  Denn zu prüfen, ob Umgebungsvariablen gesetzt sind oder ob das Datenbankpasswort der App bereitliegt, sieht oberflächlich wie normale Arbeit aus
  Organisationen müssen nun Secrets, die auf Datenträgern oder in Logs gespeichert sind, auditieren und rotieren und sie mit Tools wie SOPS oder Vault so verlagern, dass sie nur bei Bedarf im Klartext vorliegen

  • Dieses Problem ist viel stärker unterbewertet, als die meisten denken
    Der Leak-Pfad ist meist nicht „jemand hat ein Secret committed“, sondern eher: „ein Agent hat beim Antworten .env gelesen und die Werte ungekürzt in die Analyse übernommen, und dieser Prompt mitsamt Completion landete in Trainingsdaten oder einem Cache-Treffer für jemand anderen“
    In Projekten mit echten Secrets haben wir .env, credentials/ und .pem in .aiignore oder .claudeignore aufgenommen, in projektspezifische Instruktionsdateien geschrieben, dass .env-Dateien auch auf Anfrage nicht gelesen werden dürfen, und Secrets nicht auf der Festplatte, sondern in 1Password oder dem Keychain abgelegt, um sie beim Start des Prozesses als Umgebungsvariablen zu injizieren
    Das größere Problem ist, dass „respektiere .gitignore“ die falsche Abstraktion ist
    In privaten Repositories gibt es viele Dateien, die man committen darf, die aber nicht an eine LLM-API fließen sollten, und diese beiden Mengen sind nicht identisch
  • Fairerweise sollten in einer .env-Datei im Development-Tree keine hochkritischen Secrets liegen
    Es sollten Entwicklungs-Secrets mit begrenzten Rechten sein, und selbst Werte, die auf „Produktions“-Systeme zeigen, wie in einer OpenAI-Entwicklungsumgebung, sollten nach Möglichkeit eingeschränkte Berechtigungen haben
    Es geht nicht nur um Leaks; bei Tests und in der Entwicklung kann man auch leicht versehentlich ein Denial of Service auslösen oder falsche Requests an ein System schicken
    Man will vermeiden, dass jemand an Testautomatisierung arbeitet und aus Versehen Tausende echte Ergebnisse verschickt und dann eine 1.000-Dollar-Rechnung bekommt
  • Stimme zu. Langfristige statische Zugangsdaten sind das eigentliche Problem
    Dass AWS und andere große Cloud-Anbieter Werkzeuge bauen, um davon wegzukommen, und dafür sanfte oder auch recht deutliche Anreize setzen, ist lobenswert
    Aber noch nicht alle sind auf dem nötigen Stand
    Railway etwa ermöglicht keinen Zugriff auf AWS-Ressourcen über Rollen/OIDC; ich habe dafür ein Ticket eröffnet, aber bisher keine Bewegung gesehen
    0: https://station.railway.com/feedback/allow-for-integration-w...
  • Ich lasse dotenv-Dateien nicht mehr im Klartext liegen
    Ich halte mit sops verschlüsselte Umgebungsdateien vor und nutze Tools wie direnv, damit sie in der Shell während der Arbeit verfügbar sind
    Natürlich kann ein LLM diese Secrets trotzdem ausgeben, aber die Wahrscheinlichkeit sinkt
    Außerdem versucht zumindest Claude eher, das Lesen von dotenv zu vermeiden, und letztlich sollten lokale Secrets selbst nicht so wichtig sein
    Man sollte begrenzte Scopes, Entwicklungsaccounts usw. verwenden
  • Kürzlich habe ich gesehen, dass zumindest Claude sich ziemlich bemüht, Umgebungsdateien nicht zu lesen
    Wenn man etwa möchte, dass es eine Datenbank liest und darauf zugreift, muss man im Prompt ziemlich stark darauf drängen

• Wenn 2026 Regierungszugangsdaten in einem Repository liegen und es nicht einmal Scanner gibt, die das erkennen, sollte das untersucht werden
  Jemanden, der so etwas beruflich macht, würde ich äußerst misstrauisch betrachten
  Wenn ein ausländischer Geheimdienst das gesehen hätte, hätte er vermutlich zuerst an einen Honeypot gedacht; es wäre so offensichtlich gewesen, dass es wie eine fantasielose Falle gewirkt hätte

  • Gut, dass die Regierung alle kompetenten Leute entlassen hat
  • Wir wissen bereits, dass DOGE versucht hat, US-Regierungsdaten abzugreifen, etwa die gesamte Belegschaft der US-Regierung oder sämtliche Sozialversicherungsnummern
    Unter einer früheren Regierung hätte ich gedacht, CISA fahre eine Köderoperation, aber wenn man die Korruption und Inkompetenz dieser Regierung sowie die Massenentlassungen bei CISA bedenkt, könnte es auch einfach ein echter Fehler gewesen sein

• Sensible Dokumente wurden auch in ChatGPT hochgeladen [1]
  [1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...

  • Wenn man diesen Artikel liest, wirkt es, als hätten Trump/Noem die Positionen mit ausländischen Spionen besetzt
    Irgendwann wird der Tag kommen, an dem das amerikanische Volk sie zur Rechenschaft zieht

• Ironischerweise hätte man mit diesem AWS-Schlüssel mehrere sicherere AWS-Services nutzen können
  Zum Beispiel S3, nach Möglichkeit S3 mit KMS, Parameter Store, EBS, EFS, AWS Secrets Manager oder einfach Dateien direkt mit KMS verschlüsseln
  Eigentlich geht jeder AWS-Service, der KMS unterstützt und bei dem man dem Service Principal keinen Schlüsselzugriff geben muss

• Erstaunlich ist, dass das 6 bis 7 Monate lang so weiterlief
  Ich hätte erwartet, dass Firmen wie GitGuardian oder einzelne Forscher mit trufflehog geleakte Schlüssel innerhalb weniger Tage finden
  Vielleicht ist GitHub inzwischen so stark gewachsen, dass die Scanner nicht mehr mithalten

• Der Repository-Name war buchstäblich Private-CISA
  Es wäre interessant, nach Repository-Namen mit Wörtern wie private oder internal zu suchen und nach Namen von Regierungsbehörden oder nichttechnischen Unternehmen, die man normalerweise nicht in Repository-Namen erwarten würde
  Man könnte sie alle klonen und dann ein LLM schnell nach interessantem Material durchsuchen lassen
  Aber hat GitHub nicht automatische Scanner für grundlegende Dinge wie AWS-Zugangsdaten?

  • Nur wenn sie aktiviert sind. Laut Artikel hatte dieser Nutzer die Funktion deaktiviert

• Das wirklich Traurige ist, dass die Bundesregierung seit Jahrzehnten mit CAC bereits Smartcard-basierte Authentifizierung hatte
  Aber weil der öffentliche Internet-Stack auf Passwörtern läuft, verwendet am Ende auch die Regierungsinfrastruktur Passwörter