22 marzo 2022
Di Thyaga Vasudevan - VP della Gestione Prodotti, Skyhigh Security
Il passaggio a un'architettura cloud-native per le sue applicazioni aziendali può offrire un enorme valore aziendale, aggiungendo scala e agilità e scaricando compiti onerosi come il patching e l'aggiornamento dell'infrastruttura server.
Tuttavia, in ogni ambiente cloud, che sia Amazon Web Services (AWS), Azure o Google Cloud, esiste una nuova categoria di rischio. Le minacce cloud-native derivano dal nuovo contesto e dai requisiti di configurazione che si hanno in un ambiente cloud. Storicamente, le impostazioni predefinite, come l'accesso pubblico agli oggetti di archiviazione, hanno lasciato i dati sensibili all'aperto, facili da rubare da chiunque sia alla ricerca di queste debolezze.
È facile commettere errori in un nuovo ambiente, con nuove impostazioni introdotte continuamente man mano che i fornitori di cloud aggiungono nuove funzionalità. La configurazione del suo ambiente cloud è sempre una sua responsabilità. AWS e altri non hanno alcun controllo sul modo in cui lei utilizza i loro servizi. Sono un modello da cui lei può partire.
Non comprendere il risultato delle proprie configurazioni e del modo in cui si costruiscono le applicazioni cloud-native può avere conseguenze catastrofiche. E anche i clienti cloud più accorti possono soffrire di queste conseguenze.
Un esempio è la violazione subita da Capital One quasi tre anni fa, dove un aggressore ha avuto accesso ai numeri di previdenza sociale di 100 milioni di persone statunitensi e ai numeri di assicurazione sociale di 6 milioni di persone canadesi. L'aggressore ha utilizzato diverse tecniche per ottenere l'accesso ai dati, ma l'apprendimento chiave dell'attacco è stato che una funzione di sicurezza progettata per proteggere l'accesso alle macchine virtuali - istanze Elastic Compute Cloud o EC - ha aggiunto l'aggressore. La funzione si chiama Instance Metadata service o IMDS.
Attacchi ai metadati dell'istanza
La versione 1 di IMDS (IMDSv1) è stata rilasciata nel 2012 per consentire alle istanze EC2 di interagire con altri servizi AWS in modo più sicuro. Invece di lasciare le chiavi AWS sull'istanza, i clienti potevano ora far sì che l'istanza EC2 interrogasse il servizio di metadati per ottenere le credenziali ed effettuare chiamate API AWS ad altri servizi AWS. Ad esempio, se un'istanza EC2 riceveva i dati di un cliente, poteva utilizzare IMDSv1 per archiviare tali dati in un bucket Amazon Simple Storage Service (S3). È proprio questa capacità che l'aggressore ha utilizzato per estrarre informazioni sensibili da un bucket S3 utilizzato per archiviare informazioni sui clienti di Capital One.
Nei nostri test siamo stati in grado di duplicare il funzionamento di questa estrazione di dati in qualsiasi applicazione. Nel nostro esempio, un team di epidemiologi ha costruito un'applicazione cloud-native in AWS con un dashboard pubblico per rappresentare visivamente i dati che mostrano i loro progressi nell'analisi del genoma di un virus.
Durante la fase di sviluppo di questa applicazione, il team si è imbattuto in una sfida. La maggior parte delle risorse nel loro Virtual Private Cloud (VPC) doveva essere nascosta da Internet. L'unica risorsa del VPC destinata alla visione pubblica era il dashboard.
Il bucket S3 che ospita i loro dati doveva rimanere privato. Per estrarre i dati da S3 al dashboard pubblico, hanno aggiunto un reverse proxy, che funge da intermediario. È bastata una rapida ricerca su Google e poche righe di codice per aggiungere questo alla loro applicazione.
Per il team di epidemiologi, il reverse proxy era una soluzione semplice ed elegante che funzionava perfettamente per il loro caso d'uso. Quello che non hanno capito è che li ha esposti a una violazione massiccia.
All'istanza di calcolo che esegue il reverse proxy era stato assegnato un ruolo IAM con il permesso di accedere al proprio bucket S3 privato. Le credenziali per l'accesso del reverse proxy a S3 sono state ottenute dai Metadati dell'istanza.
Un aggressore che visitava il sito ed era interessato ai suoi dati ha notato che il team aveva fatto riferimento all'indirizzo IP del reverse proxy nella dashboard. L'aggressore ha quindi verificato se poteva connettersi ad esso. Dopo aver confermato la connettività, l'aggressore ha verificato se poteva accedere ai Metadati dell'Istanza attraverso il reverse proxy. Successo.
Attraverso il reverse proxy e i metadati dell'istanza, l'aggressore ha scoperto le credenziali del bucket di archiviazione S3 privato del team.
Ora, con l'accesso al bucket S3, l'aggressore poteva rubare i dati altamente sensibili che il team aveva memorizzato per la sua applicazione. L'aggressore ha semplicemente sincronizzato il bucket S3 di destinazione con il proprio bucket S3 in un altro account AWS, e i dati erano loro.
Questo tipo di attacco è solo una delle 43 tecniche descritte da MITRE nel suo quadro ATT&CK per gli ambienti cloud: https://attack.mitre.org/matrices/enterprise/cloud/
Come AWS mitiga gli attacchi ai metadati delle istanze
Per migliorare la sicurezza di questo servizio, AWS ha rilasciato IMDSv2, che aggiunge diversi nuovi livelli di protezione.
In IMDSv2, gli utenti esterni sono bloccati dalla ricezione delle credenziali, consentendo solo alle risorse applicative di riceverle. Per saperne di più su questo livello di protezione e su IMDSv2, consulti il sito https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/.
Tuttavia, la sfida rimane che IMDSv1 continua a vivere. Non c'è nulla in AWS che impedisca ai clienti di usare l'IMDSv1, e lei può ancora usarlo di default per tutte le sue istanze EC2. Come abbiamo già detto, non è responsabilità di AWS assicurarsi che lei utilizzi il cloud in modo sicuro. Questa responsabilità ricade esclusivamente sul cliente.
Nell'attacco appena descritto, il reverse proxy è stato mal configurato per consentire alle richieste esterne di raggiungere le risorse interne. Se il team avesse configurato la propria istanza di calcolo per utilizzare IMDSv2, l'accesso non autorizzato da parte dell'attore esterno sarebbe stato bloccato.
Come può aiutare Skyhigh Cloud Native Application Protection
In Skyhigh Security, abbiamo diversi approcci che possono aiutarla a rilevare e prevenire attacchi come questo. Skyhigh Cloud Native Application Protection Platform (CNAPP) è la nostra piattaforma di sicurezza cloud-native che le consente di monitorare e aggiornare le configurazioni in AWS, Azure, GCP, oltre a un'ampia gamma di misure di sicurezza aggiuntive che può leggere qui.
Utilizzando un'integrazione API diretta con AWS, Skyhigh CNAPP monitora continuamente Amazon CloudWatch - un servizio di monitoraggio delle applicazioni e delle infrastrutture - per indicare quale versione di IMDS sta utilizzando in ogni istanza EC2.
Quando CloudWatch registra un'istanza che utilizza attivamente IMDSv1, Skyhigh CNAPP genera un incidente di sicurezza, notificandole di aggiornare la configurazione a IMDSv2, che impedirà l'accesso non autorizzato alle sue credenziali da parte di utenti esterni.
Incidenti di politica CNAPP Skyhigh per la configurazione della versione IMDS
La prassi migliore è quella di imporre IMDSv2 sulle sue istanze EC2 per tutto il codice e gli utenti locali. Una volta specificato che IMDSv2 deve essere utilizzato, IMDSv1 non funzionerà più. AWS offre istruzioni passo passo su come configurare le sue istanze per utilizzare IMDSv2, qui.
Al di là di questo esempio di attacco, Skyhigh CNAPP le permette di implementare una serie di best practice per proteggere le sue applicazioni cloud-native:
- Verifica continua delle sue configurazioni. Con Skyhigh CNAPP può analizzare i modelli AWS CloudFormation prima che entrino in produzione, e poi rilevare qualsiasi "deriva" delle sue configurazioni nel tempo. Questo le consente di rilevare le configurazioni errate e di applicare un modello di minimo privilegio per l'autorizzazione delle risorse.
- Applicare la fiducia zero. Utilizza la fiducia zero come metodologia, in cui solo determinate risorse sono autorizzate a funzionare e a comunicare tra loro. Tutto il resto viene bloccato.
- Esaminare le vulnerabilità del codice. In particolare con i modelli di distribuzione del software aperto come Docker, è importante monitorare costantemente le risorse della sua applicazione per individuare eventuali vulnerabilità.
- Rilevare anomalie e minacce. Con la User and Entity Behavior Analytics (UEBA), può valutare milioni di eventi cloud per scoprire attività anomale e minacce reali come il furto di credenziali.
- Esegua la DLP sugli oggetti di archiviazione. Proprio come qualsiasi altro servizio cloud che sanziona, la sua rete o gli endpoint, all'interno di AWS può e deve classificare i suoi dati all'interno di S3 ed eseguire data loss prevention per bloccare i tentativi di esfiltrazione.
Si metta in contatto con noi per parlare dell'implementazione di queste misure nella sua organizzazione.
Torna ai blog