La ricerca Unit 42 rivela come nomi bucket unici globalmente permettano reindirizzamento silenzioso di log e messaggi tra account cloud. Cross-CSP.
Unit 42 di Palo Alto Networks ha pubblicato una ricerca che demolisce un assunto fondamentale dell'architettura cloud: la cancellazione di un bucket di storage non ne garantisce la morte definitiva. I ricercatori dimostrano che un attaccante con permessi di eliminazione può ricrearlo con lo stesso nome sotto il proprio account, intercettando silenziosamente flussi di dati attivi senza modificare alcuna configurazione sorgente. La tecnica, testata con successo su 3 servizi Google Cloud, espone una debolezza strutturale cross-provider che lega l'identità della destinazione al nome del bucket, non a un proprietario immutabile.
Punti chiave
- L'unicità globale dei nomi bucket crea un namespace condiviso dove la proprietà è volatile, non permanente: chi detiene il nome detiene il flusso
- La ricerca documenta simulazioni riuscite su Cloud Logging, Pub/Sub e Storage Transfer Service, con esfiltrazione effettiva di log e messaggi
- Servono 2 permessi GCS specifici: storage.objects.delete per svuotare il bucket e storage.bucket.delete per eliminarlo
- Unit 42 ha notificato 3 CSP — Google Cloud, AWS e Microsoft Azure; non è stata rilevata exploitation in-the-wild al momento della pubblicazione
Il binding che si rompe: nome globale, proprietà fluida
L'architettura dei principali provider cloud assegna ai bucket di storage nomi univoci a livello globale. Questo design, come osservano i ricercatori di Palo Alto Networks, "semplifica l'instaurazione dei flussi di dati" tra servizi: una volta noto il nome, qualsiasi componente può indirizzarvi dati senza ulteriori verifiche di proprietà. L'identità della destinazione è il nome stesso, non un identificatore di account persistente. La ricerca mostra che questa economia architetturale nasconde una falla strutturale. Quando un bucket viene eliminato, il suo nome torna disponibile nell'namespace globale. Un attaccante che abbia ottenuto i permessi necessari — storage.objects.delete per svuotare il contenuto e storage.bucket.delete per l'eliminazione definitiva — può ricrearlo immediatamente sotto il proprio progetto. I servizi sorgente, configurati per scrivere su quel nome specifico, continuano a farlo ignari del cambio di proprietario."Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk." — Unit 42 researchers, Palo Alto Networks
Tre servizi, un pattern: logging, messaggi e trasferimenti
I ricercatori hanno costruito dimostrazioni funzionanti su 3 servizi Google Cloud rappresentativi. Nel primo scenario, un sink di Cloud Logging configurato per scrivere log in un bucket GCS continua a riversarvi dati dopo che l'attaccante ha eliminato il bucket originale e ricreato lo stesso nome nel proprio progetto. I log, potenzialmente contenenti informazioni sensibili di sistema e applicazione, finiscono direttamente nell'ambiente attaccante. Il secondo scenario coinvolge Pub/Sub: una subscription con destinazione GCS, dopo la ricreazione del bucket sotto controllo attaccante, smista messaggi interi verso il nuovo proprietario. La ricerca documenta una simulazione in 5 passi che conclude con l'esfiltrazione effettiva del messaggio. Il terzo caso riguarda Storage Transfer Service, dove un transfer job GCS-to-GCS, una volta intercettato tramite ghost bucket, può deviare interi dataset verso account non autorizzati. Unit 42 sottolinea che questi 3 servizi costituiscono un "sottoinsieme rappresentativo" di una superficie più ampia: il pattern è sistemico, non limitato a casi isolati.Cosa fare adesso
Le organizzazioni che operano su Google Cloud possono adottare misure immediate e specifiche per ridurre la superficie di attacco documentata da Unit 42. Auditare i permessi IAM che includono storage.objects.delete e storage.bucket.delete. Questi 2 permessi specifici sono il prerequisito tecnico dell'attacco: la loro sovrallocazione a ruoli, service account o utenti che non richiedono capacità di eliminazione bucket costituisce il vettore di ingresso documentato. Verificare le configurazioni di Cloud Logging, Pub/Sub e Storage Transfer Service che puntano a bucket GCS. La ricerca ha dimostrato la vulnerabilità su questi 3 servizi: ogni sink, subscription o transfer job con destinazione bucket va ispezionato per confermare che il bucket di destinazione sia sotto controllo dell'organizzazione proprietaria del flusso. Monitorare gli eventi di eliminazione e ricreazione bucket nel proprio progetto e nei progetti connessi. Sebbene la ricerca non documenti controlli nativi automatici per la riutilizzazione di nomi, gli audit log di Google Cloud registrano le operazioni di delete e create sui bucket: la correlazione temporale di questi eventi su nomi identici è l'indicatore principale disponibile per rilevare pattern sospetti.La catena di trust che non esiste
La ricerca evidenzia un vuoto nella catena di fiducia del cloud: tra il servizio che genera dati e il bucket che li riceve non intercorre alcuna verifica crittografica o contrattuale di proprietà. Il routing si fonda su un nome di risorsa, non su un'identità attestata. Questo è diverso da altri pattern di attacco cloud — come il DNS hijacking o il subdomain takeover — dove almeno la superficie di attacco è riconducibile a registrazioni pubbliche e tempistiche di scadenza notorie. Nel caso del ghost bucket, l'attacco è istantaneo: non c'è intervallo di propagazione, non c'è TTL, non c'è cache da inquinare. La ricreazione del nome è atomica rispetto alla disponibilità del namespace. Unit 42 ha condiviso i risultati con Google Cloud, Amazon Web Services e Microsoft Azure. Lo stato delle eventuali contromisure resta non documentato al momento della pubblicazione. La ricerca non riporta risposte ufficiali dei vendor né timeline di intervento."This could have led to the exfiltration of the target's data to the attacker's account." — Unit 42 researchers
Quello che resta da chiarire
Il dossier lascia aperte questioni operative rilevanti. Non specifica se i log di audit dei provider registrino la sequenza delete-recreate con dettaglio sufficiente a consentire forensics retrospettive, né se esistano API o strumenti nativi per bloccare la riutilizzazione di un nome di bucket dopo l'eliminazione. Non documenta se la tecnica sia replicabile con bucket in regioni diverse o con requisiti di località geografica che vincolino la ricreazione. La portata cross-CSP — affermata dalla ricerca come potenziale, data la condivisione del pattern di namespace globale — non è stata verificata con simulazioni equivalenti su AWS S3 o Azure Blob Storage. I ricercatori hanno notificato i 3 provider, ma il brief non riporta risposte né conferme di riproducibilità."We have not yet identified a real-world threat actor using this attack technique. However, we recommend organizations take steps now to head off the potential impact, particularly since we anticipate that real-world attempts to use this attack technique would be difficult to detect." — Unit 42 researchersL'assenza di exploitation documentata non mitiga il rischio architetturale: la barriera all'ingresso è bassa — 2 permessi IAM sovrallocati — e la furtività è intrinseca al design. Per le organizzazioni cloud, l'insight più disruptivo della ricerca non è tecnico ma concettuale: la cancellazione, nella logica delle operazioni, segna una fine; nel namespace globale dei bucket, può segnare l'inizio di una compromissione persistente.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.