Offenlegung eines Secret-Lecks auf der Hugging Face Spaces-Plattform

• Anfang dieser Woche wurde auf der Spaces-Plattform ein unbefugter Zugriff im Zusammenhang mit Secrets festgestellt, und es besteht die Möglichkeit, dass auf einige Secrets von außen zugegriffen wurde
• Als erste Reaktionsmaßnahme wurden mehrere in Secrets enthaltene HF-Tokens widerrufen, und betroffene Nutzer wurden per E-Mail informiert
• Nutzern wird empfohlen, die betroffenen Keys und Tokens neu auszustellen und auf die nun standardmäßigen fine-grained access tokens umzusteigen
• Hugging Face untersucht den Vorfall gemeinsam mit externen Cybersecurity-Forensik-Experten und überprüft zugleich seine Sicherheitsrichtlinien und -verfahren
• Für die Spaces-Infrastruktur wurden org tokens entfernt, KMS eingeführt und die Erkennung sowie Ungültigmachung kompromittierter Tokens verstärkt; außerdem wurde der Vorfall den zuständigen Behörden gemeldet

---

Unbefugter Zugriff auf Spaces-Secrets und Maßnahmen für Nutzer

• Hugging Face hat auf der Spaces-Plattform einen unbefugten Zugriff im Zusammenhang mit Spaces secrets festgestellt
• Es besteht die Möglichkeit, dass auf einige Spaces secrets unbefugt zugegriffen wurde
• Im Zuge der ersten Wiederherstellungsmaßnahmen wurden mehrere in Secrets enthaltene HF tokens widerrufen
  • Nutzer, deren Tokens widerrufen wurden, wurden bereits per E-Mail informiert
• Nutzern wird empfohlen, ihre Keys oder Tokens neu auszustellen
• Für HF tokens wird der Umstieg auf die neue Standardeinstellung fine-grained access tokens empfohlen

Verstärkte Sicherheit der Spaces-Infrastruktur und weitere Maßnahmen

• Hugging Face untersucht den Vorfall gemeinsam mit externen Cybersecurity-Forensik-Experten und überprüft seine Sicherheitsrichtlinien und -verfahren
• In den vergangenen Tagen wurde die Sicherheit der Spaces-Infrastruktur verstärkt
  • org tokens wurden vollständig entfernt, um Nachvollziehbarkeit und Audit-Funktionen zu verbessern
  • Für Spaces secrets wurde ein Key Management Service (KMS) eingeführt
  • Die Systemfähigkeit zur Identifizierung und proaktiven Ungültigmachung kompromittierter Tokens wurde verstärkt und erweitert
  • Die allgemeine Sicherheit wurde verbessert
• Sobald fine-grained access tokens funktionale Gleichwertigkeit erreicht haben, ist geplant, die „classic“ read/write tokens in naher Zukunft vollständig abzuschaffen
• Die Untersuchung möglicher damit zusammenhängender Vorfälle dauert an
• Hugging Face hat diesen Vorfall außerdem den Strafverfolgungsbehörden und Datenschutzaufsichtsbehörden gemeldet
• Anfragen werden unter [e-mail] entgegengenommen

[GN⁺]

Meinungen auf Hacker News

• Vor zwei Tagen habe ich die Folien einer Sicherheitskonferenz überflogen; Jossef Harush Kadouri zeigte dort, dass bei der Nutzung von Modellen von Orten wie Hugging Face der Modellautor beliebigen Code auf meiner Maschine ausführen kann.
  Ich weiß nicht, ob die Folien anderswo hochgeladen wurden; die Datei, die ich bekommen habe, liegt hier: https://dro.pm/c.pdf (45 MB), Folie 188.
  Damals war mir nicht klar, dass das nicht nur für den Modellautor gilt, sondern dass dasselbe auch möglich wäre, wenn Hugging Face einen Gerichtsbeschluss erhält oder gehackt wird. Erst recht, wenn der Einbruch eine Zeit lang unbemerkt bleibt¹.
  Ich bin nicht in der KI-Branche und habe solche Modelle nie selbst ausgeführt, aber ich war überrascht, wie schnell die Branche die Formate standardisiert hat. Ich dachte, eine Modelldatei bestünde aus großen Zahlenmatrizen und etwas Metadaten, aber Folien 186 und 195 zeigen, dass ein Modell im Grunde ein Python-Skript ist, das ziemlich frei tun kann, was es will; dadurch war die Standardisierung wohl einfach. Wenn man alle machen lässt, was sie wollen, umgeht man das Problem, aber das hat seinen Preis.
  ¹ Laut https://www.verizon.com/business/resources/articles/s/how-to... bemerken 20 % einen Einbruch monatelang nicht. Das hängt natürlich von der Situation und vom Verhalten des Angreifers ab.
  • Zu „Ich dachte, eine Modelldatei bestünde aus großen Zahlenmatrizen und etwas Metadaten“: ONNX[1] kommt dem im Großen und Ganzen nahe.
    Das Problem, auf das man dann sofort stößt, sind benutzerdefinierte Layer/Operatoren und deren Inferenzlogik. Man muss alles mit den unterstützten Operationen implementieren, was in der Praxis schwierig oder unmöglich sein kann; oder man muss zur Laufzeit Operator-Implementierungen bereitstellen und ist damit letztlich wieder am Ausgangspunkt.
    [1] https://onnx.ai/
  • Gibt es nicht genau deshalb das Format .safetensors, bei dem kein Code auf dem Host ausgeführt werden kann?
  • Wie andere schon angemerkt haben, hängt das vom Format ab. Ein Format, das in diesem Thread noch nicht als sichere Variante erwähnt wurde, ist GGUF, das von llama.cpp und abgeleiteten Projekten verwendet wird.
    Es ist fast ein Format aus „großen Zahlenmatrizen und etwas Metadaten“, und einige Schwachstellen wurden gefunden und gepatcht.
    [1] https://www.databricks.com/blog/ggml-gguf-file-format-vulner...
  • Soweit ich weiß, tritt dieses Problem nur auf, wenn Modelle per pickle serialisiert/deserialisiert werden[0].
    [0]: https://huggingface.co/docs/hub/en/security-pickle
  • Der dro.pm-Link wird bald ablaufen. Das ist ein temporärer Link und deshalb kurzlebig; vielleicht hätte ich einen dauerhafteren Dienst nutzen sollen.
    Für spätere Leser habe ich das Video des Vortrags gefunden: https://m.youtube.com/watch?v=8XysLIq-e3s
• Mit „sie vermuten“ anzufangen, ist eine viel zu absichernde Formulierung mit Hintertür. Für einen Satz in dieser Art von Kommunikation wirkt das unpassend.
  • Ich fand es im Gegenteil ziemlich in Ordnung. Üblicherweise sagen solche Leak-Mitteilungen so etwas wie „Es gibt keine Hinweise darauf, dass auf Secrets zugegriffen wurde“, weil man „nicht wissen kann“, was ein Hacker nach dem Eindringen getan hat.
    Hugging Face sagt immerhin sinngemäß: „Wahrscheinlich wurde auf Secrets zugegriffen, aber wir können es nicht bestätigen.“ Das wirkt ehrlicher.
• Sie sagen, sie hätten „in den letzten Tagen die Sicherheit der Spaces-Infrastruktur deutlich verbessert“, darunter vollständige Entfernung von Organisations-Tokens, bessere Nachverfolgbarkeit und Audit-Funktionen, Einführung von KMS für Spaces-Secrets, stärkere Erkennung geleakter Tokens und proaktive Deaktivierung sowie allgemeine Sicherheitsverbesserungen. Das ist ziemlich viel Arbeit, um es in „ein paar Tagen“ abzuschließen.
  Sollten solche Arbeiten vor dem Rollout in die Produktion nicht zeitaufwendigere Schritte wie Sicherheitsaudits oder Penetrationstests auslösen?
  • Hoffentlich waren das Arbeiten, die schon länger liefen, und sie haben sie jetzt ausgerollt, weil der Schaden bereits eingetreten ist.
  • Für größere Organisationen mit einer SRE-Abteilung inklusive dediziertem Sicherheitsteam stimmt das, aber mein Eindruck ist, dass Hugging Face noch nicht ganz eine Organisation dieser Größenordnung ist.
• Mein Anthropic-Key ist geleakt, und jemand hat damit eine Rechnung über 10.000 Dollar verursacht. Wird Hugging Face das erstatten?
  • Mein OpenAI-Key wurde ebenfalls geleakt, und ich habe gesehen, dass ihn jemand benutzt hat. Zum Glück war der Schaden deutlich kleiner, nur ein paar Dollar GPT-4; meine Apps nutzten dieses Modell damals nicht einmal.
    Ich bin mir ziemlich sicher, dass der Leak über die Secrets eines HF Space passiert ist. Vor ein paar Tagen habe ich eine Warnmeldung bekommen, dass einige meiner Spaces betroffen waren.
  • Bist du sicher, dass dieser Key wirklich nur in den Secrets des Space gespeichert war? Variablen sind öffentlich, und auch alles, was in einer .env-Datei gespeichert ist, ist öffentlich.
  • Ich dachte, bei Cloud-Anbieterplattformen könne man normalerweise eine Obergrenze für Ausgaben festlegen.
• Vor ein paar Wochen habe ich bemerkt, dass einige meiner OpenAI-Keys kompromittiert wurden, und diese Keys waren ausschließlich als Secrets in einem Hugging Face Space aktiviert.
  Vor ein paar Tagen bekam ich eine E-Mail, dass die betreffenden Spaces kompromittiert wurden; dieses Problem scheint also mindestens schon seit einigen Wochen zu bestehen.
• Es gibt keine Aussage dazu, wie mit unrechtmäßig entstandenen Kosten umgegangen wird. Wenn auf Secrets zugegriffen werden konnte, könnte man doch APIs aufrufen und Kosten verursachen, oder?
  Oder geht es hier rein um den Diebstahl von Daten/Code?
  • Beides ist möglich. In meinem Fall wurde der Key für OpenAI-Aufrufe verwendet, und ich bin mir ziemlich sicher, dass er aus den Spaces-Secrets geleakt wurde.
• Was ist ein „Space“?
  • Das ist die Kurzform für Spaces von Hugging Face.
    https://huggingface.co/docs/hub/en/spaces-overview
    Es scheint eine Frontend-/Portal-Seite zu sein und dürfte in Python geschrieben sein. Vielleicht etwas wie Django.
  • Eine virtuelle Maschine, die Code des Nutzers ausführt.
• Warum speichert HF „Secrets“?
  Könnten sie nicht nur öffentliche Schlüssel speichern, während Nutzer die privaten Schlüssel behalten und Anfragen signieren?
  • Man kann eine auf HF gehostete App erstellen und auf externe APIs wie OpenAI oder Anthropic zugreifen. Dabei werden die API-Keys in HF-Secrets gespeichert.
  • Damit etwas tatsächlich innerhalb einer Browser-Session funktioniert, braucht man normalerweise irgendeine Form von Token. Hier scheint es um Tokens zu gehen, die widerrufen werden mussten; sie sind Passwörtern ähnlich, aber nicht völlig dasselbe.