Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

LO SCENARIO

Cloudborne, la vulnerabilità che espone il cloud ad attacchi hacker: che c’è da sapere

Cloudborne è una vulnerabilità dei server cloud che consente agli hacker di comprometterne il firmware con una backdoor persistente che espone i nuovi utenti dei servizi cloud a possibili attacchi. Uno scenario che potrebbe mettere in discussione l’efficacia del modello IaaS (Infrastructure as a Service). Ecco perché

09 Apr 2019
V

Massimo Valeri

Senior Consultant in ambito Risk Management & Data Protection


Gli esperti di sicurezza della rete e di hacking etico dell’International Institute of Cyber Security riportano la scoperta di una nuova vulnerabilità denominata “Cloudborne” che consente agli hacker di lasciare backdoor nel firmware dei server fisici che vengono riassegnati ad altri utenti dei servizi cloud, lasciando i nuovi utenti vulnerabili a più attività di hacking.

Molti sviluppatori di software scelgono, a questo proposito, il modello IaaS (Infrastructure as a Service): questa opzione consente di far barcollare facilmente le applicazioni basate su cloud senza dover condividere il proprio hardware con altri utenti.

Il problema è che, secondo gli specialisti della sicurezza di rete, una volta che un’azienda decide di smettere di usare questo hardware, questi server possono essere ripristinati secondo le impostazioni originali ed essere riassegnati ad altri utenti, esponendoli a vulnerabilità del firmware che possono persistere anche dopo il ripristino dei processi.

Cloudborne, la nuova vulnerabilità del cloud

Recentemente, il team di Eclypsium, società di ricerca nel campo della sicurezza informatica, ha rilasciato un report sui problemi di sicurezza del firmware che ritengono rappresentare “una lacuna fondamentale” nella sicurezza delle infrastrutture cloud. Le loro scoperte mostrano che i controller di gestione di base (BMC) integrati nei server cloud possono mettere a rischio la sicurezza informatica dei clienti. Il loro studio si basa sulla tecnologia IBM SoftLayer, ma sottolineano che anche altri fornitori potrebbero essere esposti.

Nello specifico, hanno scoperto che uno scenario di attacco che interessa vari provider di cloud potrebbe consentire ad un hacker malintenzionato di implementare backdoor nel firmware dell’infrastruttura condivisa nel cloud. La backdoor può sopravvivere al processo di riassegnazione del server eseguito dai fornitori di servizi. Per rimuovere la backdoor è necessario connettersi fisicamente ai chip per creare nuovamente il firmware, compito non pratico per i service provider.

Ciò apre la porta ad una vasta gamma di attacchi alle aziende che utilizzano le offerte IAAS.

Nello scenario della vulnerabilità in questione, un utente malintenzionato può utilizzare innanzitutto una vulnerabilità nota nell’hardware Supermicro, presente in molte infrastrutture di provider cloud, per sovrascrivere il firmware di un Baseboard Management Controller (BMC). I BMC sono componenti di terze parti progettati per consentire la gestione remota di un server per il provisioning iniziale, la reinstallazione del sistema operativo e la risoluzione dei problemi.

Dunque, gli hacker potrebbero compromettere i server aggiungendo backdoor e codice dannoso al firmware di un server fisico o al proprio Baseboard Management Controller (BMC), che richiede capacità di hacking minime.

Possibili scenari di attacco

Con una backdoor disponibile sul firmware, un utente malintenzionato sarebbe in grado di sovvertire i controlli e le misure di sicurezza del sistema operativo host e dei livelli di virtualizzazione di un server.

Se viene sfruttata la vulnerabilità, diversi scenari di attacco potrebbero presentarsi, come ad esempio i seguenti:

  • Denial of Service permanente (PDoS);
  • intercettazione e/o furto di dati dell’applicazione eseguiti sul server compromesso, dal momento che gli hacker sono in grado di ottenere l’accesso ai dati memorizzati sull’host fisico;
  • esecuzione di malware o disabilitazione dell’applicazione in esecuzione;
  • attacchi contro il firmware su drive e adattatori di rete che darebbero agli aggressori un modo semplice per rubare o intercettare i dati.

Sono possibili anche attacchi ransomware. Con la possibilità di disabilitare le applicazioni e danneggiare i dati, gli hacker sono infatti naturalmente in grado di eseguire attacchi ransomware ad alto impatto.

Inoltre, l’impianto potrebbe essere utilizzato per compromettere altre parti dell’infrastruttura. Questo in quanto BMC è un componente altamente privilegiato che utilizza l’IPMI (Intelligent Platform Management Interface) per comunicare con il software in esecuzione sul processore host. Queste comunicazioni sono senza sessioni e, come tali, non hanno un metodo per l’autenticazione.

I malware possono potenzialmente inviare comandi IPMI malevoli su interfacce di sistema dall’host senza che i comandi vengano autenticati. Poiché non viene eseguita l’autenticazione quando si utilizzano le interfacce di sistema, l’unico ostacolo all’esecuzione di codice arbitrario all’interno di BMC è che il BMC stesso esegua la verifica della firma crittograficamente sicura dell’immagine di aggiornamento del firmware prima di applicare l’aggiornamento. Sfortunatamente, non tutti i BMC eseguono questo controllo, e anche quando lo fanno, il malware può sfruttare le vulnerabilità del firmware BMC per aggirarlo.

Esperimento compiuto sulla piattaforma cloud di IBM

I servizi IBM IaaS di SoftLayer sono stati testati per vedere se poteva essere impiantata una backdoor persistente che sarebbe sopravvissuta alla migrazione dei clienti. I ricercatori hanno sottolineato che quanto testato nell’esperimento è comune a molti fornitori di servizi cloud e non deve essere considerato limitato a IBM SoftLayer. Infatti, sebbene la ricerca sia stata condotta testando i server della piattaforma cloud SoftLayer di IBM, anche altre società che forniscono questo tipo di servizi potrebbero essere vulnerabili a questo vettore di attacco.

Il team di ricercatori di Eclypsium, nello svolgere le sue prove, ha acquisito l’accesso a un server bare metal tramite il servizio IaaS, con l’obiettivo di apportare una piccola modifica al firmware BMC, rilasciarlo nuovamente a IBM e quindi riacquisire lo stesso dispositivo da un altro account utente per verificare se la modifica sarebbe sopravvissuta al processo di migrazione.

A valle del provisioning del server, suddiviso in modo quasi uniforme tra le fasi di provisioning del sistema operativo (DEPLOY) e di configurazione (DEPLOY2), è stato verificato che il server disponesse del firmware BMC più recente. Dopodiché, ha apportato una modifica di aggiornamento al firmware e ha creato un utente IPMI aggiuntivo con accesso amministrativo ai canali BMC. Il sistema è stato quindi restituito a IBM.

Dopo aver eseguito più richieste di provisioning bare metal da un altro account, il team è stato in grado di riacquisire lo stesso componente hardware, convalidandolo con lo chassis e i numeri di serie del prodotto registrati in precedenza.

Dall’esperimento è risultato che, mentre l’utente IPMI aggiuntivo veniva rimosso durante il processo di recupero, la modifica del firmware era invece restata inalterata, ad indicare che il firmware non era stato nuovamente ricaricato.

Inoltre, i log di BMC sono stati mantenuti attraverso il provisioning e la password di root di BMC è rimasta la stessa per il provisioning. Non eliminando i registri, un nuovo utente ha dunque la possibilità di ottenere informazioni sulle azioni e sui comportamenti del precedente proprietario del dispositivo. Nel frattempo, la conoscenza della password di root di BMC consentirebbe a un utente malintenzionato di ottenere più facilmente il controllo sulla macchina in futuro.

La risposta di IBM

Il team di Eclypsium ha comunicato a IBM le proprie conclusioni in un rapporto dettagliato. In risposta, IBM ha riconosciuto il problema, affermando di aver affrontato le debolezze derivate dalla vulnerabilità Cloudborne, e ha fatto sapere pubblicamente di aver affrontato la tematica, senza tuttavia riscontrare traccia del fatto che la vulnerabilità fosse stata sfruttata a scopi dannosi.

IBM ha comunque intimato a tutti i BMC, compresi quelli col firmware aggiornato, a ricorrere nuovamente al firmware di fabbrica prima di essere forniti nuovamente ai clienti futuri.

Chiaramente, l’approccio seguito da IBM nella sanificazione dei server, prima della loro redistribuzione, è un buon inizio, ma non una risoluzione del problema. Il processo di aggiornamento del firmware può essere infatti compromesso con firmware dannoso e un utente malintenzionato che esegua il flashing di un firmware personalizzato può impedire ai provider di rilevare l’immagine backdoor. È stato infatti rilevato come esistano strumenti pubblici per creare immagini firmware personalizzate per i componenti Supermicro; gli attaccanti possono usarli per ottenere l’accesso.

In ogni caso, stando a quanto riportato da IBM, il BMC ha una potenza di elaborazione e di memoria limitate, il che rende difficile questo tipo di attacchi. Inoltre, tutti i client del cloud di IBM ricevono una rete privata per i propri BMC, separati dalle reti private contenenti BMC di altri client o BMC non sottoposti a provisioning.

Se quindi da un lato IBM ha classificato questa problema come una vulnerabilità di “bassa severità”, Eclypsium, servendosi del metodo CVSS 3.0, ha classificato il problema come critico, assegnando alla vulnerabilità un punteggio di 9.3 su una scala di severità da 1 a 10.

Mitigare la issue è infatti complicato. Un utente malintenzionato con accesso al server può tranquillamente ignorare l’autenticazione quando utilizza l’utente IPMI e creare account amministrativi o inviare un’immagine dannosa al BMC, come fatto da Eclypsium. Il reflashing è gestito dal firmware BMC, quindi gli hacker possono accedere anche se il provider ripristina una versione factory.

@RIPRODUZIONE RISERVATA

Articolo 1 di 5