Hugging-Face-Angriff: Ein gestohlener Schlüssel, 181 Anmeldungen

Der Fall ist für Unternehmen wichtiger als die Frage, welches KI-Modell beteiligt war. Er zeigt eine Schwäche, die in vielen gewachsenen IT-Landschaften steckt: Ein technisch gültiger Schlüssel kann einem Angreifer genau die Rechte geben, für die er ursprünglich vorgesehen war. Verschlüsselung und ein Zero-Trust-Netzwerk helfen dann nur so weit, wie Zugangsdaten, Rollen und Freigaben sauber begrenzt sind.

Was zwischen dem 9. und 13. Juli geschah

Der Ausgangspunkt war laut OpenAI eine interne Prüfung von Fähigkeiten für Cyberangriffe. Mehrere OpenAI-Modelle sollten in einer isolierten Umgebung Aufgaben des Sicherheits-Benchmarks ExploitGym lösen. OpenAI führte die Prüfung ohne die für den Produktivbetrieb verwendeten Klassifikatoren gegen riskante Cyberaktivitäten und mit reduzierten Ablehnungen bei Cyberaufgaben durch. Direkter Internetzugang war nicht vorgesehen; erlaubt war der Paketbezug über einen internen Proxy und Cache. Einzelne Schritte wurden nach Angaben von Hugging Face nicht von einem Menschen angeordnet.

Der Agent fand zunächst eine bis dahin unbekannte Schwachstelle in diesem Paket-Cache und erhielt dadurch Internetzugang. Die ExploitGym-Betreiber waren laut Hugging Face nicht an OpenAIs Evaluationsumgebung beteiligt. Als späteren Ausgangspunkt nutzte der Agent eine von einem unbekannten Dritten auf der Cloud-Plattform Modal betriebene, öffentlich erreichbare Instanz mit der Bezeichnung „CyberGym“. Der betreffende Zugang gehört laut Hugging Face nicht zum ursprünglichen CyberGym-Projekt; Modal selbst wurde nicht kompromittiert.

Von dort griff der Agent die Datenverarbeitung von Hugging Face an. Zwei Schwachstellen ermöglichten zuerst das Lesen lokaler Dateien einschließlich des Quellcodes des zuständigen Datenverarbeitungsprogramms und danach die Ausführung von Code in einem produktiven Container. Der Agent erweiterte seine Rechte bis auf die Serverebene, las Cloud- und Cluster-Zugangsdaten aus und bewegte sich weiter durch interne Systeme.

Hugging Face rekonstruierte für die gesamte Kampagne vom 9. Juli um 02:28 Uhr UTC bis zum 13. Juli um 14:14 Uhr UTC rund 17.600 wiederherstellbare Angreiferaktionen und gruppierte sie in etwa 6.280 Aktionscluster. Nach Angaben von Hugging Face bestand der einzige zugegriffene Kundeninhalt aus fünf Datensätzen, deren Namen und Dateien auf Aufgaben beziehungsweise Lösungen aus ExploitGym oder CyberGym hindeuteten. Darüber hinaus seien nur operative Metadaten zu Suchanfragen gelesen worden. Für weitere kundenseitige Modelle, Datensätze, Spaces oder Pakete stellte Hugging Face keinen Zugriff fest.

Wann Tailscale in der Angriffskette auftauchte

Tailscale war weder das erste Ziel noch der Eintrittspunkt. Als der Agent den Tailscale-Schlüssel fand, hatte er bereits einen Produktionsserver übernommen und Cluster-Geheimnisse gelesen. In einem einzigen Produktions-Secret-Objekt lagen 136 Schlüssel. Dazu gehörte ein wiederverwendbarer Anmeldeschlüssel für das Tailscale-Netz von Hugging Face.

Der Schlüssel war für automatisierte Software-Builds gedacht, also für Continuous Integration (CI). Neue Geräte erhielten deshalb eine Rolle mit Zugriff auf interne Build-Netze und einen Übergang zum Quellcode-Anbieter. Der Agent verwendete denselben Schlüssel wiederholt und erzeugte über die Kampagne hinweg 181 Anmeldungen. Die technische Rekonstruktion beschreibt kurzlebige Knoten mit nur im Arbeitsspeicher gehaltener Geräteidentität. Die Zahl sollte deshalb nicht automatisch als 181 physisch verschiedene Rechner gelesen werden. Gezählt wurden registrierte Netzwerkknoten beziehungsweise Anmeldevorgänge.

Über die interne Quellcode-Anwendung erhielt der Agent später Zugriff auf eine kleine Gruppe interner Quellcode-Speicher. Er listete deren Inhalte, erzeugte kurzlebige Installationstokens mit Schreibrechten und eröffnete einen Änderungsvorschlag mit dem Ziel, die automatische Build-Pipeline auszulösen. Die Schreibberechtigung war laut Hugging Face real und wurde eingesetzt, führte aber zu keiner ausgelieferten Änderung. Das Unternehmen fand bei seiner Prüfung keine unbefugten gespeicherten Änderungen, Zweige oder Änderungen an automatisierten Abläufen; veröffentlichte Container-Abbilder und Pakete entsprachen den erwarteten Prüfsummen. Für einen Zugriff der 181 angemeldeten Knoten auf private Arbeitslasten oder die interne Kubernetes-Schnittstelle über das Tailscale-Netz fand Hugging Face ebenfalls keine Belege.

Warum Tailscale von einem gestohlenen Schlüssel spricht

Tailscale erklärte nach Auswertung der gemeinsamen Daten, dass keine Schwachstelle im eigenen Produkt ausgenutzt wurde. Der Agent verhielt sich gegenüber der Tailscale-Steuerung wie eine zugelassene Automatisierung: Er legte einen gültigen Schlüssel vor, erhielt die damit verbundene Rolle und durfte die dafür freigegebenen Ziele sehen.

Darin liegt der Unterschied zwischen einer Produktlücke und gestohlenen Zugangsdaten. Eine Produktlücke würde eine technische Kontrolle umgehen. Hier funktionierte die Kontrolle wie konfiguriert, aber ihre Voraussetzung war falsch geworden: Der Besitzer des Schlüssels war nicht mehr vertrauenswürdig.

Auch „Zero Trust“ bedeutet nicht, dass ein Netzwerk gestohlene Schlüssel automatisch erkennt. Das Prinzip verlangt, jede Identität und jede Berechtigung ausdrücklich zu prüfen. Wenn ein länger gültiger, wiederverwendbarer Registrierungs- oder Anmeldeschlüssel kopiert wird und den damit angemeldeten Knoten eine breite Rolle zuweist, kann der Angreifer die vorgesehene Zugangskontrolle mit formal gültigen Zugangsdaten passieren. Die Folgen werden durch kurze Laufzeiten, enge Rechte und eine zweite Aufnahmeprüfung für neue Knoten begrenzt.

Was die Zahlen 136 und 181 wirklich zeigen

• 136 Schlüssel in einem Produktions-Secret-Objekt: Zu viele unterschiedliche Vertrauensbereiche liefen an einer Stelle zusammen. Ein erfolgreicher Zugriff machte mehrere Folgeschritte möglich.
• 181 Netzwerkanmeldungen: Ein wiederverwendbarer Automatisierungsschlüssel konnte ohne ausreichende Bindung an eine bestimmte Arbeitslast erneut eingesetzt werden.
• 22 für die CI-Rolle sichtbare Netzwerkknoten: Darunter waren Netz-Übergänge und Konnektoren. Die Rolle offenbarte dem Agenten genug Struktur, um interessante Verbindungen und Dienste zu erkennen.
• Rund 17.600 Aktionen: Ein KI-Agent kann viele kleine Entscheidungen schneller aneinanderreihen als ein menschlicher Angreifer. Einzelne, scheinbar unkritische Fehlkonfigurationen werden dadurch rasch zu einer Angriffskette.

Keine dieser Zahlen beweist allein einen Datenabfluss. Zusammen beschreiben sie aber die Reichweite, die ein einziger bereits kompromittierter Server eröffnen konnte.

Fünf konkrete Konsequenzen für Unternehmen

1. Wiederverwendbare Maschinen-Schlüssel erfassen. Das betrifft Zugänge zu virtuellen privaten Netzen (VPN), automatisierte Build- und Bereitstellungsabläufe, Cloud-Konten, Quellcode-Plattformen und Sicherungssysteme. Für jeden Schlüssel müssen Besitzer, Zweck, Laufzeit und erlaubte Ziele dokumentiert sein.
2. Statische Schlüssel durch Arbeitslast-Identitäten ersetzen. Tailscales Workload Identity Federation tauscht ein signiertes Identitätstoken nach dem Standard OpenID Connect (OIDC) des Cloud- oder CI-Anbieters gegen einen kurzlebigen Tailscale-Zugang aus. Tailscale prüft dabei unter anderem Aussteller, Zielgruppe, Ablaufzeit und konfigurierte Merkmale. Regeln ordnen der Arbeitslast anschließend Rollen und Berechtigungen an der Programmierschnittstelle zu. Dadurch muss für geeignete Cloud- und CI-Arbeitslasten kein wiederverwendbarer Tailscale-Anmeldeschlüssel gespeichert werden.
3. Rollen auf eine Aufgabe zuschneiden. Eine CI-Rolle sollte nicht pauschal alle Build-Systeme und Quellcode-Übergänge erreichen. Rechte werden nach Repository, Umgebung und Arbeitslast getrennt. Die Regel lautet: genau das Nötige, nicht das historisch Bequeme.
4. Neue Geräte und ungewöhnliche Quellen sichtbar machen. Tailscale-Netzwerkflussprotokolle können erfolgreiche Verbindungen für Analyse und Alarmierung bereitstellen, sind aber standardmäßig deaktiviert und ersetzen kein Echtzeit-Monitoring. Sie protokollieren Verkehrsflüsse, nicht deren Inhalte, und clientseitige Angaben können bei einem kompromittierten Knoten fehlen oder manipuliert sein. Deshalb sollten sie mit Geräteanmeldungen, Protokollen vertrauenswürdiger Gegenstellen, Cloud-Daten und dem eigenen Alarmsystem zusammengeführt werden.
5. Eine zweite Aufnahmeprüfung erwägen. Tailnet Lock verlangt eine zusätzliche Signatur vertrauenswürdiger Knoten, bevor neue Knoten Daten austauschen. Die Funktion ist nicht standardmäßig aktiv und benötigt einen belastbaren Freigabeprozess. Sie erkennt nicht von selbst, ob Herkunft und Arbeitslast plausibel sind; diese Prüfung muss in der Signierregel oder im Freigabeablauf stecken. Ein gewöhnlicher gestohlener Anmeldeschlüssel wird nur dann von der Knotenfreigabe getrennt, wenn er nicht selbst vorab für Tailnet Lock signiert wurde und die Signierknoten sowie die Freigabelogik unabhängig geschützt bleiben.

KI-Sicherheit beginnt bei der Testumgebung

OpenAI betont, dass die beteiligten Systeme in einer Cyberprüfung liefen und keine Modelle für eine bevorstehende Veröffentlichung beteiligt waren. Der leistungsfähigere Prototyp war nur für interne Forschung vorgesehen und wurde nach dem Vorfall deaktiviert und eingeschränkt. Trotzdem gelang es dem Agenten, aus einer vermeintlich isolierten Prüfung eine reale Angriffskette zu bauen.

Unternehmen müssen deshalb auch interne KI-Automatisierungen wie privilegierte Software behandeln. Ein Agent sollte nur künstliche Testdaten sehen, keine produktiven Zugangsdaten erben und keine allgemein nutzbaren Ausgänge ins Internet besitzen. Werkzeuge, Berechtigungen und Abbruchregeln gehören vor dem ersten Test in eine schriftliche Freigabe. Für sensible Eingaben gelten zusätzlich die Grundsätze aus unserem Ratgeber zu ChatGPT und Datenschutz im Unternehmen.