Cloud: una soluzione appetibile a molti utenti, ma occhio alle vulnerabilità

Quando si parla di cloud ci vengono in mente belle immagini di persone sorridenti e felici di aver depositato una enorme mole di dati lontano, in un posto dove non devono occuparsi di guasti hardware, sistemi di failover e ridondanza, problemi di connettività e raggiungibilità, né di backup. Dal punto di vista della sicurezza fisica (con tutti i disclaimer del caso) ci sentiamo piuttosto rincuorati e ci passano tutte le ansie.

Simona Venuti
GARR
Servizio GARR CERT
Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.

Il prezzo dello spazio disco è molto basso per ogni servizio che si desidera, e ciò rende questo tipo di soluzione appetibile soprattutto per quelle realtà che non hanno risorse sia economiche che umane da investire, tanto più che spesso i servizi offerti includono feature allettanti, tipo la protezione dai DDoS, piattaforme accattivanti e di semplice utilizzo per gestire tutti i servizi che vogliamo sviluppare. La maggior parte delle volte integrano in un’unica interfaccia diversi sistemi di accesso ai server (web, ssh, ftp, mySQL, etc) e, di solito, hanno la possibilità di gestire più server contemporaneamente con un solo click.

Ma come spesso succede, aumentare la semplicità d’uso significa introdurre nel sistema parti di codice che potenzialmente potrebbero essere vulnerabili per via di SQLi, apposite forged request malevole, cross site scripting o semplici malcofigurazioni da parte degli utenti. È la legge formulata da Mikko Hypponen, Chief Research Officer di F-Secure: ogni apparato smart è vulnerabile.

Queste vulnerabilità, unite al fattore umano che, grazie alla facilità d’uso, non è necessario che sia particolarmente esperto, possono costituire un mix di ingredienti micidiale per la sicurezza dei nostri dati in cloud. È quel che è successo lo scorso novembre, quando da più parti nel mondo è stato segnalato un problema grave sui bucket di molti fornitori di soluzioni cloud, fra cui AWS di Amazon, Google, Azure, Accenture, Dropbox.

Un bucket è, nella nomenclatura del cloud, un generico contenitore dove vengono depositati i file di un utente: può essere una cartella dove stanno documenti, come nel caso di Dropbox, interi siti web come nel caso di Amazon AWS, oppure intere macchine virtuali, come nel caso di VMware e OpenStack.

Pur con le specificità di ogni piattaforma, il problema è sempre lo stesso: una vulnerabilità nel software di gestione delle piattaforme e nella configurazione dei bucket, così grave da permettere ad un utente qualsiasi, sia autenticato che non, di visualizzare tutti i file di altri bucket non suoi, e in alcuni casi anche di cambiar loro i permessi oppure ottenere i privilegi di root.

Vediamo nel dettaglio come è andata con Amazon AWS. Per semplificare la gestione dei server web, AWS mette a disposizione un servizio che si chiama Amazon Metadata Services attraverso la propria applicazione di gestione cloud fornita agli utenti. Qualsiasi applicazione voglia accedere ai dati sul cloud, il servizio chiede al Metadata Service un set di credenziali temporanee per accedere; queste credenziali possono essere usate sia per accedere ai propri servizi S3 che ad altro sulla piattaforma. Il Metadata Service è utilizzato dagli sviluppatori anche per immagazzinare i dati di configurazione delle applicazioni, che permettono di preparare o modificare in contemporanea un elevato numero di server “tutti uguali”.

Sebbene questo tipo di servizio sia un sogno per tutti gli sviluppatori, perché scala molto facilmente con un semplice comando, dal punto di vista della sicurezza non si è rivelato molto robusto: prima di tutto l’interfaccia di gestione della cloud e il Metadata Service parlano fra di sé scambiandosi dati in chiaro, cosa che farebbe drizzare le orecchie a chiunque, ma il problema più grosso è nell’unico file dei metadati, in cui sono immagazzinate tutte le informazioni di configurazione, accesso e script di avvio per tutti i sistemi di un utente. Come sappiamo, spesso i file di startup di una applicazione contengono credenziali per l’accesso a database e l’elenco dei file di configurazione: informazioni molto importanti. Ebbene, questo file di metadati può essere scaricato e consultato dall’interfaccia utente della cloud semplicemente inserendolo col path opportuno nella barra degli indirizzi del browser!

In questo file troviamo le chiavi di accesso ai bucket e ai loro servizi dei bucket: AccessKeyID, SecretAccessKey, Token. Queste informazioni hanno valori diversi a seconda del bucket che stiamo indagando: possono essere semplici configurazioni, file innocui, ma anche coppie di utente/password, anche di root, a seconda dalla fortuna che si ha. Anche nel caso in cui non siamo stati molto fortunati e non abbiamo ottenuto nessun accesso root, abbiamo ottenuto sicuramente un accesso non privilegiato all’interfaccia cloud e possiamo andare avanti a sfruttarne le vulnerabilità. Per esempio, entrando con l’utente non privilegiato appena trovato nell’interfaccia Amazon della gestione dei permessi (IAM, cioè Identity and Access Management), potremmo creare un nuovo utente e dargli gli accessi che ci mancavano! Per esempio possiamo farlo accedere alle istanze EC2 (cioè alle immagini virtuali delle macchine in cloud). Una volta che accediamo all’immagine di un server possiamo fare qualsiasi cosa, come se fossimo sulla console del virtualizzatore... Creare snapshot al volo, montare o smontare dischi, visualizzare il contenuto, creare chiavi ssh per aprire backdoor… Basta solo un po’ di fantasia!

Tutto questo è semplicemente frutto di quel famoso mix di software di gestione vulnerabile e configurazioni troppo aperte da parte dell’utente. Questa grave vulnerabilità ha colpito moltissimi siti web che facevano uso di risorse cloud: da quelli di alcune banche, alla famosa azienda Accenture, all’indice Dow Jones (quello della Borsa di New York), al database del Republican National Committee (un comitato del Partito Repubblicano americano che si occupa di profilare circa 200 milioni di persone del loro database in base a etnia, età, religione per sviluppare previsioni di voto), e infine, ciliegina sulla torta, anche a INSCOM: un’organismo governativo americano, creato dalla collaborazione fra esercito americano e NSA, che non solo aveva a disposizione tutta una serie di file e cartelle, ma anche l’immagine VirtualBox di una macchina (un file .OVA) dentro alla quale c’erano file e documenti classificati come top secret o NOFORN.

Alla luce di quanto potrebbe succedere, diventa quindi molto importante, qualora si volessero utilizzare o acquistare questi tipi di servizi, tenere presente i problemi che abbiamo discusso e metterli ben in evidenza in una eventuale analisi dei rischi: bisogna capire bene anche come funziona l’interfaccia di gestione, non sono importanti soltanto il sistema operativo, la connettività, il firewall che può essere messo davanti alle macchine, oppure la qualità del Service Level Agreement. Si tratta di un aspetto difficile da valutare, la cui soluzione non è banale né univoca.

Dovendo dare un consiglio, ritengo che probabilmente scegliere soluzioni open source, come per esempio Open- Stack, la piattaforma usata anche da GARR, possa dare più tranquillità rispetto a questi problemi. Sono ampiamente supportate e utilizzate ovunque, hanno il loro “dizionario di vulnerabilità” (CVE, cioè Common Vulnerabilities and Exposures) per la divulgazione delle vulnerabilità, in modo da venir risolte prima possibile, hanno un sistema molto granulare e versatile di assegnazione dei permessi per configurare, gestire e mantenere i bucket in maniera sicura, e delle guide molto dettagliate a riguardo, e sono comunque molto integrabili con altri sistemi di autenticazione (tipo SSO) tramite API ben documentate.