Cloudflare corregge una perdita di dati cross-tenant nei Containers

Cloudflare ha corretto una significativa vulnerabilità di perdita di dati cross-tenant nel suo servizio Containers che, se sfruttata attivamente, avrebbe potuto consentire a un cliente di leggere file residui lasciati da container di altri clienti sullo stesso host fisico. La falla, segnalata da un ricercatore di sicurezza tramite il programma bug bounty dell'azienda, è stata risolta automaticamente e non richiede alcuna azione da parte degli utenti Cloudflare.

I Containers di Cloudflare sono una funzionalità inclusa nel piano Workers Paid che consente agli sviluppatori di eseguire le proprie applicazioni all'interno di ambienti leggeri e isolati noti come container. Vengono comunemente utilizzati da aziende che realizzano servizi backend, elaborano job o eseguono piattaforme di esecuzione di codice sull'infrastruttura Cloudflare. Ogni container dovrebbe essere isolato dagli altri, ma la debolezza appena scoperta ha compromesso tale separazione, sollevando preoccupazioni sulla sicurezza dei servizi cloud multi-tenant per applicazioni sensibili ai dati.

Il problema è stato scoperto da Oren Yomtov, ricercatore di sicurezza presso la società tecnologica Accomplish, che lo ha segnalato sulla piattaforma HackerOne il 4 settembre. La successiva comunicazione di Cloudflare spiega che il problema era presente in un pool di storage condiviso che, in determinate circostanze, saltava il processo di azzeramento (sovrascrittura con zeri) dei blocchi di storage fisico da 64 kibibyte (64 KiB) riutilizzati prima di assegnarli a un nuovo container.

Ecco come funzionava la vulnerabilità. Quando un container viene eliminato, il thin volume che supporta il suo disco radice viene rimosso e i suoi blocchi fisici vengono restituiti a un pool condiviso che serve più clienti. Normalmente, prima che tali blocchi vengano riallocati, dovrebbero essere azzerati per cancellare eventuali dati residui. Tuttavia, un errore di configurazione ha causato il salto dell'azzeramento. I ricercatori hanno quindi dimostrato che scrivendo solo 4 KiB di dati in un'area inutilizzata del disco di un container appena creato, potevano forzare l'allocazione di un blocco fisico da 64 KiB riutilizzato. Poiché l'azzeramento era assente, solo i 4 KiB scritti sovrascrivevano il blocco; i restanti 60 KiB conservavano le informazioni lasciate dal container del cliente precedente. Si tratta essenzialmente di un classico problema di memoria non inizializzata, applicato allo storage persistente.

Nei loro test, Yomtov e i suoi colleghi hanno trovato materiale residuo su 18 dei 24 posizionamenti di container e su 20 dei 22 nodi fisici sottostanti esaminati. Questi dati residui includevano strutture di directory, pagine di database dal motore di database embedded basato su file comune nelle applicazioni web, frammenti di profili Chromium e file come file di configurazione .env e file di credenziali, tutti potenzialmente leggibili da un utente malintenzionato con un account Workers Paid sullo stesso host.

Cloudflare sottolinea che un utente malintenzionato non avrebbe avuto alcun controllo su quale specifico cliente avrebbe recuperato i dati, né avrebbe potuto leggere un disco attivamente collegato. Gli script del ricercatore hanno solo eseguito controlli che restituivano numeri aggregati di blocchi esposti, senza mai recuperare contenuti di file effettivamente leggibili. Di conseguenza, nessun dato reale di alcun cliente è stato esposto durante questa ricerca.

Dopo aver corretto la configurazione che saltava l'azzeramento dei blocchi, Cloudflare ha ritirato i dischi dei container esistenti e cancellato eventuali snapshot memorizzate nella cache che potevano ancora contenere mappature non aggiornate. Tutte le operazioni di mitigazione sono state completate entro il 19 settembre. L'azienda ha inoltre esaminato log interni, telemetria e dati storici e non ha trovato prove che dati di clienti fossero stati esposti tramite questo metodo al di fuori dei test controllati del ricercatore.

Poiché la patch è stata applicata automaticamente all'infrastruttura di Cloudflare, i clienti non devono aggiornare nulla né adottare misure particolari per proteggersi da questa specifica falla. Per chiunque esegua applicazioni su infrastrutture cloud condivise, tuttavia, l'incidente sottolinea una lezione più ampia: la gestione dei dati eliminati da parte del livello di storage è fondamentale per la sicurezza multi-tenant.

Per i proprietari di siti web e le aziende che ospitano i propri siti o applicazioni presso un provider, la separazione tra gli ambienti dei clienti è una delle garanzie più importanti. Un servizio di hosting progettato con un rigoroso isolamento tra tenant, come la piattaforma WordPress gestita di AEU Hosting, garantisce che i dati di un cliente non possano accidentalmente trapelare in quelli di un altro. Quando si valuta un provider di hosting o cloud, è saggio chiedere come viene effettuata la sanificazione dello storage tra tenant e quanto rapidamente vengono corrette le vulnerabilità gravi. In questo caso non è richiesta alcuna azione da parte degli utenti Cloudflare, ma il principio di base si applica ampiamente: sapere sempre come il proprio provider gestisce i dati dei clienti che condividono lo stesso hardware fisico.