Ciò che occorre sapere sul ransomware su AWS

Per quanto il ransomware sia un problema grave all'interno dei data center, ero un po' scettico sul fatto che lo fosse altrettanto nel cloud. Personalmente non mi ero mai imbattuto in alcun incidente e avevo iniziato a pensare che fosse più una questione teorica che altro. A quanto pare mi sbagliavo un po'. Anzi, mi sbagliavo completamente. Non solo il problema è più ampio di quanto pensassi, ma lo schema di attacco è diverso da quello che mi aspettavo all'interno di Amazon Web Services (AWS).

Alla conferenza AWS re:Inforce ho partecipato a un'ottima sessione condotta da Kyle Dickinson, Megan O'Neil e Karthik Ram. La sala era gremita e il responsabile ha dovuto rimandare indietro decine di persone. Questo articolo è in parte un riepilogo della sessione, unito alle mie esperienze e raccomandazioni in merito al ransomware su AWS. Eventuali errori e omissioni sono miei, non loro.

Punti chiave:

• Gli autori di attacchi ransomware prendono sempre più di mira gli ambienti Amazon Web Services (AWS), sfruttando spesso le lacune nell'accesso alle identità, nelle configurazioni di storage e nella visibilità tra i servizi.
• I bucket Amazon S3 sono un punto di ingresso comune: gli aggressori cifrano o eliminano dati critici a causa di policy deboli o della mancata applicazione della cifratura.
• Una difesa efficace dal ransomware nel cloud richiede una strategia a più livelli, che comprenda controllo degli accessi, monitoraggio in tempo reale e flussi di lavoro di risposta rapida.
• FireMon migliora la postura di sicurezza dei dati monitorando in modo continuo le configurazioni errate, applicando le policy su larga scala e fornendo la visibilità che aiuta i team a rispondere più rapidamente alle minacce ransomware basate sul cloud.

Il ransomware su Amazon AWS è un problema?

Sì. A quanto pare il ransomware su AWS è un problema più serio di quanto pensassi inizialmente. Clienti reali ne sono colpiti, non si tratta di una questione meramente teorica.

Come funziona un attacco ransomware su Amazon

Tratterò il vettore di exploit iniziale nella domanda successiva, ma esistono quattro possibili tecniche di attacco ransomware su Amazon:

• Gli aggressori compromettono un'istanza (spesso tramite phishing di un utente/amministratore, non sempre con una compromissione diretta), quindi installano il loro malware per cifrare i dati e diffondersi ad altre istanze raggiungibili. Questo non è affatto diverso dal ransomware in un data center, poiché non coinvolge nulla di specifico del cloud.
• L'aggressore copia i dati da un bucket S3 e poi elimina i dati originali. È il ransomware cloud native su Amazon più frequentemente osservato.
• Un malintenzionato cifra i dati S3 utilizzando una chiave KMS sotto il proprio controllo. Si tratta di uno scenario più teorico che reale, per diversi fattori. È molto più semplice eliminare un oggetto/bucket che cifrarlo retroattivamente.
• Un aggressore compie un'azione sui dati in un altro servizio di storage per bloccarli/eliminarli. Rimango sul vago perché non si tratta di uno scenario osservato, e la maggior parte di questi servizi presenta limitazioni interne e resilienza integrata che rendono difficile portare a termine un attacco ransomware.

Il ransomware prende di mira più comunemente i bucket AWS S3: gli aggressori copiano e poi eliminano i dati. Anche istanze e server possono essere bersaglio dello stesso malware utilizzato per attaccare i data center. Esistono alcuni attacchi teorici che nella pratica non si osservano.

Un nuovo attacco ransomware su Amazon, però, sta guadagnando terreno: le gang ransomware hanno iniziato a cifrare i dati in loco utilizzando la cifratura lato server di AWS con chiavi fornite dal cliente (SSE-C). Questa tecnica consente agli aggressori di cifrare i file direttamente nei vostri bucket S3 senza rimuoverli né attivare gli avvisi standard, e il ripristino è impossibile senza la chiave di cifratura personalizzata dell'aggressore.

Come ottengono l'accesso gli attori delle minacce per eseguire attacchi ransomware su Amazon Web Services

Credenziali esposte. Quasi sempre chiavi di accesso statiche, ma possibilmente chiavi ottenute da un'istanza compromessa (tramite il servizio di metadati). Insomma, più o meno il modo in cui funzionano quasi tutti gli attacchi alla sicurezza basata sul cloud.

Qual è la sequenza di un attacco ransomware a S3

Mi concentrerò sullo scenario del ransomware su bucket S3, poiché è quello cloud native su cui vogliamo focalizzarci.

• L'aggressore ottiene le credenziali.
• L'aggressore utilizza le credenziali per attività di ricognizione, allo scopo di determinare le chiamate API consentite e individuare le risorse a cui può accedere.
• L'aggressore scopre di disporre dei permessi di scrittura su S3 e dell'accesso in lettura/elenco per individuare i bucket. Si noti che l'aggressore potrebbe non disporre dei privilegi di List, ma può ottenere i nomi dei bucket da altre fonti, come DNS, GitHub o altre posizioni. Questo è molto meno probabile.
• L'aggressore copia/sposta i dati in un'altra posizione, che non è necessariamente in AWS.
• L'aggressore elimina gli oggetti/file di origine.
• L'aggressore carica una richiesta di riscatto (o la invia via e-mail).

Nelle campagne più recenti, gli aggressori hanno iniziato a utilizzare anche le policy di S3 Object Lifecycle Management per contrassegnare i file cifrati per l'eliminazione entro sette giorni, aumentando l'urgenza di pagare il riscatto. Spesso lasciano un file warning.txt nella directory interessata, con un indirizzo di portafoglio Bitcoin e un ID vittima univoco.

Poiché il tutto è automatizzato, il processo può iniziare entro un minuto dall'esposizione di una credenziale.

Come si può rilevare il ransomware su Amazon S3

Beh, se non potete passare direttamente alla prevenzione del ransomware su S3…

L'aggressore di solito lascia una nota con i recapiti per potergli inviare Bitcoin, il che è comodo. Ma è probabile che la maggior parte di voi voglia individuare il problema prima di quel momento. Ripercorriamo la sequenza di un attacco ransomware ad Amazon S3 per vedere dove è possibile intercettarlo.

Innanzitutto, converrà abilitare un monitoraggio più approfondito dei bucket sensibili. Poiché questo articolo è già più lungo di quanto vorrei, tralascerò tutti i dettagli su come individuare e gestire tali bucket e mi concentrerò invece su alcune fonti chiave da considerare. Per ragioni di costo, non aspettatevi di attivarle per tutto:

• CloudTrail, ovviamente.
• CloudTrail Data Events per tutti i bucket che vi interessano. Ha un costo aggiuntivo.
• GuardDuty.
• Facoltativo: Security Hub. È il modo migliore per aggregare GuardDuty e altri servizi di sicurezza AWS su tutti i vostri account.
• Forse: S3 Server Access Logs. Se disponete di CloudTrail Data Events, ottenete già gran parte di ciò che vi serve. Ma i log S3 sono gratuiti da generare (si paga solo lo storage) e rilevano alcuni eventi che CloudTrail potrebbe non cogliere (ad esempio, le autenticazioni fallite). Richiedono inoltre ore per essere visibili, quindi non sono utili durante un incidente in corso. Maggiori informazioni in questa guida utente.

Ora che abbiamo trattato il monitoraggio, vediamo i sette passaggi del processo di rilevamento:

1. Rilevare credenziali esposte e attività di ricognizione

Il processo di rilevamento inizia con l'identificazione, propria o di terze parti, di chiavi AWS divulgate pubblicamente o compromesse, oltre che di qualsiasi attività sospetta. Di solito tramite la scansione di un repository comune, come GitHub. Amazon Web Services una volta ne ha trovata una mia e mi ha inviato un'e-mail. Ops.

Qui entrano in gioco i vostri rilevamenti relativi alla ricognizione delle credenziali dell'account. Alcune opzioni includono:

• Rilevamenti GuardDuty, come l'esfiltrazione di credenziali. Tuttavia, si registra un ritardo di circa 20 minuti ed esistono tecniche di evasione
• La chiamata API GetCallerIdentity non è sempre negativa, ma non è una chiamata che dovreste vedere spesso negli account di produzione
• GetAccountAuthorizationDetails dovrebbe generare un allarme ogni volta
• Molteplici chiamate API fallite da una singola entità IAM

2. Sorvegliare l'enumerazione di S3

Ora iniziamo a concentrarci sui rilevamenti di ransomware AWS che indicano che l'aggressore si sta focalizzando su S3. Probabilmente noterete che il rilevamento precoce in queste fasi può risultare difficile a causa del rumore, ma tenete presente che sarà più praticabile in situazioni come gli account di produzione gestiti tramite CI/CD con accesso umano limitato. Anzi, questo potrebbe spingervi a utilizzare maggiormente pattern cloud native.

I rilevamenti GuardDuty per S3 relativi agli eventi di Discovery, che devono essere abilitati oltre alla semplice attivazione di GuardDuty, a seconda di come sono configurati il vostro account e la vostra organizzazione. Filtrate per Read e List Management ed eventi Data falliti sul servizio S3. Potreste cogliere l'aggressore mentre si guarda intorno. Potete farlo nel vostro SIEM, ma è altrettanto semplice creare dei CloudWatch Metrics Filters a questo scopo.

3. Monitorare le letture e le copie di oggetti

Qui state il monitoraggio continuo per verificare se l'attaccante sta leggendo gli oggetti e creandone copie. Se legge (copia) e poi elimina ciascun oggetto, questa attività può intrecciarsi con la fase successiva.

4. Rilevare l'eliminazione di massa e l'inserimento della richiesta di riscatto

Questa è la fase critica. L'attaccante non si sta limitando a esplorare: sta eseguendo l'attacco ed eliminando i dati copiati. Entrano in azione i rilevamenti GuardDuty relativi a esfiltrazione/impatto su S3. Si ricordi che occorrono almeno 20 minuti perché si attivino e che, a seconda del numero di oggetti, questo può essere un indicatore tardivo. CloudTrail Insights, se utilizzato, segnalerà l'elevato numero di eventi Write impiegati per spostare i dati.

È possibile creare rilevamenti personalizzati per un elevato numero di chiamate di eliminazione. A seconda dell'ambiente e dei consueti schemi di attività, tale numero può essere basso e attivarsi più rapidamente di GuardDuty. Il SIEM e i Metrics Filters di CloudWatch sono buone opzioni.

5. Individuare l'abuso di SSE-C (crittografia silenziosa)

Monitori l'applicazione improvvisa di header SSE-C in chiamate API come PutObject: è un segnale che i dati potrebbero essere cifrati con la chiave dell'attaccante. Poiché AWS registra solo un hash HMAC delle operazioni, il recupero forense standard è impossibile senza un monitoraggio proattivo.

6. Utilizzare canary bucket e rilevamento KMS

Le organizzazioni mature possono popolare gli account con canary bucket/oggetti e generare avvisi su qualsiasi operazione che interessi tali bucket. Sebbene sia uno schema di attacco meno comune, è possibile segnalare agli utenti l'uso di una chiave KMS dall'esterno del proprio account.

7. Escalation e risposta agli incidenti

Se rileva l'attacco in questa fase, è già stato compromesso. È il momento di rispondere. Contatti le forze dell'ordine e coinvolga l'AWS customer incident response team.

Protezione dal ransomware su AWS: come posso mettere al sicuro la mia azienda?

Per portare a termine con successo un attacco ransomware su AWS, il malintenzionato ha bisogno di tre condizioni:

• Accesso alle credenziali
• Autorizzazioni di lettura e scrittura in S3
• La possibilità di eliminare oggetti in modo irrecuperabile

Il primo livello nella prevenzione del ransomware consiste nel mettere in sicurezza IAM, per poi utilizzare gli strumenti AWS integrati per la resilienza. È facile a dirsi e difficile a farsi, ma ecco una checklist incentrata su S3, in cui cercherò di tralasciare gran parte delle pratiche di igiene e dei controlli più comuni:

• Non consenta affatto utenti IAM dotati di chiavi di accesso statiche. Se ciò non fosse possibile, utilizzi senz'altro i propri strumenti per individuare eventuali utenti con autorizzazioni di eliminazione su S3.
• Richieda la MFA per gli utenti SSO/federati. Sempre e comunque.
• Faccia in modo che gli amministratori passino a un ruolo IAM diverso quando devono eseguire operazioni di eliminazione. È possibile persino separare completamente le autorizzazioni di lettura e di eliminazione in ruoli distinti.
• Se un'istanza necessita di accesso a S3, si assicuri di delimitare le autorizzazioni nel modo più rigoroso possibile, limitandole alle chiamate API minime indispensabili verso le risorse minime indispensabili.
• Disattivi SSE-C a meno che non sia assolutamente necessario. Questo aiuta a prevenire attacchi di crittografia silenziosa che possono precludere l'accesso ai dati senza alcuna possibilità di recupero.
• Utilizzi un endpoint VPC per accedere al bucket e aggiunga una resource policy che consenta l'eliminazione solo dalla VPC di origine. In questo modo l'attaccante non potrà usare le credenziali al di fuori di tale VPC.
• Attivi il versioning, AWS Backup e/o la replica dei bucket. Tutte queste misure garantiscono che non si possa perdere l'accesso ai dati. A meno, ovviamente, di compromettere DAVVERO le proprie policy IAM e lasciare campo libero all'attaccante. Alcune di queste funzioni devono essere abilitate al momento della creazione del bucket, quindi potrebbe essere necessaria un'operazione di migrazione per attivarle.

Noterà che non ho menzionato Block Public Access. È una funzionalità eccellente, ma molte organizzazioni faticano a implementarla su larga scala, poiché hanno bisogno di alcuni bucket pubblici e questa non è d'aiuto contro attacchi che sfruttano credenziali esposte.

Tutto ciò richiede impegno e comporta costi, per cui consiglio vivamente di concentrarsi inizialmente sui bucket realmente importanti. Esistono strategie più avanzate, soprattutto per chi gestisce ambienti di grandi dimensioni, che non possono essere trattate in un articolo: mi scriva se desidera approfondirle.

Quali novità sul ransomware S3 ha appreso nella sessione Re:Inforce?

Non sapevo che il ransomware su S3 fosse così diffuso. Non sapevo nemmeno che la tecnica di attacco preferita fosse copia-ed-elimina. Pensavo si utilizzasse la crittografia KMS ed è del tutto comprensibile perché quest'ultima sia più teorica e rara. Conoscevo già i rilevatori e le difese, ma i relatori AWS hanno fatto un lavoro eccellente nel collegarli tra loro in modo estremamente chiaro e pratico. L'intervento ha decisamente superato le mie aspettative.

In che modo FireMon può aiutare la mia azienda nella protezione dal ransomware su S3?

Abbiamo un nuovo prodotto IAM in Beta per i privilegi Just in Time che sarà disponibile a breve. Offriamo inoltre verifiche della postura e rilevatori di minacce in DisruptOps per individuare bucket a rischio e segnalare attività malevole, come gli attacchi ransomware. Mi scriva se desidera approfondire l'argomento, o anche solo per un consiglio generale sulle opzioni AWS citate in questo articolo.

Prenoti oggi stesso una demo e scopra come FireMon può aiutarla a proteggere la sua azienda dal ransomware su AWS.