SAPwned: SAP-AI-Schwachstellen legten Kunden-Cloud-Umgebungen und nicht öffentliche AI-Artefakte offen

• Wiz Research stellte fest, dass eine Schwachstellenkette in der Tenant-Isolation von SAP AI Core dazu führen konnte, dass Codeausführung aus einem regulären AI-Training-Job in die Übernahme des Dienstes und den Zugriff auf Kundengeheimnisse mündete
• Der Angriffspfad bestand aus einer Verkettung von Umgehung der Istio-Netzwerkbeschränkungen, Offenlegung von AWS-Tokens in der Loki-Konfiguration, nicht authentifizierten EFS-Shares und nicht authentifiziertem Zugriff auf Helm v2 Tiller
• Mit den erlangten Berechtigungen konnten Images und Artefakte in SAPs interner Docker Registry, der Google Container Registry und dem internen Artifactory gelesen und verändert werden; außerdem konnten cluster-admin-Rechte für den Kubernetes-Cluster erlangt werden
• Potenzielle Angreifer hätten auf AWS-, Azure- und SAP-HANA-Cloud-Anmeldedaten von Kunden sowie auf nicht öffentliche AI-Artefakte wie Modelle, Datensätze und Code zugreifen oder interne Artefakte kompromittieren können
• SAP hat alle gemeldeten Schwachstellen behoben und die zugehörigen Geheimnisse rotiert; Wiz erklärte, dass keine Kundendaten kompromittiert wurden

---

In SAP AI Core offengelegte Probleme bei der Tenant-Isolation

• Wiz Research untersucht die Tenant-Isolation von AI-Service-Anbietern; SAP AI Core ist nach Hugging Face und Replicate der dritte Bericht
• SAP AI Core ist ein Managed Service, mit dem Nutzer AI-Services auf SAPs Cloud-Ressourcen entwickeln, trainieren und ausführen können
• AI-Trainingsdienste müssen auf große Mengen sensibler Kundendaten zugreifen; SAP AI Core nutzt Cloud Access Keys, die Zugriff auf interne Kundendaten ermöglichen, um HANA und andere Cloud-Services anzubinden
• Die Untersuchung begann mit einem SAP-Kundenkonto mit Standardberechtigungen, in dem ein AI-Projekt erstellt und über eine von SAP AI Core zugelassene Argo-Workflow-Datei ein Kubernetes-Pod erzeugt wurde
• Nutzer konnten konstruktionsbedingt beliebigen Code im Pod ausführen; in der Anfangsumgebung erschwerte jedoch ein Istio-Proxy-Sidecar interne Netzwerkscans, weil er den Netzwerkzugriff einschränkte

Bug #1: Umgehung der Istio-Beschränkungen

• SAPs Admission Controller blockierte gefährliche Sicherheitsoptionen; auch Versuche, Container als root auszuführen, wurden verhindert
• Zwei nicht blockierte Einstellungen führten zur Umgehung der Netzwerkbeschränkungen
  • shareProcessNamespace ermöglichte das Teilen des Prozess-Namespace mit dem Sidecar-Container, wodurch die Istio-Proxy-Konfiguration und das Zugriffstoken für den zentralen Istiod-Server einsehbar wurden
  • runAsUser und runAsGroup erlaubten andere UIDs außer root, sodass eine Ausführung mit Istios UID 1337 möglich war
• Da Istio selbst von den Istio-iptables-Regeln ausgenommen ist, liefen Prozesse mit UID 1337 ohne Traffic-Beschränkungen
• Anschließend konnte mit dem Istio-Token die Konfiguration des Istiod-Servers gelesen und Informationen über die interne Umgebung gesammelt werden

Bug #2: Offenlegung von AWS-Tokens in der Loki-Konfiguration

• Innerhalb des Clusters wurde eine Grafana-Loki-Instanz entdeckt; über eine Anfrage an den /config-Endpunkt war die gesamte Konfiguration einsehbar
• Die Antwort enthielt AWS-Geheimnisse, die Loki für den Zugriff auf S3 nutzte
• Diese Geheimnisse gewährten Zugriff auf Lokis S3-Bucket, der viele AI-Core-Service-Logs und Kunden-Pod-Logs enthielt
• SAP bewertete diese Logs als nicht sensibel

Bug #3: Offenlegung von Nutzerdateien über nicht authentifizierte EFS-Shares

• Im internen Netzwerk wurden sechs AWS-Elastic-File-System-Instanzen, also EFS, entdeckt, die auf Port 2049 lauschten
• Diese EFS-Instanzen ermöglichten das Anzeigen oder Bearbeiten von Dateien ohne Anmeldedaten, sofern Netzwerkzugriff bestand
• Mit Open-Source-NFS-Tools konnte frei auf die Inhalte der Shares zugegriffen werden
• Auf EFS waren große Mengen an AI-Daten gespeichert, darunter Code und Trainingsdatensätze, nach Kunden-IDs sortiert

Bug #4: Nicht authentifiziertes Helm Tiller legte interne Registry und Artifactory offen

• Im internen Netzwerk wurde der Tiller-Service entdeckt, die Serverkomponente von Helm v2
• Tiller kommuniziert über eine gRPC-Schnittstelle auf Port 44134 und ist standardmäßig ohne Authentifizierung exponiert
• Abfragen von Tiller legten hochprivilegierte Geheimnisse für SAP Docker Registry und Artifactory-Server offen
• Mit Leserechten konnten interne Images und Builds ausgelesen werden, um Geschäftsgeheimnisse und Kundendaten zu extrahieren
• Mit Schreibrechten konnten Images und Builds kompromittiert werden, um einen Supply-Chain-Angriff auf den SAP-AI-Core-Service auszuführen

Bug #5: Übernahme des Kubernetes-Clusters über Schreibrechte in Helm Tiller

• Tiller erlaubte nicht nur Lese-, sondern auch Schreiboperationen
• Da der Befehl install Helm-Pakete entgegennimmt und in den Kubernetes-Cluster ausrollt, erstellte und installierte das Forschungsteam ein bösartiges Helm-Paket, das ein neues Pod mit cluster-admin-Rechten erzeugte
• Dadurch wurden volle Berechtigungen für den Cluster erlangt
• Diese Berechtigungen reichten aus, um direkt auf Pods anderer Kunden zuzugreifen und sensible Daten wie Modelle, Datensätze und Code zu stehlen
• Außerdem hätten Kunden-Pods gestört, AI-Daten kompromittiert und Modell-Inferenzen manipuliert werden können
• Mit denselben Berechtigungen konnten auch Kundengeheimnisse außerhalb des Umfangs von SAP AI Core im Klartext abgefragt werden
  • Das AI-Core-Konto des Forschungsteams enthielt AWS-Kontogeheimnisse für den Zugriff auf S3-Daten
  • Es enthielt SAP-HANA-Kontogeheimnisse für den Zugriff auf Data Lake
  • Es enthielt Docker-Hub-Kontogeheimnisse zum Pullen von Images
• In derselben Abfrage wurde außerdem ein SAP Access Key für Google Container Registry namens sap-docker-registry-secret gefunden; dieser Schlüssel gewährte sowohl Lese- als auch Schreibrechte

Bestätigter Zugriffsumfang und potenzielle Auswirkungen

• Über die Schwachstellenkette waren folgende Aktionen möglich
  • Lesen und Verändern von Docker-Images in SAPs interner Container Registry
  • Lesen und Verändern von SAP-Docker-Images in Google Container Registry
  • Lesen und Verändern von Artefakten auf SAPs internem Artifactory-Server
  • Erlangen von cluster-admin-Rechten für den SAP-AI-Core-Kubernetes-Cluster
  • Zugriff auf Kunden-Cloud-Anmeldedaten und nicht öffentliche AI-Artefakte
• Potenzielle Angreifer hätten auf Kundendaten zugreifen und interne Artefakte kompromittieren können, um Auswirkungen auf zugehörige Dienste und Umgebungen anderer Kunden auszuweiten
• Alle Schwachstellen wurden dem SAP-Sicherheitsteam gemeldet und von SAP behoben; SAP würdigte dies auf der Credits-Seite für Sicherheitsforscher
• Kundendaten wurden nicht kompromittiert

Aus Verteidigungssicht offengelegte Probleme

• Die wichtigste Verteidigungslinie war eine Architektur, in der Istio den Zugriff auf das interne Netzwerk blockierte; nach Umgehung dieser Barriere verlangten jedoch mehrere interne Assets keine zusätzliche Authentifizierung
• Weil das interne Netzwerk wie eine vertrauenswürdige Zone behandelt wurde, eskalierte eine einzelne Umgehung zur Übernahme des Dienstes
• Wären interne Dienste gehärtet gewesen, hätte sich die Auswirkung des Angriffs von einer vollständigen Service-Übernahme auf einen kleineren Sicherheitsvorfall reduzieren lassen
• Kubernetes-basierte Managed Services können Fallstricke bei der Tenant-Isolation schaffen, weil Control Plane und Kunden-Compute über APIs, Identitäten, gemeinsam genutzte Compute-Ressourcen und softwarebasierte Netzwerksegmentierung logisch miteinander verbunden sind
• AI-Training erfordert naturgemäß die Ausführung beliebigen Codes; daher sind Guardrails nötig, damit nicht vertrauenswürdiger Code angemessen von internen Assets und anderen Tenants getrennt bleibt

Zeitplan der Veröffentlichung

• 25. Januar 2024: Wiz Research meldete die Sicherheitsfunde an SAP
• 27. Januar 2024: SAP antwortete und wies eine Fallnummer zu
• 16. Februar 2024: SAP behob die erste Schwachstelle und rotierte die zugehörigen Geheimnisse
• 28. Februar 2024: Wiz Research umging den Patch mit zwei neuen Schwachstellen und meldete sie an SAP
• 15. Mai 2024: SAP stellte Fixes für alle gemeldeten Schwachstellen bereit
• 17. Juli 2024: Veröffentlichung

[GN⁺]

Meinungen auf Hacker News

• Ich verstehe, dass es ein AI-Produkt ist, aber die Schwachstelle liegt hier in der k8s-Konfiguration.
  Mit dem AI-Produkt selbst, AI-Training, Machine Learning oder generativer AI hat das wenig zu tun; es geht eher um mangelhafte Cloud-Plattform-Sicherheit.

  • Vielleicht ist es sogar noch schlimmer. Ein Unternehmen wie SAP, das groß ist und viele wichtige Informationen verarbeitet, hat grundlegende Cloud Security vermasselt; es klingt also nicht danach, dass sie bei etwas Neuem gescheitert sind, sondern nach einem gewöhnlichen Fehler.
  • Der Artikel behauptet nicht, dass das Produkt selbst das Problem sei. Er beschreibt es vielmehr gut als Problem der Isolation von AI-Trainingsmodellen.
    Die eigentliche Ursache war, dass „Angreifer ein bösartiges AI-Modell und Trainingsverfahren ausführen konnten“, was im Kern Codeausführung ist.
    Ich verstehe, dass das untersucht wurde, weil AI-Produkte sich stark verbreiten und man bei deren Infrastruktur vorsichtig sein muss.
  • Die verkaufte Marke muss Verantwortung übernehmen.
    Sicherheit umzusetzen, den Bedarf an Sicherheit zu kennen, zu testen oder nicht zu veröffentlichen, bis es sicher ist – all das ist Aufgabe der Marke als Anbieter.

• Ich hoffe, SAP arbeitet gründlich auf, warum die Forschung von Wiz nicht gestoppt wurde, bevor sie vollständige Cluster-Administratorrechte erreichte.
  Ich würde gern wissen, ob SAP über diese Aktivität alarmiert wurde und ob sie sie ordnungsgemäß untersucht hat. Außerdem frage ich mich, ob SAP Regulierungen unterliegt, die ausreichende Alarmierung bei verdächtiger Netzwerkaktivität verlangen, und ob diese Untersuchung als Beleg dafür dienen könnte, dass sie diese Anforderungen nicht erfüllen.

  • Regeln und Vorschriften gibt es eindeutig. Man muss nur auf die Zertifizierungsseite schauen: https://www.sap.com/about/trust-center/certification-complia...
    Die Frage ist, ob sie tatsächlich eingehalten werden oder nur in einem Ordner im Regal stehen.
  • Normalerweise sollte ein Sicherheitsforscher das Ziel kontaktieren und um Erlaubnis bitten, bevor er tiefer in ein System eindringt.
    Bug-Bounty-Programme verlangen solche Regeln innerhalb des definierten Scopes ebenfalls oft. Da die Forscher zu einer Sicherheitsfirma gehören, würde ich erwarten, dass das hier auch so war.
    Forscher schreiben üblicherweise in den Artikel, an welchem Punkt sie zusätzliche Erlaubnis angefordert haben, aber nicht immer.
  • Wenn sie es tatsächlich nicht erkannt haben, frage ich mich, woher sie wissen wollen, dass Kundendaten nicht kompromittiert wurden.
  • SAP fehlt es an Cloud-Security-Kompetenz. Es gibt eine lange Liste von Sicherheitsproblemen bei SAP-Cloud-Diensten, und das sind nur die bekannten.
  • Es wäre gut, einen Artikel zu sehen, der zeigt, wie man so etwas in AI erkennt.

• Ich bin schockiert, dass eine tiller-Instanz lief. Sie wird seit 2020 nicht mehr unterstützt: https://helm.sh/blog/helm-v2-deprecation-timeline/

  • Du würdest dich erschrecken, wenn du wüsstest, wie viel Software von vor 2020, ja sogar von vor 2010, noch in Produktionsumgebungen läuft.
    Hier handelt es sich um ein Großunternehmen, und die Migration weg von tiller ist etwas komplex, aber auch ohne solche erschwerenden Umstände findet man alte Software leicht.
  • Nach meiner Erfahrung wird „nicht mehr unterstützt“ oft als „wurde noch nicht entfernt, also kann man es weiter nutzen“ verstanden, was manchmal ziemlich deprimierend ist.
  • In Microsoft Dynamics gibt es enorm viel alten, unsicheren und ungepatchten Legacy-Code.

• Das ist wirklich schlimm. Haben sie etwa erwartet, einen einzelnen K8s-Cluster zu betreiben und starke Multi-Tenancy-Garantien zu bekommen?
  Alle großen Clouds verwenden zwischen Kunden Virtual-Machine-Grenzen und separate K8s-Cluster. Microsoft ist vor einigen Jahren bei einem seiner Functions-Produkte ähnlich getroffen worden, bei dem K8s als zentrale Sicherheitsgrenze erwartet wurde.

  • Vielleicht habe ich im Artikel die Stelle übersehen, an der sie starke Garantien erwartet haben, aber wo sieht man diese Erwartung?
    Zum Beispiel ist mir nicht klar, welche Rolle K8s-Multi-Tenancy in Situationen spielt, in denen beliebiger Code ausgeführt wird, etwa beim Modelltraining.
    Für mich wirkt das Hauptproblem so, als hätten sie hinter Istio als Proxy/Firewall die gesamte interne Netzwerkkommunikation vertraut. Vielleicht verstehe ich k8s-Cluster aber auch nicht gut genug.
  • Starke Multi-Tenancy innerhalb desselben logischen K8s-Clusters ist realistisch schwer zu erreichen.
    Es ist ein bewegliches Ziel, und der Plan, das mit Admission Controllern sicher zu machen, ist auch nicht besonders gut.
    Wenn man starke Multi-Tenancy gegen feindliche Tenants in Betracht zieht, sollte man sich zuerst Dinge wie VirtualClusters ansehen (https://github.com/kubernetes-sigs/cluster-api-provider-nest...). Und das betrifft nur die Control Plane, die Data Plane ist dabei noch gar nicht angefasst.
    Selbst mit dieser zusätzlichen Schicht weiß ich nicht, wie sicher das ist. Auch im Bereich virtueller Maschinen gab es über Jahre völlig absurde VM-Escape-Schwachstellen.
  • Richtig konfiguriertes K8S ist buchstäblich für Multi-Tenancy konzipiert.
    Für jeden Kunden einen eigenen Cluster zu betreiben, ist absurd teuer und schlecht für den Planeten. Für ein Premiumprodukt, bei dem Sicherheit oberste Priorität hat, wäre das möglich, aber separate Cluster pro Kunde bedeuten im Grunde, Geld zu verbrennen.

• Ich finde, Unternehmen, die ohne Erlaubnis in Netzwerke eindringen, um Schwachstellen zu finden und Blog-Content zu produzieren, sollten strafrechtlich verfolgt werden.
  Dieser Artikel klingt insbesondere wie ein angriffslustiger Beitrag, der nur dünn als Schwachstellenoffenlegung verpackt ist. Auch das „Danke für die Zusammenarbeit“ klingt ein wenig nach Erpressung.

  • Man kann das auch umformulieren zu: „Unternehmen, die sensible Nutzerdaten fahrlässig sammeln und unsicher speichern, sollten keiner genauen Prüfung unterliegen, und man sollte ihnen erlauben, weiterhin die Daten unschuldiger Nutzer böswilligen Cyberkriminellen auszusetzen.“
    Aus dieser Perspektive sieht es ziemlich anders aus, oder?
  • Unaufgefordert ein großes Unternehmen hacken zu wollen, ist eine Straftat und würde normalerweise ernsthaft verfolgt werden.
    Allerdings läuft es, wie die Rechtspraxis sagt, oft darauf hinaus: „Wenn man Milliarden Dollar hat, gilt das Gesetz nicht mehr.“

• Hat jemand Wiz schon ausprobiert?
  Könnte die am schnellsten wachsende Rakete unter den Enterprise-Software-Unternehmen sein. Nach 1,5 Jahren 100 Mio. US-Dollar ARR, am Ende des dritten Jahres 350 Mio. US-Dollar erreicht
  https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

  • Wir nutzen es und sind sehr zufrieden. Selbst abgesehen vom Sicherheitsaspekt war es das beste Tool, das ich ausprobiert habe, um Multi-Cloud-Asset-Management wirklich richtig zu machen
    Mit der Graph-Funktion kann man, wenn man will, praktisch alles über alle Accounts hinweg abfragen
  • Google ist außerdem dabei, es für 23 Mrd. US-Dollar zu übernehmen

• Ich bin froh, dass ich die Leute in der Firma davon überzeugen konnte, den jährlichen Penetrationstest des Produkts in der Produktionsumgebung laufen zu lassen und die gesamte Produktionsinfrastruktur in den Scope aufzunehmen
  Der Fokus kann zwar auf einem bestimmten Produkt oder System liegen, aber alles ist im Scope. Der erste Test läuft gerade, und noch schreit niemand, also hoffe ich, dass es gut läuft

  • Wenn du „jährlich“ sagst, kann man das so verstehen, dass ihr keine regelmäßigen internen Penetrationstests macht?
    Mich würde auch interessieren, ob du eine Pentest-Firma empfehlen kannst, die das ordentlich macht und nicht nur einmal grob mit Metasploit drübergeht

• Wenn ich das richtig gelesen habe, werden die Kontodaten eines Kunden demselben Kunden offengelegt? Nur ein Teil der Logs scheint eine Ausnahme zu sein

  • Nicht nur ein Teil der Logs, sondern auch Trainingsdaten und Code anderer Kunden sowie das interne Docker-Image-Repository von SAP wurden offengelegt. Und das mit Lese- und Schreibrechten!

• Als Sicherheitsforscher sollte man eigentlich wissen, dass Pixelierung keine gute Wahl ist, um Text zu verdecken
  https://www.bleepingcomputer.com/news/security/researcher-re...

  • Alle gemeldeten Bugs wurden gepatcht, und potenziell kompromittierte Secrets wurden wahrscheinlich ebenfalls rotiert
    Unabhängig davon, ob Weichzeichnen oder Pixelierung wirksam ist, wirkt es hier praktisch unnötig. Die verdeckten Daten scheinen lokale Hostnamen und Teile von Image-Hashes zu sein
  • Für mich sah es nicht nach Pixelierung, sondern nach Weichzeichnen aus
    Edit: Beim erneuten Hinsehen scheint es an manchen Stellen weichgezeichnet und an anderen pixeliert worden zu sein