AGGIORNAMENTO: Questo post è stato aggiornato per riflettere le nuove informazioni apprese in collaborazione con i team AWS S3 Replication, CloudTrail e Security.
Una strategia di backup completa è una pietra miliare di qualsiasi piano di DR. Ma come si fa a distinguere tra un'attività di backup legittima e un'esfiltrazione dolosa dei dati?
Gli aggressori informatici stanno ottenendo sempre più spesso l'accesso ai piani di controllo cloud , che includono funzionalità per eseguire backup cloud. Qui mostrerò come questi strumenti possono essere sfruttati per esfiltrare i dati dall'ambiente di produzione di un'organizzazione.
In questo blog, si analizzerà da vicino come un aggressore può abusare di S3 Replication per migrare in modo efficiente i vostri dati fuori dal vostro ambiente. Spero che la lettura sia divertente come lo è stata la creazione.
Vedrete l'attacco svolgersi in archi narrativi separati dalla prospettiva di quattro diversi attori qui elencati.
- Il servizio di replica S3è un servizio che segue benevolmente gli ordini dettati dalle regole di replica per replicare i dati S3 tra i vari bucket.
- Il malvagio servizio di replica S3poiché si abusa dei suoi poteri per copiare i dati in posizioni esterne.
- L'attaccante che ottiene il controllo del servizio di replica S3, cooptando il servizio per scopi malvagi e sfruttando la mancanza di registrazione per non farsi notare.
- Membri del team SOC (centri operativi di sicurezza) che apprendono di essere parzialmente ciechi al movimento dei dati attraverso il servizio di replica S3, ma possono ora modificare la loro strategia di rilevamento per compensare.
Introduzione al servizio di replica S3, alle sue funzionalità e ai casi d'uso per il bene
Il servizio AWS S3 non è più il "Simple Storage Service" che è stato presentato come tale. Con decine di funzionalità e integrazioni, è diventato il data store preferito dai clienti AWS aziendali. È anche così complicato che è difficile capire e quindi proteggere tutte le sue funzionalità. Una delle numerose funzionalità di S3 è la possibilità di copiare i dati tra regioni e account creando backup attivi dei dati.
Come si vede in questo post, questa funzione è matura per essere abusata e può essere difficile ottenere visibilità.
Il servizio di replica di AWS fa esattamente quello che si potrebbe pensare: quando viene indirizzato con delle regole, copia i dati S3 tra i bucket.
Il servizio prende ordini di marcia dalle Regole di replica. È possibile configurare le regole per indicare al servizio di copiare i dati in più bucket, creando più repliche dello stesso oggetto sorgente.
I bucket di destinazione non devono nemmeno trovarsi nella stessa regione o nello stesso account del bucket di origine.
Le sue capacità di replica dei dati sono possibili solo se al servizio vengono concesse le autorizzazioni necessarie. Per abilitare il servizio di replica S3, è necessario configurarlo in modo che assuma un ruolo IAM e che gli vengano concesse le autorizzazioni IAM per accedere a entrambi i bucket di origine e di destinazione.
Quali sono le conseguenze se un aggressore ottiene la capacità di utilizzare la replica S3 in AWS?
La replica incrociata degli account può aiutare le organizzazioni a riprendersi da un evento di perdita di dati. Nelle mani sbagliate, tuttavia, il servizio di replica consente agli attori delle minacce di trasferire i dati in luoghi non attendibili.
Il servizio di replica S3 ha un elevato potenziale di abuso e, di conseguenza, è un obiettivo primario per gli aggressori.
Se un utente malintenzionato dovesse acquisire la capacità di creare regole di replica, potrebbe indirizzare il servizio di replica S3 a copiare i dati in un bucket esterno controllato dall'utente. Anche uno che risiede al di fuori dell'organizzazione AWS della vittima.
Quali autorizzazioni IAM sono necessarie per replicare esternamente?
Il servizio di replica S3 richiede le autorizzazioni sugli oggetti S3 per ottenere l'oggetto dal bucket di origine e replicarlo nel bucket esterno controllato dall'aggressore.
Ecco un esempio di un criterio IAM che definisce le azioni necessarie per la replica, ma trascura di assegnare i permessi a una risorsa, lasciando il campo della risorsa come "*". Questo criterio è così permissivo da consentire al servizio di replica S3 di copiare oggetti in qualsiasi bucket, anche al di fuori dell'account dell'utente.
Con un criterio eccessivamente permissivo, un utente malintenzionato dovrebbe avere la possibilità di aggiornare le regole di replica, dirigendo il servizio di replica a copiare i dati in un bucket controllato dall'utente. Non sono necessarie autorizzazioni sugli oggetti stessi, ma solo la possibilità di aggiornare le regole.
Ricapitolando: invece di copiare o spostare direttamente i dati da un account, il servizio di replica S3 può essere sfruttato da un utente malintenzionato per eseguire le stesse azioni per suo conto, come risultato di una regola di replica dannosa. Non si tratta di un bug che può essere risolto, ma di un tipo di vulnerabilità cloud chiamata "abuso di funzionalità".
In che modo il servizio di replica S3 registra le proprie attività? E in che modo questo aiuta un attaccante a passare inosservato?
Il movimento autorizzato dei dati tramite il servizio di replica S3 è poco trasparente e rende particolarmente difficile la caccia all'esfiltrazione dei dati, consentendo a un aggressore di nascondere la propria attività in bella vista all'interno del vostro ambiente cloud .
Vediamo quando e dove il servizio di replica scrive gli eventi su CloudTrail in base alle configurazioni del bucket scoping del data-plane.
Per ottenere visibilità sugli eventi che riguardano gli oggetti S3, è necessario partecipare alla raccolta di eventi di dati S3. L'ambito di questi eventi può essere configurato in modo da includere "Tutti i bucket S3 attuali e futuri" oppure si possono enumerare i singoli bucket. Questa impostazione di CloudTrail serve come meccanismo di filtraggio per inserire bucket specifici nella registrazione del data-plane S3.
Quando i dati vengono copiati dal servizio di replica S3, si verifica un evento GetObject, poiché il servizio afferra l'oggetto durante la replica. Questo evento viene scritto nel CloudTrail dell'account sorgente.
Dopo l'evento GetObject, l'evento PutObject, che rivela il bucket di destinazione, viene registrato sia nel conto di destinazione esterno che nel conto di origine.
Qual è il comportamento del log del data-plane S3 di CloudTrail se i log sono limitati a bucket specifici?
Per controllare i costi, le organizzazioni spesso abilitano i log del data-plane S3 solo sui loro bucket di alto valore, invece di pagare per il logging su "tutti i bucket attuali e futuri". In che modo questa configurazione di log modifica la visibilità del servizio di replica S3?
Dopo l'evento GetObject , è possibile registrare un evento PutObject nell'account di destinazione, in base alla configurazione del CloudTrail dell'account di destinazione. In particolare, nessun evento PutObject verrà registrato nell'account di origine.
In pratica, quando i dati vengono copiati dal Servizio di replica, non c'è alcun record nel CloudTrail dell'account sorgente che rivela il bucket di destinazione esterno.
Quando CloudTrail è configurato per catturare gli eventi del data-plane S3 da specifici bucket dell'account sorgente, si verifica una lacuna nella registrazione, che consente di copiare i dati senza registrare l'evento del data-plane, PutObject, nell'account sorgente.
Senza i log dei data-planes con lo scopo di includere i log di tutti i bucket attuali e futuri, un utente malintenzionato potrebbe aggiornare le regole di replica per replicare gli oggetti nel proprio bucket esterno e rilassarsi mentre il servizio di replica sposta silenziosamente i dati fuori dall'organizzazione.
Fortunatamente, i controlli preventivi sono chiari.
Come sempre, quando si definiscono i criteri di identità AWS IAM, non lasciare vuoto il campo delle risorse, in modo che le autorizzazioni del criterio si applichino a qualsiasi criterio. Assicurarsi che il ruolo IAM assunto dal servizio di replica enumeri esplicitamente i bucket su cui è autorizzato a operare.
Quali sono le conseguenze per i difensori cloud ?
I cacciatori di virus possono utilizzare l'aggiornamento dannoso delle regole di replica come indizio che l'esfiltrazione dei dati potrebbe avvenire silenziosamente nel loro ambiente.
Dato che l'abuso del servizio è evitabile con il servizio di replica S3 e perché questa mancanza di visibilità è importante per i cacciatori di minacce e i difensori cloud di tutto il mondo?
Per capire perché queste incongruenze di registrazione sono importanti, dobbiamo discutere la missione del difensore in un'organizzazione. I difensori Cloud pongono continuamente domande sull'ambiente cloud alla ricerca di indicatori di compromissione. Il loro compito è rilevare quando le cose vanno storte, nonostante i migliori sforzi delle misure preventive.
Il pane quotidiano di un difensore sono i registri, che vengono utilizzati per creare rilevamenti e fornire segnali precoci che indicano che i dati si stanno spostando dal perimetro. I log del data-plane a disposizione dei difensori possono essere limitati solo a bucket noti e di alto valore per risolvere i problemi di costo e ridurre il volume dei log del data-plane che possono essere generati quando si catturano tutti.
Se i dati possono essere copiati senza incorrere in una registrazione del bucket di destinazione, i difensori non possono effettuare un'allerta o una caccia all'esfiltrazione dei dati in modo esaustivo cercando i bucket danneggiati negli eventi del data-plane, come gli eventi CopyObject o PutObject.
I difensori devono ampliare gli eventi che monitorano per includere l'aggiornamento delle regole di replica, in modo da garantire un monitoraggio completo del perimetro dei dati.
Se un SOC non è in grado di imporre la registrazione del data-plane S3 su "tutti i bucket attuali e futuri, il monitoraggio e l'avviso sull'evento PutBucketReplication è l'unico punto in cui un difensore avrà visibilità sui bucket di destinazione esterni. Questo evento non indica che i dati sono stati copiati, ma solo che il servizio di replica ha una regola configurata per copiare i dati.
Lezioni apprese quando si abusa del servizio di replica
Il servizio di replica S3 può essere utilizzato per aiutare le organizzazioni a diventare più resistenti al ransomware, ma è importante, quando si costruisce il nostro modello di minaccia, creare storie di utenti malvagi che ci aiutino a vedere le funzionalità cloud dal punto di vista di un attaccante.
A causa dei costi, un'organizzazione tipica potrebbe esitare ad abilitare il log del data-plane S3 su tutti i bucket di un account, preferendo catturare selettivamente i log solo sui bucket di alto valore. Come abbiamo visto, questa strategia comporterà una lacuna nella visibilità dell'esfiltrazione S3, poiché l'evento PutObject non verrà scritto nell'account sorgente.
Ad agosto 2022, AWS ha rifiutato di risolvere il problema di registrazione con il servizio S3 Replication. Discutendo con AWS, sono state proposte le seguenti soluzioni o "richieste di funzionalità".
- Includere il bucket di destinazione nell'evento GetObject
- Preferibilmente, considerare gli eventi GetObject e PutObject come coppie, scrivendo questi due eventi nell'account di origine come risultato del filtro di scoping del bucket di origine, piuttosto che considerare l'ambito del log del data-plane del bucket di destinazione.
Tempistica di rendicontazione
10/19/21
[Vectra]: Invio del rapporto iniziale sulla vulnerabilità e conferma della ricezione il giorno stesso.
10/20/21
[AWS]: Ha risposto indicando che non ritiene che si tratti di una vulnerabilità:
"Non riteniamo che il comportamento descritto in questo rapporto rappresenti un problema di sicurezza, piuttosto è un comportamento previsto. Offriamo allarmi CloudWatch che registrano qualsiasi modifica apportata alla politica di replica di un bucket [1], che fornirebbe visibilità sulla destinazione dei dati per il modello di minaccia descritto. Vedere la sezione "S3BucketChangesAlarm".
10/20/21
[Vectra]: Ho chiesto conferma del fatto che AWS non considera la mancanza di registrazione una vulnerabilità. Ho indicato che la risposta di AWS a questa segnalazione sarà "non risolverà" in qualsiasi divulgazione pubblica.
10/26/21
[AWS]: L'AWS mi ha chiesto dove avrei pubblicato la divulgazione e se poteva avere una copia anticipata del testo.
10/26/21
[Vectra]: Ha riconosciuto di poter ricevere una copia anticipata di qualsiasi divulgazione pubblica.
2/2/22
[Vectra]: Ha inviato nuovamente il rapporto originale sulla vulnerabilità a un contatto interno del team di sicurezza di AWS, suggerendo di presentare una richiesta di miglioramento del logging sul servizio di replica S3.
2/3/22
[AWS]: Ha riconosciuto di aver inserito il ticket internamente.
7/20/22
[Vectra]: Pubblicata una ricerca iniziale sull'argomento che descriveva il problema di registrazione come un problema che si verificava solo quando era abilitato il controllo del tempo di replica (RTC).
7/25/22
[Vectra]: Revisione dei reperti per scoprire l'assenza di registrazione con o senza RTC abilitato.
7/26/22
[Vectra]: Presentati i risultati a fwd:cloudSec
8/18/22
[Vectra e AWS]: Incontro per discutere i risultati. In questa riunione si è capito che il filtro di scoping del data-plane S3 di CloudTrail è il meccanismo che controlla se un evento PutObject viene scritto o meno nell'account di origine.
[1] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/awscloudtrail-ug.pdf