Abuso di accesso transitivo - Esfiltrazione di dati tramite l'intelligenza artificiale dei documenti

¹⁶ settembre 2024

TLDR;

Ilservizio Document AI consente involontariamente agli utenti di leggere qualsiasi oggetto di Cloud Storage nello stesso progetto.

• Errata configurazione del servizio Document AI: All'agente del servizio Document AI vengono assegnate automaticamente autorizzazioni eccessive, che gli consentono di accedere a tutti gli oggetti dei bucket di Cloud Storage dello stesso progetto.
• Rischio di esfiltrazione dei dati: gli attori malintenzionati possono sfruttare questo aspetto per esfiltrare i dati dal Cloud Storage sfruttando indirettamente le autorizzazioni dell'agente di servizio.
• Abuso di accesso transitivo: Questa vulnerabilità è un caso di abuso di accesso transitivo, una classe di falle di sicurezza in cui l'accesso non autorizzato viene ottenuto indirettamente attraverso un intermediario fidato. 
• Impatto per i clienti di Google Cloud : Con questo caso di abuso, le minacce vanno oltre le "autorizzazioni rischiose" di primo livello e includono una ragnatela di relazioni transitive non documentate. 

‍

Background del servizio:

Document AI è un servizio di Google Cloud che estrae informazioni da documenti non strutturati. Offre sia modelli pre-addestrati sia una piattaforma per la creazione di modelli personalizzati. Come parte di Vertex AI, Document AI si integra con altri servizi di AI per servire e condividere modelli.

Document AI utilizza un account di servizio gestito da Google, spesso chiamato Service Agent, a cui viene assegnato il ruolo documentaicore.serviceAgent durante l'elaborazione batch dei documenti. Questo account gestisce l'ingestione, la trasformazione e l'output dei dati utilizzando le sue ampie autorizzazioni di Cloud Storage. Questo approccio riduce l'attrito per l'utente finale automatizzando la creazione dell'identità e l'assegnazione automatica delle autorizzazioni rispetto all'alternativa di utilizzare un account di servizio gestito dal cliente per l'esecuzione, che richiederebbe una configurazione esplicita e l'assegnazione manuale dei ruoli.

Descrizione della vulnerabilità

Document AI consente agli utenti di elaborare i documenti memorizzati nel Cloud Storage creando lavori online (standard) e offline (batch). Il servizio utilizza il Document AI Core Service Agent con il ruolo documentaicore.serviceAgent per gestire l'ingestione dei dati e produrre i risultati quando si esegue l'elaborazione batch. In particolare, questo agente di servizio possiede ampie autorizzazioni per accedere a qualsiasi bucket di Cloud Storage all'interno dello stesso progetto. 

A differenza dell'elaborazione online o standard, in cui il chiamante iniziale di Document AI è il principale utilizzato per recuperare gli oggetti GCS, in modalità di elaborazione batch, il recupero di qualsiasi dato di input e la scrittura dei risultati in un bucket GCS vengono eseguiti nel contesto del Document AI Core Service Agent, utilizzando i suoi permessi pre-assegnati. Poiché l'agente di servizio viene utilizzato come identità nell'elaborazione batch, i limiti di autorizzazione del chiamante iniziale non vengono rispettati, consentendo l'esfiltrazione dei dati.

Il servizio Document AI accetta una posizione di input definita dall'utente per leggere i dati pre-elaborati e una posizione di output per scrivere i risultati. Questa capacità consente a un attore malintenzionato di esfiltrare i dati dal GCS a un bucket di Cloud Storage arbitrario, aggirando i controlli di accesso ed esfiltrare informazioni sensibili.

Sfruttare il servizio (e la sua identità) per esfiltrare i dati costituisce un abuso di accesso transitivo, che aggira i controlli di accesso previsti e compromette la riservatezza dei dati.

‍

Prerequisiti

1. Elaboratore AI di documenti esistenti

Supponiamo che un processore esista in un progetto di destinazione. In questo caso, un attore malintenzionato ha bisogno solo dei permessi documentai.processors.processBatch o documentai.processorVersions.processBatch per utilizzare il processore, leggere i dati da qualsiasi bucket di Cloud Storage del progetto ed esfiltrare gli oggetti in un bucket arbitrario.

‍

2. Creazione o aggiornamento di un processore

Se in un progetto di destinazione non esiste alcun processore, un attore malintenzionato avrebbe bisogno del permesso documentai.processors.create per crearne uno adatto alla lettura da un bucket di Cloud Storage e scrivere l'output in un altro. In alternativa, un processore potrebbe essere modificato con l'autorizzazione documentai.processors.update per consentire l'inserimento tramite un bucket GCS. 

‍

3. Documento AI non utilizzato in precedenza

Se DocumentAI non è stato utilizzato in un progetto, un aggressore deve abilitare il servizio prima di creare o utilizzare un processore. L'abilitazione di nuovi servizi nei progetti GCP richiede l'autorizzazione serviceusage.services.enable Cloud IAM ed è inclusa in oltre 25 ruoli predefiniti, oltre ai ruoli a grana grossa Editor e Owner. Quando si abilita il servizio DocumentAI, vengono creati l'agente di servizio associato e il suo ruolo autoassegnato a livello di progetto, che non richiede le autorizzazioni *.setIamPolicy da parte dell'abilitatore del servizio.

‍

Prova di concetto

Vengono forniti quattro moduli Terraform per dimostrare l'esfiltrazione dei dati attraverso l'IA dei documenti. Due moduli sfruttano la funzione processors.processBatch e processorVersions.processBatch rispettivamente, sfruttando le ampie autorizzazioni dell'agente di servizio per copiare i dati da un bucket di Cloud Storage di input a un bucket di output specificato dall'utente. Al contrario, i restanti due moduli mostrano le modalità online standard, processors.process e processorVersions.process, che recuperano i dati di input nel contesto del chiamante originale, rispettando i controlli di accesso previsti. I metodi di processo batch aggirano efficacemente questi controlli eseguendo il lavoro come agente del servizio DocumentAI.    

‍

La risposta di Google 

Questo caso di abuso di accesso transitivo è stato segnalato a Google tramite il Vulnerability Reward Program il 4 aprile 2024. Dopo diversi mesi di sforzi da parte dei ricercatori per identificare la causa del problema e proporre una soluzione, Google ha accettato la segnalazione come vulnerabilità, classificandola come categoria S2C "bypass di controlli di sicurezza significativi", altri dati/sistemi. I ricercatori sono stati informati della divulgazione pubblica prevista per il 2 luglio.

Un resoconto completo della tempistica di rendicontazione può essere consultato di seguito, ma sono degni di nota i seguenti commenti/azioni:

1. Google ha stabilito che "il problema di ..... è dovuto a una documentazione insufficiente o errata".
2. Il rapporto elaborato attraverso il Vulnerability Reward Program (VRP) è stato modificato in "Fixed" (risolto) nonostante il problema persista.
3. È stato aggiunto un riquadro di attenzione al Ruoli IAM DocumentAI pagina di documentazione, avvertendo i clienti che "Le autorizzazioni per documentai.processors.create e documentai.datasets.update sono altamente privilegiati". 
   1. Il seguente riquadro di avviso è stato aggiunto qualche tempo dopo la precedente istantanea di Internet Archive del 9 dicembre 2023. Non ho modo di sapere se è stato aggiunto in risposta alla mia segnalazione.

‍

1. Google ha revocato la decisione di non assegnare la taglia, adducendo come causa principale una "documentazione insufficiente o errata". La segnalazione del bug è stata ora classificata come "aggiramento di controlli di sicurezza significativi" e ha ottenuto una taglia. Non ci sono ancora indicazioni su quando o come verrà risolto il caso di abuso.

‍

Raccomandazioni per Google

 All'Agente di servizio AI per i documenti non devono essere assegnate automaticamente autorizzazioni ampie a livello di progetto. Sebbene l'utilizzo di un account di servizio gestito da Google offra vantaggi operativi, la concessione di un accesso illimitato al Cloud Storage in combinazione con posizioni di input/output definite dall'utente introduce un rischio significativo per la sicurezza attraverso l'abuso di accesso transitivo. Il servizio potrebbe funzionare come previsto, ma non come ci si aspettava.

Impatto sui clienti di Google Cloud

Tutti i clienti di Google Cloud sono interessati da questa vulnerabilità se non impediscono l'abilitazione del servizio DocumentAI e il suo utilizzo tramite i vincoli dei criteri organizzativi elencati di seguito. Non è necessario che un cliente utilizzi DocumentAI per essere affetto da questa vulnerabilità. La semplice possibilità per un utente malintenzionato di abilitare il servizio mette a rischio di esfiltrazione i dati critici.

Quando le autorizzazioni IAM hanno effetti a catena, rispondere alla domanda "cosa potrebbe andare storto" con un determinato servizio diventa impossibile. Non è chiaro quali siano le prossime mosse di Google per proteggere i propri clienti, se intenda offrire un vincolo di Politica Organizzativa o se voglia eliminare del tutto questo caso di abuso di accesso transitivo.

‍

Mitigazioni

Purtroppo, la segnalazione presentata attraverso il Vulnerability Reward Program (VRP) di Google non ha portato ad alcuna modifica del servizio nonostante gli sforzi profusi. Le migrazioni menzionate di seguito non risolvono la vulnerabilità sottostante, ma riducono solo l'impatto potenziale del cliente. 

1. Segmentazione a livello di progetto: L'intelligenza artificiale dei documenti deve essere utilizzata in un progetto segmentato e isolato. Non combinare il servizio di IA dei documenti in un progetto contenente dati sensibili. Quando si utilizza un servizio SaaS o ETL, configurare le posizioni degli ingressi e delle uscite in modo trasversale al progetto. In questo modo si obbliga il binding manuale delle autorizzazioni IAM per qualsiasi agente di servizio, anziché affidarsi alle concessioni automatiche.

 2. Limitare l'API e il servizio: Utilizzare l'Org Policy Constraint serviceuser.services per impedire l'abilitazione del servizio Document AI quando non è necessario e limitare l'uso dell'API con l'Org Policy Constraint serviceuser.restrictServiceUsage.

‍

Conclusioni

Le concessioni di ruoli e autorizzazioni raccontano solo una parte della storia, soprattutto se si considerano le funzionalità del servizio e la possibilità di accesso transitivo. È probabile che l'abuso di accesso transitivo non sia isolato al servizio Document AI; è probabile che si ripeta in tutti i servizi (e in tutti i principali fornitori di cloud ), dato che persistono incomprensioni sui modelli di minaccia.

La segmentazione dell'archiviazione dei dati, della logica aziendale e dei carichi di lavoro in progetti diversi può ridurre il raggio d'azione di agenti di servizio eccessivamente privilegiati, ma i clienti si affidano ai fornitori di cloud per garantire che non creino percorsi di escalation dei privilegi nei loro prodotti e schemi IAM.

‍

Tempistica di segnalazione e risposta

• 4 aprile^th 2024: Rapporto iniziale: Esfiltrazione di dati tramite l'elaborazione di dati AI, edizione 332943600
  • [Google VRP]: "Salve! Grazie per aver condiviso la sua segnalazione. Questa e-mail conferma che abbiamo ricevuto il tuo messaggio. Indagheremo sul problema che hai segnalato e ti contatteremo non appena avremo un aggiornamento. Nel frattempo, potresti dare un'occhiata all' elenco di domande frequenti su Google Bug Hunters.

• 8 aprile^th 2024: Priorità modificata P4 -> P3 e Stato modificato Nuovo -> Assegnato
  • [Google VRP]: "Vogliamo solo informarla che la sua segnalazione è stata analizzata e che la stiamo esaminando".
• 9 aprile^th 2024: Il tipo cambia Problema del cliente -> Bug; la gravità cambia da S4 -> S2; lo stato cambia da Assegnato -> In corso (accettato).
  • [Google VRP]: "Grazie ancora per la segnalazione. Ho segnalato un bug al team di prodotto responsabile in base alla sua segnalazione. Il team di prodotto valuterà la sua segnalazione e deciderà se è necessaria una correzione. Le faremo sapere se il problema è stato risolto. Per quanto riguarda il nostro programma di ricompensa per le vulnerabilità: A prima vista, sembra che questo problema non sia abbastanza grave da poter essere ricompensato. Tuttavia, il gruppo VRP esaminerà il problema più da vicino durante la prossima riunione. Vi aggiorneremo una volta presa una decisione. Se non ricevete risposta entro 2-3 settimane o se avete ulteriori informazioni sulla vulnerabilità, fatecelo sapere! "
• ⁹ aprile 2024 - [Kat Traxler]: "Come sempre, grazie per il rapido triage. Se posso essere d'aiuto nel descrivere i rischi della configurazione attuale, non esiti a contattarmi. Grazie, Kat".
• ³⁰ aprile 2024 - [Kat Traxler]: "Salve, vi porto in cima alla vostra casella di posta. Vorrei sapere se è stato considerato un rischio di abuso o se è previsto un aggiornamento del servizio. Grazie, Kat".
• ² maggio 2024 - [Google VRP]: "Salve! I membri della commissione non hanno ancora preso una decisione su questo rapporto; la commissione si riunisce due volte a settimana e il vostro rapporto viene preso in considerazione in ogni riunione. Ci scusiamo per il ritardo e vi ringraziamo per la vostra pazienza. Riceverà un'e-mail automatica una volta presa una decisione".
• ² maggio 2024 - [Kat Traxler]: "Grazie per l'aggiornamento. Se non avrò notizie entro circa 4 settimane, farò un altro ping".
• ⁷ maggio 2024 - [Google VRP]: "** NOTA: Questa è un'e-mail generata automaticamente **Salve, la commissione del Google Vulnerability Reward Program ha deciso che l'impatto sulla sicurezza di questo problema non soddisfa i requisiti per una ricompensa finanziaria. Tuttavia, vorremmo riconoscere il tuo contributo alla sicurezza di Google nella nostra pagina delle menzioni d'onore all'indirizzo https://bughunters.google.com/leaderboard/honorable-mentions. Se desiderate essere aggiunti alla pagina, create un profilo all'indirizzo https://bughunters.google.com, se non l'avete ancora fatto. Motivazione della decisione: Abbiamo stabilito che il problema è dovuto a una documentazione insufficiente o errata. Il fatto che questo problema non venga premiato non significa che il team di prodotto non lo risolverà. Abbiamo segnalato il problema al team di prodotto. Esaminerà la segnalazione e deciderà se è necessaria una correzione. Vi faremo sapere se il problema è stato risolto. Saluti, Google Security Bot".
• ⁷ maggio 2024: - [Kat Traxler]: "Grazie per la risposta!"
• 22 giugno^nd 2024: Stato modificato in "Fisso".
  • [Google VRP]: "I nostri sistemi mostrano che tutti i bug creati in base alla sua segnalazione sono stati risolti dal team di prodotto. Sentiti libero di controllare e di farci sapere se a te sembra tutto a posto. Grazie ancora per il tuo aiuto!".
• ²⁵ giugno 2024 - [Kat Traxler]: "Salve. Ho riscontrato che questo problema persiste. I documenti e i dati di formazione possono essere esportati utilizzando le autorizzazioni del Document AI Core Service Agent, consentendo a un utente che non ha accesso all'archiviazione di esfiltrare i dati. Si noti che questa funzionalità esiste nei metodi: google.cloud.documentai.uiv1beta3.DocumentService.ExportDocuments e nelle funzionalità di elaborazione batch: (processors.batchProcess & processorVersions.batchProcess & processors.batchProcess) Fatemi sapere se avete bisogno di ulteriori POC".
• ²⁶ giugno 2024 - [Google VRP]: "Ciao! Grazie per la tua risposta, abbiamo aggiornato il bug interno per il team che sta lavorando al problema".
• ² luglio 2024 - [Kat Traxler]: "Salve. Dato il recente 'falso allarme' che questo problema era stato risolto, ho iniziato a temere di non aver comunicato il rischio e l'impatto in modo appropriato. Pertanto, ho creato un'installazione TF e ho registrato un POC per voi e per il team di assistenza. L'implementazione TF è disponibile all'indirizzo: https://github.com/KatTraxler/document-ai-samples POC video a questo link. Il punto che deve essere ribadito è che il principale che può elaborare (o elaborare in batch) i documenti con Document AI non deve avere i permessi di archiviazione per accedere ai dati nel Cloud Storage e spostarli in un'altra posizione (esfiltrazione dei dati). (roles/documentaicore.serviceAgent). Consiglio di assegnare a Document AI un account di servizio per l'elaborazione dei dati, simile a quello di Cloud Workflows. Consentire al P4SA di spostare i dati definiti dall'utente non è il modello corretto e ha portato a una vulnerabilità di esfiltrazione dei dati. Modificare lo stato di questo problema per indicare che non è stato risolto. La divulgazione al pubblico avverrà in occasione di un evento di alto profilo nel settembre 2024".
• ⁴ luglio 2024 - [Google VRP]: "Salve! Grazie per le ulteriori informazioni sul caso, chiederemo al team di prodotto. Inoltre, grazie per averci avvisato della divulgazione del vostro rapporto. Vi invitiamo a leggere la nostra posizione sulla divulgazione coordinata. In sostanza, il nostro impegno nei vostri confronti è quello di rispondere prontamente e di risolvere le vulnerabilità in tempi ragionevoli; in cambio, chiediamo un ragionevole preavviso".
• ²⁹ luglio 2024 - [Kat Traxler]: "Ciao Team. Vi avviso ancora una volta che parlerò del rischio di esfiltrazione dei dati tramite il servizio DocumentAI al fwd:CloudsecEU il 17 settembre: https://pretalx.com/fwd-cloudsec-europe-2024/talk/BTT9LJ/ Con un blog di accompagnamento da pubblicare il giorno prima, il 16 settembre. Grazie, Kat".
• ³⁰ luglio 2024 - [Google VRP]: "Ciao, grazie mille per avermi avvisato!".
• ⁵ agosto 2024 - [Kat Traxler]: "Grazie. Posso suggerire di cambiare lo stato di questo rapporto da "Risolto"? Dal momento che non è stato risolto, grazie ancora. Kat"
• ¹² agosto 2024 - [Google VRP]: "Salve, sarebbe possibile condividere con noi una bozza della presentazione e/o del post sul blog prima della divulgazione? Grazie"
• ¹² agosto 2024: Commento di Kat Traxler: "Sono più che felice di farlo. Mi interessa soprattutto il tuo feedback per l'accuratezza e il coordinamento delle informazioni. Il post sul blog sarà pronto per il²⁶ agosto^".
• ¹³ agosto 2024 - [Google VRP]: "CIAO! Grazie!"
• ²¹ agosto 2024 - [Google VRP]: "Ciao Kat, Grazie ancora per la tua segnalazione e per la tua pazienza! Il team si è appena riunito e ha discusso la tua segnalazione in modo molto più dettagliato. Abbiamo deciso di segnalare un bug al team di prodotto dopo aver valutato se si trattasse di WAI o di una vulnerabilità. Lo abbiamo fatto perché il comportamento non è chiaro dal vostro punto di vista, ma il team di prodotto è nella posizione migliore per determinare se qualcosa è WAI o meno. Il bug interno è stato effettivamente riaperto il 9 luglio sulla base del vostro commento e lavoreremo con il team di prodotto per prendere questa decisione. Riapriremo anche il problema 332943600 per riflettere questo fatto - questo sarebbe dovuto accadere a luglio, mi dispiace! Ancora una volta, grazie per averci contattato e per la segnalazione!
  Il team di Google Bug Hunter".
• ²² agosto 2024 - [Kat Traxler]: "Grazie per l'aggiornamento e il cambiamento di stato. Siete in grado di condividere le vostre definizioni di WAI e di vulnerabilità? Per me, un problema può funzionare come previsto (WAI) e avere un impatto negativo significativo sulla sicurezza. Grazie. Kat"
• ⁹ settembre 2024 - [Google VRP]: "Il panel del Google Vulnerability Reward Program ha deciso di emettere una ricompensa di 3133,70 dollari per la tua segnalazione". Congratulazioni! Motivo della decisione: Applicazioni Google normali. La categoria di vulnerabilità è "bypass di controlli di sicurezza significativi", altri dati/sistemi. Abbiamo applicato un downgrade perché l'attaccante deve avere accesso a un progetto della vittima impattata".

 Ricerca correlata

 Per ulteriori informazioni sugli agenti di servizio GCP e sui loro modelli di minaccia, consultare la serie GCP IAM 201 che tratta questi argomenti:

• GCP IAM 201 - Agenti di servizio
• GCP IAM 201 - Modello di minaccia dell'agente di servizio

‍