Bit of a Close Talker: A Practical Guide to Serverless Cloud Co-Location Attacks
Questo articolo presenta una metodologia completa per sfruttare le vulnerabilità negli scheduler cloud serverless al fine di ottenere la co-locazione fisica per attacchi side-channel micro-architetturali, dimostra attacchi riusciti su importanti piattaforme come Microsoft Azure Functions e propone uno scheduler "Double-Dip" come strategia di mitigazione.
Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Il quadro generale: l'hotel "Serverless"
Immaginate il mondo del cloud computing come un enorme hotel.
- Cloud Tradizionale (Serverful): Affittate una stanza intera per voi. Pagate per la stanza anche se ci dormite solo 5 minuti o 24 ore.
- Cloud Serverless: Pagate solo per l'esatto tempo in cui trascorrete nella stanza. Se avete bisogno di una stanza per 10 secondi per consegnare un pacco, pagate per 10 secondi. Il personale dell'hotel (il provider cloud) si occupa di tutto: pulizia, chiavi e manutenzione. Voi vi presentate, fate la vostra cosa e ve ne andate.
Questo è fantastico per risparmiare denaro ed essere flessibili. Ma, poiché l'hotel è così efficiente, cerca di stipare quanti più ospiti possibile nelle stesse stanze per risparmiare spazio. Questo crea un rischio di sicurezza: estranei potrebbero finire nella stessa stanza con voi.
Il problema: l'attacco del "Close Talker" (Chi parla troppo vicino)
Nel mondo dei computer, esistono trucchi subdoli chiamati attacchi side-channel. Immaginate un ladro che cerca di rubare la vostra carta di credito. Non può scassinare la vostra cassaforte, ma se sta proprio accanto a voi nella stessa stanza, può sentire il vostro battito cardiaco o il calore del vostro computer per indovinare la vostra password.
Per fare questo, il ladro ha bisogno di essere co-localizzato con voi — ovvero, la sua istanza di computer e la vostra istanza di computer devono essere in esecuzione sullo stesso identico server fisico (la stessa "stanza").
La sfida: I provider cloud sono intelligenti. Cercano di mescolare gli ospiti in modo che degli estranei non finiscano nella stessa stanza. Il documento si chiede: Un ladro può ingannare il manager dell'hotel (lo scheduler) per farsi mettere nella stessa stanza con una vittima specifica?
La soluzione: come hanno fatto i ladri
Gli autori di questo documento hanno creato una "guida pratica" su come ingannare il cloud. Hanno suddiviso il processo in tre fasi, come un detective che risolve un mistero:
Fase 1: Fingerprinting (La prova generale)
Prima di attaccare, il ladro deve sapere come pensa il manager dell'hotel.
- L'analogia: Immaginate che il ladro invii un messaggio di prova all'hotel. Osserva dove l'hotel lo colloca. Poi invia un altro messaggio e osserva di nuovo.
- La scoperta: Inviando molte richieste di prova, il ladro apprende le abitudini del manager.
- Il manager mette sempre lo stesso ospite nella stessa stanza per risparmiare tempo? (Sì, questo è chiamato "Invocation Locality").
- Il manager aggiunge più stanze quando c'è molto lavoro? (Sì, questo è l' "Auto-Scaling").
- Il manager raggruppa le persone che hanno bagagli simili? (Sì, questo è il "Package Locality" — se entrambi avete bisogno degli stessi strumenti software, venite messi insieme).
Fase 2: L'attacco (La trappola)
Una volta che il ladro conosce le abitudini del manager, prepara una trappola.
- Se il manager raggruppa per bagaglio (Package Locality): Il ladro crea una funzione falsa che utilizza esattamente lo stesso "bagaglio" (pacchetti software) della vittima. Il manager vede il bagaglio corrispondente e li mette automaticamente nella stessa stanza.
- Se il manager è impegnato e aggiunge stanze (Auto-Scaling): Il ladro crea un enorme picco di richieste false. Questo costringe il manager ad aprire molte nuove stanze rapidamente. Il ladro inonda il sistema con i propri "ospiti" per aumentare le probabilità che uno di loro finisca accidentalmente nella stanza della vittima.
- Il risultato: Nei loro test, sono riusciti a ingannare sistemi come Microsoft Azure e piattaforme open-source per farli mettere il codice dell' "attaccante" proprio accanto al codice della "vittima".
Fase 3: La prova
Non hanno solo tirato a indovinare; hanno dimostrato che funzionava.
- Hanno testato questo su un hotel simulato (un programma per computer).
- Hanno testato questo su un cluster reale di 50 computer.
- Hanno testato questo su Microsoft Azure Functions (un vero servizio cloud pubblico).
- Il risultato: Sono riusciti con successo a co-localizzarsi con le vittime in Azure, costando loro meno di 25 dollari per farlo.
La soluzione: lo scheduler "Double-Dip"
Il documento non si limita a mostrare come entrare; propone anche una serratura. Propongono una nuova regola per il manager dell'hotel chiamata Double-Dip.
- Come funziona:
- Primo Dip (Primo tuffo): Se arriva un ospite (funzione), il manager controlla prima: "Questo ospite è già in una stanza? Possiamo rimetterlo lì?" (Questo mantiene le cose veloci ed efficienti).
- Secondo Dip (Secondo tuffo): Se non c'è una stanza per lui, il manager cerca una stanza che abbia il minor numero di tipi diversi di ospiti già presenti.
- L'obiettivo: Questo assicura che se un nuovo ospite entra, sia meno probabile che venga mescolato con uno sconosciuto. Crea un' "isolamento morbido". Non è un muro perfetto (come una casa privata dedicata), ma rende molto più difficile per un ladro indovinare dove si nasconde la vittima.
Il punto fondamentale
- La minaccia: I cloud serverless sono efficienti, ma la loro efficienza (raggruppare cose simili insieme) crea una porta sul retro per gli attaccanti per avvicinarsi furtivamente alle vittime.
- La realtà: Gli attaccanti non hanno bisogno di superpoteri; devono solo comprendere le regole di scheduling del cloud e inviare i giusti "messaggi di prova" per sfruttarle.
- La difesa: I provider cloud devono cambiare i loro algoritmi di scheduling per renderli un po' più casuali e meno prevedibili, assicurando che gli estranei non finiscano accidentalmente a condividere una stanza.
Nota importante: Il documento sottolinea che questa ricerca riguarda lo scheduling (l'assegnazione delle stanze). Non ruba effettivamente dati; dimostra solo che l' "assegnazione della stanza" può essere manipolata per preparare il terreno per un futuro furto di dati. Gli autori hanno avvertito Microsoft di questo, e Microsoft ha notato che dispone di altre difese in atto, ma la vulnerabilità dello scheduling rimane un problema reale.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.