Quanto è sicuro un ambiente cloud conforme a CIS/AWS?

Blogpost 29 aprile 2021 di Roy Stultiens, Analista di sicurezza di Bureau Veritas Cybersecurity

In Bureau Veritas Cybersecurity vediamo clienti che desiderano conformarsi agli standard di settore o alle linee guida di sicurezza per assicurarsi che il loro ambiente cloud sia adeguatamente protetto. Negli ambienti cloud, una delle linee di base comuni è quella del CIS (Center for Internet Security [1]). Queste linee di base apportano valore e sicurezza di base a un ambiente, ma in realtà potrebbero essere ancora a rischio di attacco, come dimostra la nostra ricerca.

Uno dei nostri analisti della sicurezza ha condotto una ricerca per scoprire quanto sia sicuro un ambiente cloud AWS completamente conforme ai requisiti CIS e se questo protegga dalle misconfigurazioni e dalle vulnerabilità comunemente riscontrate. I risultati sono che con tre linee di base comunemente utilizzate è possibile portare a termine 4 dei 6 attacchi più comuni. In questo articolo condividiamo i dettagli di questa ricerca e forniamo consigli sulle più comuni configurazioni errate o falle di sicurezza per aiutarla a proteggere il suo cloud.

Parametri di sicurezza/Baseline comunemente utilizzati

Per prima cosa sono stati raccolti i framework di sicurezza AWS più popolari, utilizzati comunemente dai nostri clienti e dalla nostra esperienza nelle valutazioni del cloud. Per AWS, sono stati identificati tre framework di sicurezza, ossia:

• CIS Amazon Web Services Foundations benchmark v1.2 (2018) [2]
  Questo benchmark è di gran lunga il più popolare e fornisce 49 raccomandazioni di sicurezza su IAM, Logging, Monitoring e Networking. Le raccomandazioni sono di livello 1 o di livello 2, dove il livello 2 è rappresentato da misure di difesa approfondite che potrebbero avere un impatto sulle prestazioni di un servizio. Le raccomandazioni sono generiche e possono essere applicate a tutti gli ambienti AWS.
• CIS AWS Three-tier Web Architecture benchmark v1.0 (2016) [3]
  Il benchmark Three-tier è composto da 96 raccomandazioni, specificate per servizi specifici, come EC2 (Elastic Computing) e database. Il documento è finalizzato all'utilizzo dell'architettura a tre livelli. L'implementazione di questo benchmark su altre architetture richiede una conoscenza approfondita da parte dell'utente.
• Standard AWS Foundational Security Best Practices [4]
  Questo standard è rilasciato da AWS e in costante sviluppo. Al momento della stesura del presente documento, contiene 70 raccomandazioni di sicurezza, mentre durante la ricerca consisteva in 31 regole. Tutte le regole sono specifiche del servizio e sono completamente integrate con l'AWS Security Hub.

Misconfigurazioni e/o vulnerabilità comuni in Cloud/AWS

Sebbene Bureau Veritas Cybersecurity utilizzi benchmark e linee di base per la sicurezza nei suoi assessment sul cloud, i nostri expert tendono ad adottare un approccio olistico piuttosto che verificare solo queste linee di base. Nelle valutazioni del cloud condotte nella vita reale, sono state trovate molte configurazioni errate e vulnerabilità diverse. Una selezione di quelle più comuni sono:

1. Server Side Request Forgery (SSRF) su EC2 [5]
   In questo scenario, un'istanza di calcolo AWS (EC2) viene lanciata con le autorizzazioni per leggere i bucket S3. Tuttavia, il servizio web in esecuzione sull'istanza contiene una vulnerabilità che consente a un aggressore di lasciare che il server esegua le richieste per suo conto. Un aggressore può abusarne per interrogare il Servizio Metadati Istanza di AWS ed estrarre le credenziali che la macchina utilizza per accedere ai bucket S3. Maggiori dettagli sono disponibili in questo video.
2. Segreti memorizzati nei dati-utente sulle istanze EC2 [6]
   I dati-utente sulle istanze EC2 sono spesso utilizzati per gli script di configurazione al primo avvio. Potrebbe essere allettante memorizzare i segreti, come le chiavi API o di accesso, nei dati utente, in modo che questi possano essere inviati alla macchina durante l'installazione. Tuttavia, questi dati non sono criptati e possono essere estratti utilizzando il Servizio Metadati Istanza o la Console AWS. L'archiviazione di segreti nei dati utente non è solo un rischio per gli aggressori esterni, anche gli addetti ai lavori potrebbero estrarre informazioni preziose. Maggiori dettagli sono disponibili in questo video.
3. Istantanee pubbliche dai volumi EBS [7]
   I volumi Elastic Block Store (EBS) sono i dischi rigidi delle istanze EC2. L'utilizzo delle istantanee per poter riportare la macchina ad uno stato precedente è una pratica comune e buona. AWS consente agli utenti di condividere le proprie istantanee, sia con un account AWS specifico che con tutti gli account (pubblico). Le istantanee pubbliche possono essere clonate da tutti, i dati che risiedono nell'istantanea non sono sicuri e possono essere facilmente estratti e analizzati per scoprire eventuali segreti. Veda la ricerca di Bishopfox.
   
4. Autorizzazioni pubbliche di lettura/scrittura sui bucket S3
   Forse la causa più nota di violazione dei dati sono i bucket S3 mal configurati. Questi bucket consentono un'archiviazione quasi illimitata e possono essere configurati per consentire l'accesso pubblico. Se viene effettuata questa configurazione, è sufficiente avere il nome del bucket per estrarre tutti i dati.
5. Vulnerabilità di iniezione di codice nelle funzioni Lambda [8]
   Possono essere utilizzate per tutti i tipi di compiti, come l'etichettatura degli oggetti, l'elaborazione delle immagini e le notifiche. Per eseguire con successo questi compiti, le funzioni ricevono spesso le autorizzazioni tramite i ruoli IAM su altri servizi AWS, come S3 o EC2. Quando l'evento viene lanciato, la funzione Lambda si attiva ed esegue il codice programmato. Se questo codice contiene una vulnerabilità di iniezione, un aggressore potrebbe essere in grado di estrarre le variabili di sistema della funzione. Ciò include le credenziali AWS che vengono utilizzate per accedere ad altri servizi AWS. Maggiori dettagli sono disponibili in questo video.
6. Segreti memorizzati nelle variabili di ambiente nelle funzioni Lambda
   Le funzioni Lambda sono servizi di calcolo senza server che monitorano l'ambiente. Quando si crea una funzione Lambda, è possibile assegnare delle variabili d'ambiente, che possono essere utilizzate dal codice all'interno della funzione. Spesso queste variabili includono segreti, come chiavi API o anche credenziali di accesso. Le variabili d'ambiente possono essere estratte da un aggressore se esiste una vulnerabilità di iniezione di codice nel codice. Inoltre, gli aggressori interni possono leggere le variabili d'ambiente configurate in chiaro.

Un ambiente conforme vulnerabile

Per verificare se gli ambienti cloud effettivamente conformi sono a rischio per gli attacchi sopra menzionati, abbiamo creato un ambiente di test AWS. Tutte queste vulnerabilità sono state sviluppate in scenari implementabili con l'uso di Terraform. Terraform è uno strumento software infra-as-code, che consente agli utenti di definire il codice dell'infrastruttura. Questo assicura che ogni volta che gli scenari vengono distribuiti, siano esattamente gli stessi e non richiedano configurazioni manuali.

L'ambiente di test AWS è stato configurato per essere conforme ai diversi benchmark e standard di sicurezza. Poi le risorse sono state distribuite utilizzando Terraform. Dopo la distribuzione, l'ambiente è stato analizzato per assicurarsi che fosse ancora conforme agli standard di sicurezza.

Risultati

Ogni attacco è stato eseguito nell'ambiente di test. I risultati sono riportati nella tabella seguente, dove X indica che non è protetto e altrimenti viene visualizzato il controllo corrispondente:

I risultati indicano che il benchmark di sicurezza più comune, il benchmark CIS AWS Foundations, non protegge da nessuno degli attacchi implementati! Il framework offre un ambiente più sicuro, ma manca di difese approfondite per i servizi AWS più popolari e comunemente utilizzati, come EC2, S3 e Lambda.

Il framework Three-tier impedisce di avere snapshot EBS pubblici grazie ai controlli 1.5 e 1.6., ma altri attacchi o configurazioni errate sono ancora possibili. I controlli 1.5 e 1.6 assicurano che i volumi EBS siano crittografati. Questo impedisce che le istantanee vengano condivise pubblicamente, poiché la chiave di decodifica non è accessibile pubblicamente. Questo quadro è meno frequente, perché è più difficile da applicare alle architetture cloud generiche.

Lo standard AWS Foundational Security Best Practices offre una protezione migliore, soprattutto contro i bucket S3 esposti pubblicamente. I controlli S3.1 - S3.3 stabiliscono esplicitamente che i bucket non devono essere leggibili o scrivibili pubblicamente. In questo modo si evita la ragione numero uno delle violazioni di dati legate al cloud. Anche il controllo EC2.1 impedisce le istantanee EBS, ma anche con questa linea di base implementata, l'ambiente è ancora suscettibile per 4 dei 6 attacchi!

Informazioni su Secura

Scritto da Roy Stultiens. Roy è uno degli expert di Bureau Veritas Cybersecurity in materia di cloud. Con una forte passione per la sicurezza del cloud, è un membro attivo del gruppo di conoscenza del cloud. Insieme a questo gruppo, esegue regolarmente pentest sul cloud e condivide le esperienze con i colleghi e i clienti in questo campo in rapido sviluppo.

Note a piè di pagina:

[1] Center for Internet Securtiy: https://www.cisecurity.org.
[2] CIS Amazon Web Services Foundations White Paper: https: //d0.awsstatic.com/white...
[3] CIS Amazon Web Services Three-tierWeb White Paper: https: //d0.awsstatic.com/white...
[4] Standard AWS Foundational Security Best Practices: https://docs.aws.amazon.com/se...
[5] Server Side Request Forgery (SSRF) su EC2: https://youtu. be/6U-DpyEoVRs...
[6] Segreti memorizzati nei dati utente sulle istanze EC2: https: //youtu.be/-p5yCrrsTFA
[7] Dufflebag: Scoprire i segreti nei volumi EBS esposti: https: //labs.bishopfox.com/tec...
[8] Vulnerabilità di code injection nelle funzioni Lambda: https: //youtu.be/gl2hEmN67ms