Il cloud ha stravolto il contesto su cui i difensori sono abituati a basarsi per comprendere la superficie di attacco. Gli aggressori non si muovono più lungo un piano di rete lineare, da un asset all'altro, dove la visibilità può essere rintracciata a un livello prevedibile dello stack di rete. Nel cloud, ogni mossa che un attaccante può fare deve essere compresa in relazione all'infrastruttura cloud su cui opera.
In questo post mi propongo di chiarire gli approcci unici necessari per difendere i sistemi cloud , discutendo l'architettura alla base del cloud, il modello di minaccia che ne deriva e, infine, il modo in cui gli aggressori abusano di tali sistemi.
Innanzitutto, una breve rassegna della classica architettura on-prem e dei punti di inflessione che gli aggressori cercano di sfruttare. In contrapposizione allo stack tecnologico tradizionale c'è l'architettura del cloud service provider (CSP). Vi illustrerò le basi dell'architettura cloud , il nuovo modello di minaccia che emerge e, di conseguenza, i passi che gli aggressori compiono per infiltrarsi nelle risorse distribuite cloud . Per concludere, una volta chiarito perché il cloud è diverso, vi illustrerò un modo cloud con cui gli aggressori abusano dell'ambiente e come i difensori devono pensare alla visibilità nel cloud.
Modello di minaccia dello stack tecnologico tradizionale
Può essere utile fornire una breve panoramica dell'architettura dei data center anche se la maggior parte dei lettori ha una buona conoscenza di uno stack tecnologico tradizionale. Dedicare un po' di tempo al modello di minaccia delle architetture dei data center è utile per il juxta-positioning che faremo in seguito rispetto al modello di minaccia cloud , ma aiuta anche a ricordare le ipotesi incorporate che abbiamo su come proteggere i sistemi.
Esame dei vettori di compromissione iniziale.
- L'architettura classica può essere afflitta da porte di gestione esposte in cui gli aggressori potrebbero ottenere l'accesso diretto a un server.
- Dobbiamo anche modellare i rischi associati alle vulnerabilità del livello applicativo e il modo in cui potrebbero essere sfruttate per ottenere l'accesso al livello OS.
- Un altro paio di punti comuni di compromissione iniziale in un sistema classico includono i sempre rilevanti attacchi phishing , gli impianti consegnati via e-mail e lo sfruttamento delle vulnerabilità dell'host-layer.
Ognuno di questi vettori può essere sfruttato da un aggressore sia per ottenere un punto d'appoggio iniziale in un ambiente, sia per avanzare in un sistema alla ricerca di un obiettivo, spesso per compromettere la riservatezza dei dati.
Le tecniche di attacco sono dettate dalle caratteristiche dello stack tecnologico.
Potrebbe sembrare un'osservazione ovvia: gli aggressori vivono sul territorio e adattano le loro metodologie allo stack tecnologico con cui si trovano a operare. Nonostante la sua semplicità, questa verità universale aiuta a spiegare la diversità delle tecniche utilizzate quando gli attori delle minacce prendono di mira i sistemi on-premise rispetto alle infrastrutture cloud .
I sistemi on-premise che gli avversari utilizzano sono probabilmente installati con sistemi operativi perfettamente funzionanti. Questa superficie di attacco potrebbe essere sfruttata per passare da una workstation compromessa a un server instradabile nel datacenter della vittima.
I server non funzionano in air-gapped, ma sono collegati tra loro tramite una rete. È attraverso questa rete che gli aggressori possono spostarsi da un host all'altro.
Spesso, nell'architettura tradizionale dei data center si trovano regole di uscita permissive. È su questo percorso di rete in uscita che gli aggressori cercano di stabilire la persistenza attraverso tunnel di comando e controllo e di esfiltrare i dati al di fuori di un perimetro di rete affidabile.
Se notate, la progressione dell'attacco on-premises documentata nel diagramma precedente è guidata dalla superficie disponibile per un attaccante. Nella prossima sezione, quando passeremo a discutere dell'architettura cloud , noterete che le stesse regole della strada rimangono, lo stack tecnologico informa le tattiche e le tecniche che gli aggressori impiegano per raggiungere i loro obiettivi.
Architettura Cloud e nuovo modello di minaccia
Il cloud si basa sul concetto di infrastruttura condivisa, in cui ai clienti viene concesso un accesso granulare a determinati livelli dello stack dell'infrastruttura per creare e mantenere le risorse. Un cliente cloud ha la completa autonomia di creare risorse IaaS, utilizzare servizi PaaS, trasferire dati e creare criteri IAM (Identity and Access Management) per governare l'accesso, il tutto grazie all'autorizzazione delegata a una porzione dell'infrastruttura gestita dai fornitori di servizi cloud .
L'accesso alle funzionalità è delegato ed esposto al cliente al cliente attraverso un livello di API, definito in generale API del piano di controllo Cloud .
Tutte le interazioni dell'utente finale con un ambiente cloud sono intermediate attraverso il piano di controllo Cloud da migliaia di API disponibili pubblicamente. Le API del piano di controllo consentono ai clienti di eseguire operazioni amministrative come la creazione di nuovi ambienti, il provisioning degli utenti, la manutenzione delle risorse e l'accesso ai dati memorizzati sui servizi PaaS gestiti.
L'API del piano di controllo ha il compito di:
- Autorizzare i chiamanti, assicurarsi che abbiano i permessi corretti per eseguire le azioni richieste.
- Riprodurre l'azione al componente a valle. Un'azione può essere il riavvio di una macchina virtuale, la copia di un oggetto da un bucket a un altro o l'aggiornamento delle autorizzazioni di un utente.
Il cloud è potente!
Esponendo tutte le funzionalità tramite una serie di API pubbliche e ben note, le aziende possono trovare velocità e scalabilità di impatto come mai prima d'ora. Costruire sul cloud è come gettare benzina sui cicli di sviluppo ed è per questo che la grande migrazione verso il cloud in tutti i settori è in corso, nonostante i costi spesso elevati della migrazione e i costi continui dell'infrastruttura cloud .
Alla luce di questo nuovo paradigma, come dobbiamo modellare le minacce che incombono sui dati archiviati nel cloud?
Trovo utile concentrarmi sulla compromissione iniziale perché è un'ottima lente per evidenziare le somiglianze e le differenze tra i modelli di minaccia on-prem e cloud .
Un paio di vettori di compromissione iniziale nel cloud dovrebbero risultare familiari.
- La compromissione iniziale nel cloud può avvenire a causa di porte di gestione aperte sulle risorse IaaS. Conosciamo tutti il caso di una porta SSH o RDP aperta che attira attenzioni indesiderate. Nel cloud, questi rischi rimangono.
- Inoltre, le vulnerabilità del livello applicativo sono ancora del tutto rilevanti. Il codice non sicuro distribuito sulle applicazioni Web rivolte al pubblico causa come minimo l'interruzione delle operazioni aziendali e, nel peggiore dei casi, offre agli aggressori un punto d'appoggio nella vostra DMZ.
L'esperienza acquisita in ambito on-premise nella prevenzione e nel rilevamento della compromissione iniziale attraverso questi due vettori sarà utile nel cloud. Le regole di prevenzione e rilevamento possono assumere una cloud leggermente cloud, ma sono fondamentalmente le stesse quando si verificano in un ambiente cloud .
Ma che dire delle API del piano di controllo? Si tratta di endpoint pubblici in cui l'autorizzazione è configurabile dal cliente. Questa superficie di attacco è completamente nuova ed è il punto in cui l'attaccante esperto sfrutterà le comodità del cloud per raggiungere i propri obiettivi.
Esaminiamo come potrebbe essere la progressione di un attacco quando un aggressore sfrutta le API del piano di controllo rispetto a una superficie di attacco on-premises (vedi diagramma):
- La compromissione iniziale tramite phishing è una tattica molto diffusa tra gli avversari perché spesso funziona.
- L'impatto delle credenziali raccolte può spostarsi sul cloud quando le credenziali vengono utilizzate per autenticare e autorizzare le attività in ambienti cloud .
- È improbabile che le credenziali associate alla compromissione iniziale forniscano un percorso diretto all'avversario. Di conseguenza, per ottenere ulteriori permessi si potrebbe ricorrere a una delle tante tecniche di privilege escalation già sperimentate nel cloud .
- Le campagne cercheranno spesso di stabilire una forma di persistenza. Sul piano di controllo del cloud , questo aspetto sarà significativamente diverso rispetto a quello on-premise. La persistenza nel cloud si presenta spesso come il backdooring dell'accesso agli account attraverso la manipolazione dei criteri IAM.
- Percorrendo la progressione dell'attacco, ci troviamo ora a un punto in cui è stato ottenuto l'accesso all'obiettivo. Nel cloud questo significa semplicemente ottenere le autorizzazioni IAM appropriate per accedere ai dati ospitati cloud .
- Infine, in questo scenario, le azioni sugli obiettivi consistono nell'esfiltrazione dei dati dall'ambiente. Anche in questo caso, le API del piano di controllo cloud vengono utilizzate per trasferire i dati dall'ambiente della vittima a un ambiente controllato dall'aggressore.
L'intera sequenza di attacco, dalla compromissione iniziale all'impatto, è stata orchestrata attraverso le API pubblicamente disponibili del fornitore di servizi cloud . In nessun momento sono entrati in gioco il livello di rete o il livello host. Non è stato possibile effettuare controlli preventivi o sensori su una rete.
Esfiltrazione dei dati Cloud
Una caratteristica fondamentale di ogni CSP è la sua rete dorsale. Che cos'è una rete dorsale?
- È il livello di servizio del fornitore di servizi cloud , utilizzato per le attività operative in background del CSP, la rete back-channel utilizzata per comunicare con l'infrastruttura multi-tenant e mantenere la disponibilità.
- Il backbone si riferisce anche alla rete utilizzata dal CSP per trasferire i dati dei clienti, invece di trasportare byte sul web.
Questa rete dorsale fa sì che molti servizi gestiti, come i repository di cloud storage, siano automaticamente instradabili verso tutti gli altri repository di storage del CSP.
Dal punto di vista tattico, se si desidera spostare i dati da un bucket S3 a un altro bucket S3, sono sufficienti le autorizzazioni IAM per farlo. Il percorso di rete è già tracciato sulla rete dorsale del CSPCloud Service Provider).
In qualità di consumatore cloud , non è possibile implementare alcuna restrizione di rete intorno ai dati che risiedono nello storage cloud-native1 e non si ha visibilità sulla rete su cui viaggiano.
Ad esempio, non è possibile ingerire i log del livello di rete per acquisire il traffico tra due bucket S3.
Si tratta di una serie di circostanze interessanti per un aggressore motivato a esfiltrare dati da un ambiente cloud .
Se ottengono le autorizzazioni IAM appropriate, i dati possono essere spostati da un bucket della vittima a un bucket di un account controllato dall'aggressore inviando richieste API di livello 7 al control-plane cloud .
Per eseguire questa operazione, un aggressore interagisce esclusivamente con le API del piano di controllo cloud disponibili pubblicamente e sfrutta la rete dorsale del CSP, un percorso di rete preconfigurato, non accessibile al cliente.
Visibilità sul piano di controllo
I dati spostati da un bucket all'altro non lasciano il tipo di traccia a cui sono abituati i difensori.
- I log del livello di rete, che potrebbero rivelare i pacchetti di dati che si spostano dal vostro bucket a un altro, non sono disponibili per voi come consumatori cloud .
- Il movimento dei dati avviene attraverso la rete dorsale, per la quale i clienti cloud non hanno visibilità.
- E la visibilità del livello host?
- Lo storage Cloud, come i bucket S3, i blob di Azure e simili, sono tutti servizi gestiti. Il cliente non ha accesso all'host o al sistema operativo, come nel modello di infrastruttura come servizio. Non è possibile distribuire agenti sui servizi gestiti.
Rimane quindi il piano di controllo. Nessuna delle azioni intraprese da un attaccante potrebbe essere identificata con i sensori tradizionali, ma gli indicatori dell'attività appaiono nei registri scritti dal piano di controllo cloud .
Tutte le azioni sulle risorse e sui dati cloud sono autorizzate dalle API proxy del piano di controllo cloud e risultano in qualche forma di registrazione.
- Le azioni dei vostri sviluppatori quando creano i loro bucket vengono registrate, la normale ingestione e lettura dei dati viene registrata e risulta in eventi corrispondenti.
- Al contrario, quando i malintenzionati sfruttano le API del piano di controllo cloud , le loro azioni vengono registrate come lo stesso evento.
Questi record di eventi raccontano la storia del vostro ambiente cloud , chi ha avuto accesso a cosa, da dove e con quali credenziali, ma non le intenzioni dell'utente. Per determinare se una particolare azione ha un intento malevolo o benevolo sono necessari ulteriori indizi di contesto e spesso una lente più ampia attraverso la quale osservare l'ambiente.
Considerazioni finali
Un paio di spunti di riflessione
- Gli avversari sfrutteranno l'architettura unica del cloud e i servizi cloud per lo stesso motivo per cui gli sviluppatori usano il cloud : è veloce! È scalabile! E le API del piano di controllo cloud li aiutano a raggiungere i loro obiettivi.
- Il piano di controllo è il luogo in cui è possibile trovare prove di attività, dannose o di altro tipo, in un ambiente cloud . Il monitoraggio basato sulla rete o sull'host non fornisce la visibilità necessaria.
[1] Controlli dei servizi VPC (Virtual Private Cloud): Solo Google Cloud offre la funzionalità di imporre perimetri intorno ai servizi gestiti, non vincolati ai VPC cloud