Microsoft-KI-Forscher legten versehentlich 38 TB an Daten offen

• Das KI-Forschungsteam von Microsoft legte beim Veröffentlichen von Open-Source-Trainingsdaten auf GitHub versehentlich 38 Terabyte an privaten Daten offen
• Zu den offengelegten Daten gehörten Arbeitsplatz-Disk-Backups von zwei Mitarbeitern, Geheimnisse, private Schlüssel, Passwörter sowie mehr als 30.000 interne Microsoft-Teams-Nachrichten
• Diese Daten wurden mithilfe von SAS-Tokens freigegeben, einer Azure-Funktion, mit der sich Daten aus Azure-Storage-Konten teilen lassen. Der Link war jedoch so konfiguriert, dass das gesamte Storage-Konto freigegeben wurde, wodurch die Daten offengelegt wurden
• Der Vorfall unterstreicht neue Risiken, denen Organisationen beim Einsatz von KI gegenüberstehen, und zeigt, dass zusätzliche Sicherheitsprüfungen und Schutzmechanismen nötig sind, da immer mehr Engineers mit großen Mengen an Trainingsdaten arbeiten
• Das Forschungsteam von Wiz entdeckte die Offenlegung, als es im Internet nach fehlkonfigurierten Storage-Containern suchte
• Dabei fanden sie ein GitHub-Repository namens robust-models-transfer unter der Microsoft-Organisation. Das Repository wurde erstellt, um Open-Source-Code und KI-Modelle für Bilderkennung bereitzustellen, erlaubte aufgrund einer Fehlkonfiguration über eine URL jedoch Zugriff auf mehr als nur die Open-Source-Modelle
• Auch das verwendete Token war falsch konfiguriert und erlaubte Berechtigungen mit „voller Kontrolle“, sodass ein Angreifer vorhandene Dateien einsehen, löschen und überschreiben konnte
• Der Vorfall macht die Sicherheitsrisiken von SAS-Tokens deutlich, da sie ein hohes Zugriffsniveau auf Storage-Konten gewähren und Probleme mit dem Ablaufdatum haben können. Außerdem sind sie schwer zu verwalten und zu widerrufen
• Das Forschungsteam von Wiz empfiehlt, wegen fehlender Sicherheit und Governance auf den Einsatz von Account SAS für die externe Freigabe zu verzichten und stattdessen Stored Access Policy oder User Delegation SAS für zeitlich begrenzte Freigaben zu nutzen
• Das Team empfiehlt außerdem, für die externe Freigabe dedizierte Storage-Konten zu erstellen und CSPM zu verwenden, um Richtlinien nachzuverfolgen und durchzusetzen
• Der Vorfall erinnert Sicherheitsteams daran, die in jeder Phase des KI-Entwicklungsprozesses inhärenten Sicherheitsrisiken zu verstehen, einschließlich der Risiken übermäßiger Datenfreigabe und von Supply-Chain-Angriffen
• Microsoft hat das SAS-Token inzwischen ungültig gemacht und auf GitHub ersetzt sowie die interne Untersuchung zu den potenziellen Auswirkungen abgeschlossen

[GN⁺]

Hacker-News-Kommentare

• Artikel über den Datenabfluss durch Microsoft-AI-Forscher, aber Kommentierende weisen darauf hin, dass dies nicht direkt mit AI zu tun hat
• Es geht bei dem Problem eher um Cloud-Anbieter, verwirrende Security-Token und den Umgang mit großen Daten-Downloads
• Eines der hervorgehobenen AI-spezifischen Risiken ist die Verwendung serialisierter Python-Objekte zum Speichern großer AI-Modelle, die verschleiert werden können und potenziell schädlichen Code enthalten
• Der Vorfall wurde durch eine Fehlkonfiguration von Storage-Tokens verursacht und ist ein typischer Fall, der die Notwendigkeit regelmäßiger Penetrationstests unterstreicht
• Die Verwendung von Pickle-Dateien und SAS-Tokens in Azure Storage wird kritisiert; stattdessen wird die Nutzung rollenbasierter Zugriffskontrolle (RBAC) vorgeschlagen
• Der Vorfall zeigt das Fehlen von Defense in Depth: SAS-Tokens hatten kein Ablaufdatum, gewährten weitreichenden Zugriff und umfassten auch Maschinen-Backups mit eigenen Tokens
• Es gibt den Vorschlag, alle Secrets und Umgebungsvariablen zu verwerfen, da die meisten Systeme rollenbasiert arbeiten könnten
• Der Vorfall wirkt wie ein Versagen bei der menschlichen Erstellung von Security-Tokens; vorgeschlagen wird, dass Organisationen OrgPolicy einrichten, um das pauschale Teilen von Authentifizierungs-Tokens/Zugangsdaten zu verhindern
• Es gibt Verwunderung darüber, dass jemand Teams-Nachrichten aus Teams exportieren konnte
• Der Datenabfluss dauerte zwei Jahre an und wurde erst vor zwei Monaten behoben
• Einige Kommentierende mögen das Key-Management-System von Azure nicht und schlagen stattdessen vor, pro Container unbegrenzt viele benannte Schlüssel zu haben
• Der Vorfall scheint die Schwierigkeiten von Cloud Security zu belegen: Ein oder zwei Fehler können Terabytes an Daten offenlegen