Il cloud stravolto il contesto su cui i difensori erano soliti basarsi per comprendere la superficie di attacco. Gli aggressori non si muovono più lungo un piano di rete lineare, passando da una risorsa all'altra dove la visibilità può essere tracciata a un livello prevedibile nello stack di rete. Nel cloud, ogni mossa che un aggressore può compiere deve essere compresa in relazione cloud su cui opera.
In questo post intendo chiarire gli approcci specifici necessari per difendere 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 panoramica dell'architettura classica on-premise e dei punti di svolta che gli aggressori cercano di sfruttare. A contrapporsi allo stack tecnologico tradizionale è l'architettura del vostro fornitore cloud (CSP). Vi guiderò attraverso le basi cloud , il nuovo modello di minaccia che emerge e, di conseguenza, le misure adottate dagli aggressori per infiltrarsi nelle risorse cloud . Per concludere, una volta chiarito perché il cloud diverso, vi illustrerò un modo cloud in cui gli aggressori abusano dell'ambiente e come i difensori devono considerare la 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 degli stack tecnologici tradizionali. Dedicare del tempo all'analisi del modello di minaccia delle architetture dei data center aiuta a contestualizzare il confronto che faremo in seguito con un modello cloud , ma serve anche a ricordarci i presupposti su cui si basa la nostra protezione dei sistemi.
Esame dei vettori della compromissione iniziale.
- L'architettura classica può essere afflitta da porte di gestione esposte attraverso le quali gli aggressori potrebbero ottenere accesso diretto a un server.
- Dobbiamo anche modellare i rischi associati alle vulnerabilità del livello applicativo e il modo in cui potrebbero essere sfruttati per ottenere l'accesso al livello del sistema operativo.
- Altri due punti comuni di compromissione iniziale in un sistema classico includono gli phishing , sempre rilevanti, gli impianti inviati tramite e-mail e lo sfruttamento delle vulnerabilità del livello host.
Ciascuno di questi vettori può essere sfruttato da un aggressore sia per ottenere un primo punto d'appoggio in un ambiente, sia per avanzare all'interno di un sistema al fine di raggiungere un obiettivo, spesso quello di compromettere la riservatezza dei dati.
Le tecniche degli aggressori sono dettate dalle caratteristiche dello stack tecnologico.
Potrebbe sembrare un'osservazione ovvia, ma gli aggressori sfruttano le risorse disponibili e adattano le loro metodologie allo stack tecnologico con cui si trovano a interagire. Nonostante la sua semplicità, questa verità universale aiuta a spiegare la divergenza delle tecniche utilizzate quando gli autori delle minacce prendono di mira i sistemi on-premise rispetto cloud .
I sistemi locali con cui gli avversari interagiscono sono probabilmente dotati di sistemi operativi perfettamente funzionanti. Tale superficie di attacco potrebbe essere sfruttata per passare da una workstation compromessa a un server instradabile nel data center della vittima.
I server non funzionano in modalità air-gapped, ma sono collegati tra loro tramite una rete. È proprio attraverso questa rete che gli hacker possono spostarsi da un host all'altro.
Spesso, nell'architettura tradizionale dei data center si riscontrano regole di uscita permissive. È proprio su questo percorso di rete in uscita che gli aggressori cercano di stabilire una persistenza attraverso tunnel di comando e controllo e di sottrarre dati dal perimetro di una rete affidabile.
Come potete notare, la progressione dell'attacco on-premise documentata nel diagramma sopra riportato è determinata dalla superficie disponibile per l'autore dell'attacco. Nella sezione successiva, quando passeremo a discutere cloud , noterete che valgono le stesse regole: lo stack tecnologico determina le tattiche e le tecniche utilizzate dagli autori degli attacchi per raggiungere i propri obiettivi.
Cloud e il nuovo modello di minaccia
Il cloud basa sul concetto di infrastruttura condivisa, in cui ai clienti viene concesso un accesso granulare a determinati livelli dello stack infrastrutturale per creare e gestire le risorse. Un cloud ha completa autonomia per creare risorse IaaS, utilizzare servizi PaaS, trasferire dati e creare criteri IAM (Identity and Access Management) per governare l'accesso, tutto grazie all'autorizzazione delegata a una parte dell'infrastruttura gestita dai fornitori cloud .
L'accesso alle funzionalità è delegato ed esposto al cliente attraverso un livello di API comunemente denominato Cloud API.
Tutte le interazioni degli utenti finali con un cloud vengono gestite tramite il Cloud da migliaia di API disponibili pubblicamente. Le API del piano di controllo consentono ai clienti di eseguire attività amministrative come la creazione di nuovi ambienti, il provisioning degli utenti, la manutenzione delle risorse e l'accesso ai dati archiviati sui servizi PaaS gestiti.
La responsabilità dell'API del piano di controllo è quella di:
- Autorizza i chiamanti, assicurati che dispongano delle autorizzazioni corrette per eseguire le azioni richieste.
- Riproduci l'azione sul componente a valle. Un'azione potrebbe essere il riavvio di una VM, 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 ben note, le aziende possono ottenere una velocità e una scalabilità senza precedenti. Sviluppare sul cloud come dare una marcia in più ai propri cicli di sviluppo ed è per questo che la grande migrazione al cloud tutti i settori è in pieno svolgimento, nonostante i costi spesso elevati della migrazione e i costi continui cloud .
Alla luce di questo nuovo paradigma, come dovremmo modellare le minacce che incombono sui dati archiviati nel cloud?
In questo caso ritengo utile concentrarsi sul compromesso iniziale, poiché è un ottimo punto di vista per evidenziare le somiglianze e le differenze tra i modelli cloud on-premise e cloud .
Un paio di vettori di compromissione iniziale nel cloud risultare familiari.
- Il compromesso iniziale nel cloud verificarsi a causa delle porte di gestione aperte sulle risorse IaaS. Sappiamo tutti che una porta SSH o RDP aperta attira attenzioni indesiderate. Nel cloud, tali rischi permangono.
- Inoltre, le vulnerabilità a livello di applicazione sono ancora del tutto rilevanti. Il codice non sicuro implementato su applicazioni web accessibili al pubblico causa come minimo interruzioni delle operazioni aziendali e, nel peggiore dei casi, offre agli aggressori un punto d'appoggio nella vostra DMZ.
Qualsiasi esperienza on-premise che avete acquisito nella prevenzione e nell'individuazione delle violazioni iniziali tramite questi due vettori vi sarà utile nel cloud. Le regole relative alla prevenzione e all'individuazione potrebbero assumere una connotazione leggermente cloud, ma sono sostanzialmente le stesse quando si verificano in un 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 è qui che gli hacker più esperti sfrutteranno le comodità del cloud raggiungere i propri obiettivi.
Esaminiamo come potrebbe presentarsi una progressione dell'attacco quando un aggressore sfrutta le API del piano di controllo anziché una superficie di attacco locale (vedere il diagramma):
- Il compromesso iniziale tramite phishing una tattica molto utilizzata dagli avversari perché spesso funziona.
- L'impatto delle credenziali raccolte può spostarsi sul cloud le credenziali vengono utilizzate per autenticare e autorizzare attività in cloud .
- È improbabile che le credenziali associate alla compromissione iniziale forniscano un percorso diretto all'avversario. Di conseguenza, per ottenere ulteriori autorizzazioni cloud essere impiegata una delle tante tecniche collaudate di escalation dei privilegi nel cloud .
- Le campagne spesso cercano di stabilire una qualche forma di persistenza. Sul piano cloud , ciò apparirà significativamente diverso rispetto all'ambiente locale. La persistenza nel cloud assomiglia all'accesso backdoor all'account attraverso la manipolazione della politica IAM.
- Seguendo questa sequenza di attacchi, siamo ora giunti al punto in cui è stato ottenuto l'accesso al bersaglio. Nel cloud significa semplicemente ottenere le autorizzazioni IAM appropriate per accedere ai dati cloud .
- Infine, in questo scenario, le azioni sugli obiettivi consistono nell'esfiltrazione dei dati dall'ambiente. Anche in questo caso, le API cloud vengono utilizzate per trasferire i dati dall'ambiente della vittima a un ambiente controllato dall'autore dell'attacco.
L'intera sequenza dell'attacco, dalla compromissione iniziale all'impatto, è stata orchestrata attraverso le API pubblicamente disponibili del fornitore cloud . In nessun momento sono entrati in gioco il livello di rete o il livello host. Non era nemmeno possibile utilizzare controlli preventivi o sensori su una rete.
Esfiltrazione dei dati Cloud
Una caratteristica fondamentale di qualsiasi CSP è la sua rete dorsale. Che cos'è una rete dorsale?
- È il livello di servizio del fornitore cloud , utilizzato per le attività operative di background del CSP, la rete di back-channel utilizzata per comunicare con l'infrastruttura multi-tenant e mantenere la disponibilità.
- La dorsale si riferisce anche alla rete utilizzata dal CSP per trasferire i dati dei clienti, anziché trasportare byte sul web aperto.
Questa rete dorsale consente di gestire automaticamente molti servizi, come gli archivi cloud , che possono essere instradati automaticamente verso tutti gli altri archivi di storage del CSP.
Dal punto di vista tattico, se si desidera spostare i dati da un bucket S3 a un altro bucket S3, è sufficiente disporre delle autorizzazioni IAM necessarie. Il percorso di rete è già definito sulla rete backbone dei CSP (Cloud Provider).
In qualità di cloud , non è possibile implementare alcuna restrizione di rete sui dati che risiedononell'archivio cloud e non si ha visibilità sulla rete attraverso la quale viaggiano.
Ad esempio, non è possibile acquisire alcun log a livello di rete per catturare il traffico tra due bucket S3.
Questo crea una serie di circostanze favorevoli per un hacker motivato a sottrarre dati da un cloud .
Se ottengono le autorizzazioni IAM appropriate, i dati possono essere spostati dal bucket della vittima a un bucket in un account controllato dall'autore dell'attacco inviando richieste API di livello 7 al cloud .
Per eseguire questa operazione, un aggressore interagisce esclusivamente con le API del piano cloud disponibili pubblicamente e sfrutta la rete backbone CSP, un percorso di rete preconfigurato, non accessibile al cliente.
Visibilità sul piano di controllo
I dati trasferiti da un bucket all'altro non lasciano tracce del tipo a cui sono abituati la maggior parte dei difensori.
- I log a livello di rete, che potrebbero rivelare i pacchetti di dati che si spostano dal tuo bucket a un altro, non sono disponibili per te in quanto cloud .
- Il trasferimento dei dati avviene attraverso la rete dorsale, di cui cloud non hanno alcuna visibilità.
- E la visibilità a livello di host?
- Gli archivi Cloud come i bucket S3, i blob di archiviazione Azure e simili sono tutti servizi gestiti. Il cliente non ha accesso al livello host o al sistema operativo come nel modello Infrastructure as a Service. Non è possibile distribuire agenti sui servizi gestiti.
Ciò ci porta al piano di controllo. Nessuna delle azioni intraprese da un aggressore potrebbe essere identificata con i sensori tradizionali, ma gli indicatori dell'attività compaiono nei registri scritti dal piano cloud .
Tutte le azioni sulle risorse e sui dati cloud sono autorizzate dalle API proxy cloud e danno luogo a una qualche forma di registrazione.
- Le azioni dei tuoi sviluppatori durante la creazione dei bucket vengono registrate, così come la normale acquisizione e lettura dei dati, generando eventi corrispondenti.
- Al contrario, quando i malintenzionati sfruttano le API cloud , le loro azioni vengono registrate come lo stesso evento.
Questi registri degli eventi raccontano la storia del tuo cloud , chi ha effettuato l'accesso, da dove e con quali credenziali, ma non le intenzioni dell'utente. Per determinare se una determinata azione abbia intenzioni malevole o benevole sono necessari ulteriori indizi contestuali e spesso una visione più ampia dell'ambiente.
Conclusioni finali
Un paio di cose da ricordare
- Gli avversari sfrutteranno l'architettura unica del cloud e i servizi cloud per lo stesso motivo per cui gli sviluppatori utilizzano il cloud è veloce! È scalabile! E le API cloud li aiutano a raggiungere i loro obiettivi.
- Il piano di controllo è il luogo in cui possiamo trovare prove di attività, dannose o meno, in un cloud . Il monitoraggio basato sulla rete e sull'host non fornirà la visibilità necessaria.
[1] Controlli del servizio VPC (Virtual Private Cloud): solo Google Cloud funzionalità per applicare perimetri attorno ai servizi gestiti, non vincolati ai VPC cloud