Abuso dell'accesso transitivo - Esfiltrazione dei dati tramite Document AI

¹⁶ settembre 2024

TLDR;

Il servizio Document AI consente involontariamente agli utenti di leggere qualsiasi oggetto Cloud nello stesso progetto.

• Configurazione errata del servizio Document AI: all'agente del servizio Document AI vengono assegnate automaticamente autorizzazioni eccessive, che gli consentono di accedere a tutti gli oggetti dai bucket Cloud nello stesso progetto.
• Rischio di esfiltrazione dei dati: gli autori di attacchi malintenzionati possono sfruttare questa vulnerabilità per esfiltrare dati dal Cloud sfruttando indirettamente le autorizzazioni dell'agente di servizio.
• Abuso di accesso transitivo: questa vulnerabilità è un esempio di abuso di accesso transitivo, una classe di falle di sicurezza in cui l'accesso non autorizzato viene ottenuto indirettamente tramite un intermediario affidabile. 
• Impatto sui Cloud Google Cloud : con questo caso di abuso, le minacce vanno oltre le "autorizzazioni rischiose" di primo livello per includere una rete di relazioni transitive non documentate. 

‍

Contesto del servizio:

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

Document AI utilizza un account di servizio gestito da Google, spesso denominato Service Agent, a cui viene assegnato il ruolo documentaicore.serviceAgent durante l'elaborazione in batch dei documenti. Questo account gestisce l'acquisizione, la trasformazione e l'output dei dati utilizzando le sue ampie autorizzazioni Cloud . 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 archiviati nel Cloud creando sia lavori online (standard) che lavori di elaborazione offline (batch). Il servizio utilizza Document AI Core Service Agent con il ruolo documentaicore.serviceAgent per gestire l'acquisizione dei dati e produrre i risultati durante l'elaborazione batch. È fondamentale sottolineare che questo agente di servizio dispone di ampie autorizzazioni per accedere a qualsiasi bucket Cloud 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, nella 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 le autorizzazioni preassegnate. Poiché il Service Agent viene utilizzato come identità nell'elaborazione batch, le limitazioni delle autorizzazioni del chiamante iniziale non vengono rispettate, 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 funzionalità consente a un malintenzionato di sottrarre dati da GCS e trasferirli in un bucket Cloud arbitrario, aggirando i controlli di accesso e sottraendo informazioni sensibili.

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

‍

Requisiti

1. Processore AI per documenti esistenti

Supponiamo che in un progetto di destinazione sia presente un processore. In tal caso, un malintenzionato necessita solo dell'autorizzazione documentai.processors.processBatch o documentai.processorVersions.processBatch per utilizzare il processore, leggere i dati da qualsiasi bucket Cloud nel progetto ed esfiltrare gli oggetti in un bucket arbitrario.

‍

2. Creazione o aggiornamento di un processore

Se nel progetto di destinazione non è presente alcun processore, un malintenzionato avrebbe inoltre bisogno dell'autorizzazione documentai.processors.create per crearne uno adatto alla lettura da un bucket Cloud e scrivere l'output in un altro. In alternativa, un processore potrebbe essere modificato con l'autorizzazione documentai.processors.update per consentire l'acquisizione tramite un bucket GCS. 

‍

3. Document AI non utilizzato in precedenza

Se DocumentAI non è stato utilizzato in un progetto, un utente malintenzionato deve abilitare il servizio prima di creare o utilizzare un processore. L'abilitazione di nuovi servizi nei progetti GCP richiede l'autorizzazione Cloud serviceusage.services.enable ed è inclusa in oltre 25 ruoli predefiniti insieme ai ruoli generici Editor e Proprietario. Quando si abilita il servizio DocumentAI, vengono creati l'agente di servizio associato e il suo ruolo a livello di progetto assegnato automaticamente, senza richiedere autorizzazioni *.setIamPolicy da parte dell'abilitatore del servizio.

‍

Prova di concetto

Sono disponibili quattro moduli Terraform per dimostrare l'esfiltrazione dei dati tramite Document AI. Due moduli sfruttano i processors.processBatch e processorVersions.processBatch , sfruttando le ampie autorizzazioni dell'agente di servizio per copiare i dati da un bucket Cloud 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 elaborazione batch aggirano efficacemente questi controlli eseguendo il processo come agente di servizio DocumentAI.    

‍

La risposta di Google 

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

Di seguito è possibile consultare un resoconto completo della tempistica di segnalazione; tuttavia, è opportuno sottolineare i seguenti commenti/azioni:

1. Google ha stabilito che "... il problema è dovuto a una documentazione insufficiente o errata".
2. Lo stato della segnalazione, valutata attraverso il loro Vulnerability Reward Program (VRP), è stato modificato in "Risolto" nonostante il problema persista.
3. È stata aggiunta una casella di avviso al Ruoli IAM di DocumentAI pagina della documentazione, avvertendo i clienti che "Le autorizzazioni per documentai.processori.crea e ddocumentai.datasets.update sono altamente privilegiati”. 
   1. Il seguente riquadro di avviso è stato aggiunto qualche tempo dopo l'ultima istantanea dell'Internet Archive del 9 dicembre 2023. Non ho modo di sapere se sia stato aggiunto in risposta alla mia segnalazione.

‍

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

‍

Raccomandazioni per Google

 All'agente del servizio Document AI non devono essere assegnate automaticamente autorizzazioni di ampio respiro a livello di progetto. Sebbene l'utilizzo di un account di servizio gestito da Google offra vantaggi operativi, concedergli un accesso illimitato Cloud in combinazione con posizioni di input/output definite dall'utente comporta un rischio significativo per la sicurezza a causa dell'abuso dell'accesso transitivo. Il servizio potrebbe funzionare come previsto, ma non come desiderato.

Impatto sui Cloud Google Cloud

Tutti Cloud Google Cloud sono interessati da questa vulnerabilità se non impediscono l'abilitazione del servizio DocumentAI e il suo utilizzo tramite i vincoli delle politiche organizzative elencati di seguito. Attualmente, non è necessario che un cliente utilizzi DocumentAI per essere interessato dalla vulnerabilità. La semplice possibilità per un aggressore di abilitare il servizio mette a rischio di esfiltrazione i dati critici.

Quando le autorizzazioni IAM hanno effetti a catena l'una sull'altra, rispondere alla domanda "Cosa potrebbe andare storto" con un determinato servizio diventa impossibile. Non è chiaro quali saranno i prossimi passi di Google per proteggere i propri clienti, se intendono offrire un vincolo di politica organizzativa o se rimuoveranno del tutto questo caso di abuso di accesso transitivo.

‍

Mitigazioni

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

1. Segmentazione a livello di progetto: Document AI deve essere utilizzato in un progetto segmentato e isolato. Non combinare il servizio Document AI in un progetto contenente dati sensibili. Quando si utilizza un servizio SaaS o ETL, configurare le posizioni di input e output tra i progetti. Ciò costringerà il binding manuale delle autorizzazioni IAM per qualsiasi agente di servizio, anziché affidarsi alle concessioni automatiche.

 2. Limitare l'API e il servizio: utilizzare il vincolo di politica dell'organizzazione serviceuser.services per impedire l'abilitazione del servizio Document AI quando non è necessario e limitare l'utilizzo dell'API con il vincolo di politica dell'organizzazione serviceuser.restrictServiceUsage.

‍

Conclusioni

I ruoli e le autorizzazioni concesse raccontano solo una parte della storia, soprattutto se si considerano le funzionalità del servizio e la possibilità di accesso transitivo. L'abuso dell'accesso transitivo non è probabilmente limitato al servizio Document AI, ma è probabile che si ripeta in tutti i servizi (e presso tutti i principali cloud ) fintanto che persisteranno le incomprensioni sui modelli di minaccia.

La segmentazione dell'archiviazione dei dati, della logica aziendale e dei carichi di lavoro in diversi progetti può ridurre il raggio d'azione degli agenti di servizio con privilegi eccessivi, ma i clienti si affidano ai 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 elaborazione dati Document AI, Problema 332943600
  • [Google VRP]: "Ciao! Grazie mille per aver condiviso la tua segnalazione. Questa email conferma che abbiamo ricevuto il tuo messaggio. Esamineremo il problema che hai segnalato e ti ricontatteremo non appena avremo aggiornamenti. Nel frattempo, ti invitiamo a consultare l' elenco delle domande frequenti su Google Bug Hunters.

• 8 aprile^th 2024: Priorità modificata da P4 a P3 e Stato modificato da Nuovo a Assegnato
  • [Google VRP]: "Desideriamo informarvi che la vostra segnalazione è stata esaminata e che al momento la stiamo valutando."
• 9 aprile^th 2024: Modifiche al tipo Problema cliente -> Bug; Gravità modificata da S4 -> S2; Stato modificato da Assegnato -> In corso (accettato)
  • [Google VRP]: "Grazie ancora per la segnalazione. Ho segnalato il bug al team di prodotto responsabile sulla base della tua segnalazione. Il team di prodotto valuterà la tua segnalazione e deciderà se è necessaria una correzione. Ti faremo sapere se il problema è stato risolto. Per quanto riguarda il nostro programma di ricompensa per la segnalazione di vulnerabilità: a prima vista, sembra che questo problema non sia abbastanza grave da giustificare una ricompensa. Tuttavia, il comitato VRP esaminerà più attentamente la questione nella sua prossima riunione. Ti aggiorneremo non appena avremo preso una decisione. Se non riceverai alcuna risposta da parte nostra entro 2-3 settimane o se avrai ulteriori informazioni sulla vulnerabilità, faccelo sapere! "
• ⁹ aprile 2024 - [Kat Traxler]: "Come sempre, grazie per la rapida valutazione. Se posso essere d'aiuto nel descrivere i rischi della configurazione attuale, non esitate a contattarmi. Grazie, Kat"
• ³⁰ aprile 2024 - [Kat Traxler]: "Salve, riporto questo messaggio in cima alla vostra casella di posta. Vorrei sapere se è stato valutato come rischio di abuso o se sono previsti aggiornamenti al servizio. Grazie, Kat".
• ² maggio 2024 - [Google VRP]: "Salve! I membri della commissione non hanno ancora preso una decisione in merito alla Sua segnalazione; la commissione si riunisce due volte alla settimana e la Sua segnalazione viene presa in considerazione ad ogni riunione. Ci scusiamo per il ritardo e La ringraziamo per la Sua pazienza. Riceverà un'e-mail automatica una volta che sarà stata presa una decisione."
• ² maggio 2024 - [Kat Traxler]: "Grazie per l'aggiornamento. Se non riceverò notizie entro circa 4 settimane, vi ricontatterò".
• ⁷ maggio 2024 - [Google VRP]: "** NOTA: questa è un'e-mail generata automaticamente ** Salve, il comitato del Programma di ricompensa per le vulnerabilità di Google ha deciso che l'impatto sulla sicurezza di questo problema non soddisfa i requisiti per una ricompensa finanziaria. Tuttavia, desideriamo 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 desideri essere aggiunto, crea un profilo all'indirizzo https://bughunters.google.com, se non l'hai già fatto. Motivazione di questa decisione: abbiamo stabilito che il problema è dovuto a una documentazione insufficiente o errata. Si prega di notare che il fatto che questo problema non venga ricompensato non significa che il team di prodotto non lo risolverà. Abbiamo segnalato il bug al team di prodotto. Esamineranno la tua segnalazione e decideranno se è necessaria una correzione. Ti faremo sapere se il problema è stato risolto. Cordiali saluti, Google Security Bot"
• ⁷ maggio 2024: - [Kat Traxler]: "Grazie per la risposta!"
• 22 giugno^nd 2024: Stato modificato in "Risolto"
  • [Google VRP]: "I nostri sistemi indicano che tutti i bug che abbiamo creato sulla base della tua segnalazione sono stati risolti dal team di prodotto. Verificalo e facci sapere se da parte tua sembra tutto a posto. Grazie ancora per il tuo aiuto!"
• ²⁵ giugno 2024 - [Kat Traxler]: "Salve. Ho riscontrato che il problema persiste. I documenti e i dati di addestramento possono essere esportati utilizzando le autorizzazioni dell'agente del servizio Document AI Core, consentendo a un utente che non ha accesso all'archiviazione di estrarre i dati. Si noti che questa funzionalità è presente nei metodi: google.cloud.documentai.uiv1beta3.DocumentService.ExportDocuments e nelle funzionalità di elaborazione batch: (processors.batchProcess & processorVersions.batchProcess & processors.batchProcess). Mi faccia sapere se ha 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. Considerato il recente 'falso allarme' secondo cui il problema era stato risolto, ho iniziato a preoccuparmi di non aver comunicato adeguatamente il rischio e l'impatto. Pertanto, ho creato una distribuzione TF e registrato un POC affinché voi e il team di assistenza poteste visionarlo. L'implementazione TF è disponibile all'indirizzo: https://github.com/KatTraxler/document-ai-samples Il video POC è disponibile a questo link. Il punto che deve essere ribadito è che il responsabile che può elaborare (o elaborare in batch) i documenti con Document AI non ha bisogno di autorizzazioni di archiviazione per accedere ai dati nel Cloud e spostarli in un'altra posizione (esfiltrazione dei dati). Ciò è possibile grazie alle autorizzazioni assegnate al Document AI P4SA. (roles/documentaicore.serviceAgent). Raccomando che a Document AI venga assegnato un account di servizio gestito dall'utente per l'elaborazione dei dati, simile a Cloud . Consentire al P4SA di spostare i dati definiti dall'utente non è il modello corretto e ha portato a una vulnerabilità di esfiltrazione dei dati. Si prega di modificare lo stato di questo problema per indicare che non è stato risolto. La divulgazione pubblica avverrà in occasione di un evento di alto profilo nel settembre 2024".
• ⁴ luglio 2024 - [Google VRP]: "Salve! Grazie per le ulteriori informazioni sul caso, contatteremo il team di prodotto. Grazie anche per averci avvisato in merito alla divulgazione della vostra segnalazione. Vi invitiamo a leggere la nostra posizione sulla divulgazione coordinata. In sostanza, il nostro impegno nei vostri confronti è quello di rispondere prontamente e correggere le vulnerabilità in un lasso di tempo ragionevole e, in cambio, chiediamo un preavviso ragionevole".
• ²⁹ luglio 2024 - [Kat Traxler]: "Ciao a tutti. Vi informo nuovamente che il 17 settembre parlerò del rischio di esfiltrazione dei dati tramite il servizio DocumentAI al fwd:CloudsecEU: https://pretalx.com/fwd-cloudsec-europe-2024/talk/BTT9LJ/ Il giorno prima, il 16 settembre, verrà pubblicato un blog di accompagnamento. Grazie, Kat".
• ³⁰ luglio 2024 - [Google VRP]: "Ciao. Grazie mille per l'informazione!"
• ⁵ agosto 2024 - [Kat Traxler]: "Grazie. Posso suggerire di modificare lo stato di questo rapporto da "Risolto"? Poiché 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: "Ne sarò più che felice. Sono particolarmente interessata al tuo feedback per quanto riguarda l'accuratezza e il coordinamento delle comunicazioni. Il post sul blog sarà pronto entro il 26 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 il bug al team di prodotto dopo aver valutato se si trattasse di un problema WAI o di una vulnerabilità. Abbiamo agito in questo modo perché il comportamento non è chiaro dal tuo punto di vista, ma il team di prodotto è nella posizione migliore per determinare se si tratta di un problema WAI o meno. Il bug interno è stato effettivamente riaperto il 9 luglio sulla base del tuo commento e lavoreremo con il team di prodotto per prendere una decisione in merito. Riapriremo anche il problema 332943600 per riflettere questa decisione: avremmo dovuto farlo a luglio, ci scusiamo! Grazie ancora per averci contattato e per la tua segnalazione!
  Il team Google Bug Hunter
• ²² agosto 2024 - [Kat Traxler]: "Grazie per l'aggiornamento e la modifica dello stato. Potresti condividere le tue definizioni di WAI e vulnerabilità? A mio avviso, un problema può essere sia funzionante come previsto (WAI) sia avere un impatto negativo significativo sulla sicurezza. Grazie. Kat"
• ⁹ settembre 2024 - [Google VRP]: "Il comitato del Google Vulnerability Reward Program ha deciso di assegnare un premio di 3133,70 dollari per la tua segnalazione. Congratulazioni! Motivazione della decisione: applicazioni Google normali. La categoria di vulnerabilità è "aggiramento di controlli di sicurezza significativi", altri dati/sistemi. Abbiamo applicato un downgrade perché l'autore dell'attacco deve avere accesso al progetto della vittima colpita".

 Ricerca correlata

 Per ulteriori informazioni sugli agenti di servizio GCP e sui relativi 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

‍