Transitiver Zugriffsmissbrauch - Datenexfiltration über Document AI

^16. September 2024

TLDR;

‍DerDocument AI-Dienst ermöglicht es Benutzern unbeabsichtigt, jedes Cloud Speicherobjekt im selben Projekt zu lesen.

• Document AI Service Fehlkonfiguration: Der Document AI Service Agent ist automatisch mit übermäßigen Berechtigungen ausgestattet, so dass er auf alle Objekte aus Cloud Storage Buckets im selben Projekt zugreifen kann.
• Risiko der Datenexfiltration: Böswillige Akteure können dies ausnutzen, um Daten von Cloud Storage zu exfiltrieren, indem sie indirekt die Berechtigungen des Service-Agenten ausnutzen.
• Transitiver Zugriffsmissbrauch: Bei dieser Schwachstelle handelt es sich um einen Fall von transitivem Zugriffsmissbrauch, einer Klasse von Sicherheitslücken, bei der unbefugter Zugriff indirekt über einen vertrauenswürdigen Vermittler erlangt wird. 
• Auswirkungen auf Google Cloud Kunden: Bei diesem Missbrauchsfall gehen die Bedrohungen über "riskante Berechtigungen" der ersten Stufe hinaus und umfassen ein Spinnennetz undokumentierter transitiver Beziehungen. 

‍

Dienstlicher Hintergrund:

Document AI ist ein Google Cloud Service, der Informationen aus unstrukturierten Dokumenten extrahiert. Er bietet sowohl vorgefertigte Modelle als auch eine Plattform für die Erstellung eigener Modelle. Als Teil von Vertex AI lässt sich Document AI mit anderen KI-Diensten integrieren, um Modelle bereitzustellen und zu teilen.

Document AI verwendet bei der Stapelverarbeitung von Dokumenten ein von Google verwaltetes Dienstkonto, das oft als Service Agent bezeichnet wird und dem die Rolle documentaicore.serviceAgent zugewiesen ist. Dieses Konto wickelt die Datenaufnahme, -umwandlung und -ausgabe mithilfe seiner umfassenden Cloud Speicherberechtigungen ab. Dieser Ansatz verringert die Reibungsverluste für den Endbenutzer, da die Identitätserstellung und die automatische Zuweisung von Berechtigungen automatisiert werden, im Gegensatz zur Verwendung eines vom Kunden verwalteten Dienstkontos für die Ausführung, die eine explizite Konfiguration und manuelle Rollenzuweisung erfordern würde.

Schwachstelle Beschreibung

Document AI ermöglicht es Benutzern, in Cloud Storage gespeicherte Dokumente zu verarbeiten, indem sie sowohl Online- (Standard-) Aufträge als auch Offline- (Stapel-) Verarbeitungsaufträge erstellen. Der Dienst verwendet den Document AI Core Service Agent mit der Rolle documentaicore.serviceAgent, um die Dateneingabe zu verarbeiten und die Ergebnisse bei der Stapelverarbeitung auszugeben. Entscheidend ist, dass dieser Service-Agent umfassende Berechtigungen für den Zugriff auf jeden Cloud Storage-Bucket innerhalb desselben Projekts besitzt. 

Anders als bei der Online- oder Standardverarbeitung, bei der der ursprüngliche Aufrufer von Document AI der Auftraggeber für den Abruf von GCS-Objekten ist, wird im Stapelverarbeitungsmodus der Abruf aller Eingabedaten und das Schreiben der Ergebnisse in einen GCS-Bucket im Kontext des Document AI Core Service Agent unter Verwendung seiner vorab zugewiesenen Berechtigungen ausgeführt. Da der Service Agent bei der Stapelverarbeitung als Identität verwendet wird, werden die Berechtigungsbeschränkungen des ursprünglichen Aufrufers nicht beachtet, was eine Datenexfiltration ermöglicht.

Der Document AI-Dienst nimmt eine benutzerdefinierte Eingabestelle zum Lesen vorverarbeiteter Daten und eine Ausgabestelle zum Schreiben der Ergebnisse auf. Diese Fähigkeit ermöglicht es einem böswilligen Akteur, Daten von GCS in einen beliebigen Cloud Storage-Bucket zu exfiltrieren, Zugriffskontrollen zu umgehen und sensible Informationen zu exfiltrieren.

Die Nutzung des Dienstes (und seiner Identität) zum Exfiltrieren von Daten stellt einen Missbrauch des transitiven Zugriffs dar, der die erwarteten Zugriffskontrollen umgeht und die Vertraulichkeit der Daten gefährdet.

‍

Voraussetzungen

1. Vorhandenes Dokument AI-Prozessor

Angenommen, ein Prozessor existiert in einem Zielprojekt. In diesem Fall benötigt ein böswilliger Akteur nur die Berechtigung documentai.processors.processBatch oder documentai.processorVersions.processBatch, um den Prozessor zu verwenden, Daten aus einem beliebigen Cloud Storage Bucket im Projekt zu lesen und die Objekte in einen beliebigen Bucket zu exfiltrieren.

‍

2. Erstellen oder Aktualisieren eines Prozessors

Wenn in einem Zielprojekt kein Prozessor vorhanden ist, bräuchte ein böswilliger Akteur zusätzlich die Berechtigung documentai.processors.create, um einen Prozessor zu erstellen, der sich zum Lesen aus einem Cloud -Storage-Bucket eignet, und die Ausgabe in einen anderen zu schreiben. Alternativ könnte ein Prozessor mit der Berechtigung documentai.processors.update geändert werden, um das Einlesen über einen GCS-Bucket zu ermöglichen. 

‍

3. Dokument AI Nicht zuvor verwendet

Wenn DocumentAI noch nicht in einem Projekt verwendet wurde, muss ein Angreifer den Dienst aktivieren, bevor er einen Prozessor erstellt oder verwendet. Die Aktivierung neuer Dienste in GCP-Projekten erfordert die IAM-Berechtigung serviceusage.services.enable Cloud und ist in mehr als 25 vordefinierten Rollen zusammen mit den grobkörnigen Rollen Editor und Owner enthalten. Bei der Aktivierung des DocumentAI-Dienstes werden der zugehörige Service-Agent und die ihm automatisch zugewiesene Rolle auf Projektebene erstellt, so dass keine *.setIamPolicy-Berechtigungen für den Service-Enabler erforderlich sind.

‍

Proof of Concept

Vier Terraform-Module werden bereitgestellt, um die Datenexfiltration durch Document AI zu demonstrieren. Zwei Module nutzen die processors.processBatch und processorVersions.processBatch Methoden aus und nutzen die weitreichenden Berechtigungen des Service-Agenten, um Daten von einem Cloud Storage Bucket in ein benutzerdefiniertes Ausgabe-Bucket zu kopieren. Im Gegensatz dazu zeigen die beiden anderen Module die standardmäßigen Online-Modi, processors.process und processorVersions.process, die Eingabedaten im Kontext des ursprünglichen Aufrufers abrufen und dabei die erwarteten Zugriffskontrollen einhalten. Die Stapelverarbeitungsmethoden umgehen diese Kontrollen effektiv, indem sie den Auftrag als DocumentAI Service Agent ausführen.    

‍

Googles Antwort 

Dieser Fall von transitivem Zugriffsmissbrauch wurde Google über das Vulnerability Reward Program am 4. April 2024 gemeldet. Nach mehrmonatigen Bemühungen der Forscher, die Ursache des Problems zu ermitteln und eine Lösung vorzuschlagen, hat Google die Meldung als Schwachstelle akzeptiert und als Kategorie S2C "Umgehung wichtiger Sicherheitskontrollen", andere Daten/Systeme, eingestuft. Sie wurden am 2. Juli über die geplante Veröffentlichung informiert.

Eine vollständige Aufstellung des Zeitplans für die Berichterstattung finden Sie weiter unten, wobei die folgenden Kommentare/Aktionen besonders hervorzuheben sind:

1. Google stellte fest, dass ".....das Problem auf eine unzureichende oder falsche Dokumentation zurückzuführen ist".
2. Der Status des Berichts, der im Rahmen des Vulnerability Reward Program (VRP) bearbeitet wurde, wurde auf "Behoben" geändert, obwohl das Problem weiterhin besteht.
3. Das Feld "Vorsicht" wurde in der DocumentAI IAM-Rollen Dokumentationsseite, in der die Kunden gewarnt werden, dass "die Berechtigungen für documentai.prozessoren.erstellen und documentai.datasets.update sind hoch privilegiert". 
   1. Der folgende Warnhinweis wurde irgendwann nach dem letzten Internet Archive Snapshot am 9. Dezember 2023 hinzugefügt. Ich kann nicht wissen, ob es als Reaktion auf meinen Bericht hinzugefügt wurde

‍

1. Google revidierte seine Entscheidung, ein Kopfgeld zu verweigern, und nannte "unzureichende oder fehlerhafte Dokumentation" als Grund dafür. Der eingereichte Fehler wurde nun als "Umgehung signifikanter Sicherheitskontrollen" eingestuft und mit einer Prämie belohnt. Es gibt immer noch keinen Hinweis darauf, wann oder wie der Missbrauchsfall behoben werden wird.

‍

Empfehlungen für Google

 Dem Document AI Service Agent sollten nicht automatisch umfassende Berechtigungen auf Projektebene zugewiesen werden. Die Verwendung eines von Google verwalteten Dienstkontos bietet zwar betriebliche Vorteile, aber die Gewährung eines uneingeschränkten Cloud Speicherzugriffs in Verbindung mit benutzerdefinierten Eingabe-/Ausgabespeicherorten stellt ein erhebliches Sicherheitsrisiko durch Missbrauch des transitiven Zugriffs dar. Der Dienst funktioniert möglicherweise wie vorgesehen, aber nicht wie erwartet.

Auswirkungen auf Google Cloud Kunden

Alle Kunden von Google Cloud sind von dieser Sicherheitslücke betroffen, wenn sie die Aktivierung des DocumentAI-Dienstes und seine Verwendung nicht durch die unten aufgeführten organisatorischen Richtlinieneinschränkungen verhindern. Ein Kunde muss DocumentAI derzeit nicht verwenden, um betroffen zu sein. Allein die Möglichkeit für einen Angreifer, den Dienst zu aktivieren, stellt ein Risiko für die Exfiltration wichtiger Daten dar.

Wenn IAM-Berechtigungen sich gegenseitig beeinflussen, wird die Beantwortung der Frage "Was könnte schiefgehen" bei einem bestimmten Dienst unmöglich. Es ist unklar, welche Schritte Google als Nächstes zum Schutz seiner Kunden unternimmt, ob sie eine Einschränkung der Organisationsrichtlinien anbieten oder diesen Fall von transitivem Zugriffsmissbrauch ganz abschaffen wollen.

‍

Abhilfemaßnahmen

Leider hat der Bericht, der über das Schwachstellen-Belohnungsprogramm (Vulnerability Reward Program, VRP) von Google eingereicht wurde, trotz aller Bemühungen nicht zu Änderungen am Dienst geführt. Die unten erwähnten Migrationen beheben die zugrunde liegende Schwachstelle nicht, sondern verringern nur die potenziellen Auswirkungen für den Kunden. 

1. Segmentierung auf Projektebene: Document AI sollte in einem segmentierten und isolierten Projekt verwendet werden. Mischen Sie den Document AI-Dienst nicht mit einem Projekt, das sensible Daten enthält. Wenn Sie einen SaaS- oder ETL-Dienst verwenden, konfigurieren Sie die projektübergreifenden Ein- und Ausgabestellen. Dies erzwingt die manuelle Bindung von IAM-Berechtigungen für jeden Service-Agenten, anstatt sich auf automatische Zuweisungen zu verlassen.

 2. Schränken Sie die API und den Dienst ein: Verwenden Sie die Org Policy Constraint serviceuser.services, um die Aktivierung des Document AI-Dienstes zu verhindern, wenn er nicht benötigt wird, und schränken Sie die API-Nutzung mit der Org Policy Constraint serviceuser.restrictServiceUsage ein.

‍

Schlussfolgerungen

Die Zuweisung von Rollen und Berechtigungen ist nur ein Teil der Geschichte, vor allem wenn man die Funktionalität des Dienstes und die Möglichkeit des transitiven Zugriffs berücksichtigt. Der Missbrauch des transitiven Zugriffs ist wahrscheinlich nicht auf den Document AI-Dienst beschränkt; er wird wahrscheinlich bei allen Diensten (und allen großen Anbietern von cloud ) wieder auftreten, da die Bedrohungsmodelle weiterhin missverstanden werden.

Die Segmentierung von Datenspeicherung, Geschäftslogik und Arbeitslasten in verschiedene Projekte kann den Radius von übermäßig privilegierten Service-Agenten reduzieren, aber die Kunden verlassen sich darauf, dass die Anbieter von cloud sicherstellen, dass sie in ihren Produkten und IAM-Schemata keine Wege zur Privilegieneskalation aufbauen.

‍

Zeitplan für die Berichterstattung und Reaktion

• April 4^th 2024: Erster Bericht: Datenexfiltration über Document AI Data Processing, Ausgabe 332943600
  • [Google VRP]: "Hallo! Vielen Dank für Ihren Bericht. Diese E-Mail bestätigt, dass wir Ihre Nachricht erhalten haben. Wir werden das von Ihnen gemeldete Problem untersuchen und uns wieder bei Ihnen melden, sobald wir ein Update haben. In der Zwischenzeit sollten Sie einen Blick auf die Liste der häufig gestellten Fragen zu Google Bug Hunters.

• April 8^th 2024: Priorität geändert P4 -> P3 und Status geändert Neu -> Zugewiesen
  • [Google VRP]: "Wir möchten Sie nur wissen lassen, dass Ihre Meldung geprüft wurde und wir sie derzeit untersuchen."
• 9. April^th 2024: Typ ändert Kundenproblem -> Fehler; Schweregrad geändert von S4 -> S2; Status geändert von Zugewiesen -> In Bearbeitung (akzeptiert)
  • [Google VRP]: "Nochmals vielen Dank für Ihren Bericht. Ich habe auf der Grundlage Ihres Berichts einen Fehler beim zuständigen Produktteam gemeldet. Das Produktteam wird Ihren Bericht auswerten und entscheiden, ob eine Korrektur erforderlich ist. Wir werden Sie informieren, wenn das Problem behoben wurde. Bezüglich unseres Schwachstellen-Belohnungsprogramms: Auf den ersten Blick scheint dieses Problem nicht schwerwiegend genug zu sein, um sich für eine Belohnung zu qualifizieren. Das VRP-Gremium wird sich das Problem jedoch bei seinem nächsten Treffen genauer ansehen. Wir werden Sie auf dem Laufenden halten, sobald wir eine Entscheidung getroffen haben. Wenn Sie innerhalb von 2-3 Wochen keine Antwort von uns erhalten oder zusätzliche Informationen über die Sicherheitslücke haben, lassen Sie es uns wissen! "
• ^9. April 2024 - [Kat Traxler]: "Wie immer danke für die schnelle Triage. Wenn ich Ihnen helfen kann, das Risiko der aktuellen Konfiguration zu beschreiben, zögern Sie bitte nicht, mich zu kontaktieren. Danke, Kat"
• ^30. April 2024 - [Kat Traxler]: "Hallo, ich bringe dies an den Anfang Ihres Posteingangs. Ich möchte wissen, ob dies als Missbrauchsrisiko eingestuft wurde? oder ob eine Aktualisierung des Dienstes bevorsteht. Danke, Kat"
• ^2. Mai 2024 - [Google VRP]: "Hallo! Die Mitglieder des Gremiums haben noch keine Entscheidung über diesen Bericht getroffen; das Gremium tagt zweimal pro Woche, und Ihr Bericht wird bei jeder Sitzung berücksichtigt. Wir entschuldigen uns für die Verzögerung und danken Ihnen für Ihre Geduld. Sie werden eine automatische E-Mail erhalten, sobald eine Entscheidung getroffen wurde."
• ^2. Mai 2024 - [Kat Traxler]: "Danke für das Update. Wenn ich in ~4 Wochen oder so nichts höre, werde ich mich wieder melden.
• ^7. Mai 2024 - [Google VRP]: "**Hinweis: Dies ist eine automatisch generierte E-Mail **Hallo, das Gremium des Google Vulnerability Reward Program hat entschieden, dass die Sicherheitsauswirkungen dieses Problems nicht die Voraussetzungen für eine finanzielle Belohnung erfüllen. Wir möchten jedoch Ihren Beitrag zur Sicherheit von Google auf unserer Seite für lobende Erwähnungen unter https://bughunters.google.com/leaderboard/honorable-mentions würdigen. Wenn Sie dort aufgenommen werden möchten, erstellen Sie bitte ein Profil unter https://bughunters.google.com, falls Sie dies noch nicht getan haben. Begründung für diese Entscheidung: Wir haben festgestellt, dass das Problem auf unzureichende oder falsche Dokumentation zurückzuführen ist. Bitte beachten Sie, dass die Tatsache, dass dieses Problem nicht belohnt wird, nicht bedeutet, dass das Produktteam das Problem nicht beheben wird. Wir haben einen Fehler an das Produktteam gemeldet. Es wird Ihren Bericht prüfen und entscheiden, ob eine Korrektur erforderlich ist. Wir werden Sie benachrichtigen, wenn das Problem behoben wurde. Mit freundlichen Grüßen, Google Security Bot"
• ^7. Mai 2024: - [Kat Traxler]: "Danke für die Antwort!"
• 22. Juni^und 2024: Status geändert auf "Behoben"
  • [Google VRP]: "Unsere Systeme zeigen, dass alle Fehler, die wir aufgrund Ihres Berichts erstellt haben, vom Produktteam behoben wurden. Bitte überprüfen Sie dies und lassen Sie uns wissen, ob bei Ihnen alles in Ordnung ist. Nochmals vielen Dank für Ihre Hilfe!"
• ^25. Juni 2024 - [Kat Traxler]: "Hallo. Ich stelle fest, dass dieses Problem nach wie vor besteht. Dokumente und Trainingsdaten können mit den Berechtigungen des Document AI Core Service Agent exportiert werden, wodurch ein Benutzer, der keinen Zugriff auf den Speicher hat, die Möglichkeit hat, Daten zu exfiltrieren. Beachten Sie, dass diese Fähigkeit in den Methoden: google.cloud.documentai.uiv1beta3.DocumentService.ExportDocuments und in den Stapelverarbeitungsfähigkeiten: (processors.batchProcess & processorVersions.batchProcess & processors.batchProcess) vorhanden ist Lassen Sie mich wissen, wenn Sie weitere POCs benötigen.
• ^26. Juni 2024 - [Google VRP]: "Hallo! Danke für Ihre Antwort, wir haben den internen Fehler für das Team, das an diesem Problem arbeitet, aktualisiert."
• ^2. Juli 2024 - [Kat Traxler]: "Hallo. Angesichts des kürzlichen 'Fehlalarms', dass dieses Problem behoben sei, habe ich mir Sorgen gemacht, dass ich das Risiko und die Auswirkungen nicht angemessen kommuniziert habe. Daher habe ich einen TF-Einsatz erstellt und einen POC aufgezeichnet, den Sie und das Serviceteam sich ansehen können. Die TF-Bereitstellung finden Sie unter: https://github.com/KatTraxler/document-ai-samples POC-Video unter diesem Link. Der Punkt, der besonders hervorgehoben werden muss, ist, dass der Auftraggeber, der Dokumente mit Document AI bearbeiten (oder stapelverarbeiten) kann, keine Speicherberechtigungen haben muss, um auf Daten in Cloud Storage zuzugreifen und sie an einen anderen Ort zu verschieben (Datenexfiltration). Dies wird durch die Berechtigungen erreicht, die Document AI P4SA zugewiesen sind. (roles/documentaicore.serviceAgent). Ich empfehle, dass Document AI für seine Datenverarbeitung ein benutzerverwaltetes Dienstkonto zugewiesen wird, ähnlich wie bei Cloud Workflows. Der P4SA zu erlauben, benutzerdefinierte Daten zu verschieben, ist nicht das richtige Muster und hat zu einer Schwachstelle bei der Datenexfiltration geführt. Bitte ändern Sie den Status dieses Problems, um anzuzeigen, dass es noch nicht behoben wurde. Die öffentliche Bekanntgabe erfolgt auf einer hochkarätigen Veranstaltung im September 2024.
• ^4. Juli 2024 - [Google VRP]: "Hallo! Vielen Dank für weitere Informationen zu dem Fall, wir werden das Produktteam anpingen. Und danke für den Hinweis auf die Veröffentlichung Ihres Berichts. Bitte lesen Sie unseren Standpunkt zur koordinierten Offenlegung. Im Wesentlichen ist unser Versprechen an Sie, umgehend zu reagieren und Schwachstellen in einem vernünftigen Zeitrahmen zu beheben - und im Gegenzug bitten wir um eine angemessene Vorankündigung."
• ^29. Juli 2024 - [Kat Traxler]: "Hallo Team. Ich möchte euch noch einmal darauf hinweisen, dass ich am 17. September auf der fwd:CloudsecEU über das Risiko der Datenexfiltration durch den DocumentAI-Service sprechen werde: https://pretalx.com/fwd-cloudsec-europe-2024/talk/BTT9LJ/. Ein begleitender Blog wird am Tag zuvor, am 16. September, veröffentlicht. Danke, Kat"
• ^30. Juli 2024 - [Google VRP]: "Hallo. Vielen Dank für die Vorwarnung!"
• ^5. August 2024 - [Kat Traxler]: "Danke. Darf ich vorschlagen, den Status dieses Berichts von "Behoben" zu ändern? Da er nicht behoben ist, nochmals vielen Dank. Kat"
• ^12. August 2024 - [Google VRP]: "Hallo, wäre es möglich, einen Entwurf der Präsentation und/oder des Blogbeitrags vor der Veröffentlichung mit uns zu teilen? Thank you"
• ^12. August 2024: Kommentar von Kat Traxler: "Das mache ich sehr gerne. Ich bin vor allem an Ihrem Feedback zur Genauigkeit und zur Koordinierung des Hinweises interessiert. Ich werde den Blogbeitrag bis zum²⁶. August fertig haben^.
• ^13. August 2024 - [Google VRP]: "HI! Danke!"
• ^21. August 2024 - [Google VRP]: "Hallo Kat, nochmals vielen Dank für Ihren Bericht und Ihre Geduld! Das Team hat sich soeben zusammengesetzt und Ihre Meldung im Team viel ausführlicher diskutiert. Wir haben beschlossen, dem Produktteam einen Fehler zu melden, nachdem wir überlegt haben, ob es sich um WAI oder eine Schwachstelle handelt. Wir haben dies getan, weil das Verhalten aus Ihrer Sicht nicht klar ist, aber das Produktteam am besten in der Lage ist, zu entscheiden, ob etwas WAI ist oder nicht. Der interne Fehler wurde am 9. Juli aufgrund Ihres Kommentars wieder geöffnet und wir werden mit dem Produktteam zusammenarbeiten, um diese Entscheidung zu treffen. Wir werden auch die Meldung 332943600 wieder öffnen, um dies zu berücksichtigen - dies hätte bereits im Juli geschehen müssen, sorry! Nochmals vielen Dank für Ihre Kontaktaufnahme und Ihren Bericht!
  Das Google Bug Hunter Team"
• ^22. August 2024 - [Kat Traxler]: "Danke für das Update und die Statusänderung. Können Sie Ihre Definitionen von WAI und einer Sicherheitslücke mitteilen? Für mich kann ein Problem sowohl wie vorgesehen funktionieren (WAI) als auch erhebliche negative Auswirkungen auf die Sicherheit haben. Vielen Dank. Kat"
• ^9. September 2024 - [Google VRP]: "Das Gremium des Google Vulnerability Reward Program hat beschlossen, für Ihre Meldung eine Belohnung in Höhe von 3133,70 $ zu vergeben. Herzlichen Glückwunsch! Begründung für diese Entscheidung: Normale Google-Anwendungen. Schwachstellen-Kategorie ist "Umgehung signifikanter Sicherheitskontrollen", andere Daten/Systeme Wir haben eine Herabstufung vorgenommen, weil der Angreifer Zugriff auf ein betroffenes Opferprojekt haben muss."

 Verwandte Forschung

 Weitere Informationen zu GCP Service Agents und ihren Bedrohungsmodellen finden Sie in der GCP IAM 201 Serie zu diesen Themen:

• GCP IAM 201 - Dienstleistungsagenten
• GCP IAM 201 - Bedrohungsmodell für Service-Agenten

‍