Quanto sono sicure le macchine virtuali? Falso senso di sicurezza?

Le macchine virtuali possono sicuramente attraversare. Di solito li hai collegati in rete, quindi qualsiasi malware con un componente di rete (cioè i worm) si propagherà ovunque il loro indirizzamento / routing gli consenta. I virus normali tendono a funzionare solo in usermode, quindi mentre non potevano comunicare apertamente, potevano comunque creare un canale segreto. Se si condividono le CPU, un processo occupato su una VM può effettivamente comunicare lo stato su un'altra VM (che è il canale di copertura temporizzato prototipo). Lo storage covert channel sarebbe un po 'più difficile dato che i dischi virtuali tendono ad avere un limite rigido su di essi, quindi, a meno che tu non abbia un sistema in grado di sovrascrivere lo spazio su disco, non dovrebbe esserci un problema.

L'approccio più interessante alla protezione delle macchine virtuali è chiamato Kernel di separazione . È il risultato del documento del 1981 di John Rushby che in pratica afferma che per avere VM isolate in un modo che potrebbe essere equivalente alla separazione fisica, il computer deve esportare le risorse su macchine virtuali specifiche in un modo in cui nessuna risorsa in grado di memorizzare lo stato viene condivisa in nessun punto tra le macchine virtuali. Ciò ha conseguenze profonde, poiché richiede che l'architettura del computer sottostante sia progettata in modo tale che possa essere eseguita in modo non bypassabile.

30 anni dopo questo documento, abbiamo finalmente pochi prodotti che affermano di farlo. x86 non è la migliore piattaforma per questo, poiché ci sono molte istruzioni che non possono essere virtualizzate, per supportare pienamente l'idea di 'no sharing'. Inoltre, non è molto pratico per i sistemi comuni, in quanto per avere quattro VM, sono necessari quattro hard disk che pendono da quattro controller del disco, quattro schede video, quattro controller USB con quattro mouse, ecc.

Nel corso degli anni sono stati pubblicati alcuni white paper che descrivono i modi in cui i ricercatori sono riusciti a infestare un sistema operativo host da una VM. Questi sono visti, giustamente, come vulnerabilità di sicurezza da parte dei produttori di VM e trattati come tali. Da quando ho visto quei documenti per la prima volta, Intel ha apportato alcuni significativi miglioramenti al set di istruzioni del processore consentendo la separazione di VM e hypervisor.

Le poche vulnerabilità che vedo in questi giorni sono basate più sulla porzione 'vmtools'. Questo è il software che installi per rendere il SO guest più efficiente (per VMWare questo è ciò che consente l'acquisizione del cursore al volo e la condivisione tra guest e host senza rete). Questo è un percorso software speciale per l'infezione; non installare gli strumenti, non avere la vulnerabilità.

Alcuni malware hanno mostrato la capacità di rilevare che vengono eseguiti all'interno di una VM e quindi modificare il loro comportamento, con l'aggravante dei ricercatori di malware che tentano di utilizzare le macchine virtuali come metodo per testare il malware . Non so quanto sia prevalente in questi giorni, però.

Un esempio di esecuzione di codice guest-to-host può essere trovato nell'exploit Cloudburst. C'è un video dimostrativo e un documento di Immunity dettagli del loro successo su VMware Workstation 6.5.0 build118166 su Windows Vista SP1, VMware Workstation 6.5.1 build126130 su Windows Vista SP1 e (ancora più spaventoso) VMware ESX Server 4.0.0 build133495.

Questo probabilmente fornisce poco conforto, ma non ne ho mai sentito parlare in natura e l'exploit è del 2009. Quel libro è stato pubblicato nel 2010, quindi l'autore dovrebbe ripulire quella dichiarazione.

Una macchina virtuale è esattamente quella, una macchina separata logicamente, quindi deve avere gli stessi livelli di sicurezza posizionati su di essa come se fosse un sistema bare metal. L'uso di una macchina virtuale non fermerà un vul se utilizza i normali canali per raggiungere la macchina host.

La vera bellezza della virtualizzazione è la possibilità di ripristinare le VM in uno stato in cui non sono state effettuate, nonché la possibilità di gestire meglio le risorse disponibili.

Se vengono adottate le misure appropriate per proteggere la macchina host, la virtualizzazione può essere estremamente sicura. Pratiche come mantenere la gestione dei server ESX / VM su una rete logica diversa e non utilizzare gli strumenti di interfacciamento dell'host di macchine virtuali manterranno gli attaccanti per lo più ignari del fatto che una macchina è virtuale, per non dire come arrivare all'host.

Inoltre, ci sono exploit noti che influenzano gli host VM (li ho giocati con VMWare e Hyper-V). Sono al momento solo a conoscenza degli exploit DoS dell'host quando si tratta di hyper-v (vedere questo ), ma io sono certo ci sono altri reperti all'orizzonte. VMWare ne ha anche alcuni nella sua storia (es. questo , è basato su strumenti VMWare, ma è comunque valido).

A seconda di ciò che stai facendo, ci sono alcuni strumenti online che potrebbero essere in grado di eliminare la tua necessità di fare analisi sul tuo computer. Ecco alcuni siti per dare un'occhiata a:
 - Threatexpert.com
 - anubis.iseclab.org
 - virustotal.com

Ciò che si intende per il materiale Security + è che finora il malware non è stato in grado di sfuggire alla sandbox della VM sfruttando il fatto che si tratta di una VM e in qualche modo colpisce l'hypervisor. Altri meccanismi, come la diffusione su una rete condivisa, sono gli stessi come se si trattasse di box fisici diversi.

Non sono perfettamente sicuri, come dimostrato da questo exploit:

VENOM, CVE-2015-3456, è una vulnerabilità di sicurezza che influisce su alcune piattaforme di virtualizzazione dei computer comuni, in particolare Xen, KVM, VirtualBox e il client QEMU nativo.

Questa vulnerabilità può consentire a un utente malintenzionato di uscire dai confini di un guest di una macchina virtuale interessata e potenzialmente ottenere l'accesso di esecuzione del codice all'host. Più dettagli per quanto riguarda la vulnerabilità può essere trovato qui.

Penso che l'affermazione dell'autore sia non completamente true. In realtà, ci sono due tipi di hypervisor nell'area di virtualizzazione. Hypervisor è un pezzo di software, firmware o hardware che crea e esegue macchina virtuale s. Questi tipi sono:

• Hypervisor di tipo 1
• Hypervisor di tipo 2

L'ipervisore di tipo 1 esegue direttamente sull'hardware dell'host per controllare l'hardware e gestire i sistemi operativi guest. Per questo motivo, a volte vengono chiamati bare metal hypervisor mentre hypervisor di tipo 2 viene eseguito su un sistema operativo convenzionale proprio come fanno altri programmi per computer. VMWare o VirtualBox sono esempi di hypervisor di tipo 2 perché vengono eseguiti come programmi nel sistema host .

Per gli hypervisor di tipo 2, esiste un progetto RoboLinux che ha una funzione unica chiamata Stealth VM . Programma di installazione del software VM Stealth che consente di creare un clone di Windows 7 in esecuzione in una partizione Linux sicura . Il sistema è protetto dal malware, tutto ciò che scarichi sarà contenuto w nella macchina virtuale ed è destinato alle persone che devono avere un programma Windows specifico con la comodità di poter ripristinare il sistema operativo come nuovo in soli due clic.

C'è Qubes OS sviluppato su Linux e Xen come esempio per gli hypervisor di tipo 1. Qubes OS adotta un approccio chiamato sicurezza per isolamento , che in questo contesto significa mantenere le cose che fai sul tuo computer isolate in modo sicuro in diverse VM in modo che una VM venga compromessa vinta ' t influenza gli altri. A differenza degli hypervisor di tipo 2, dispone di un sistema di trasferimento file inter-VM sicuro per gestire il rischio di condivisione delle cartelle. In teoria, tale organizzazione è più sicura della virtualizzazione di tipo 2 in base agli sviluppatori.

In breve, l'autore dovrebbe indicare quale hypervisor o sistema virtuale.

Riferimenti :

• link
• link
• link
• link
• link

Di interesse e pertinenza, il concorso per la sicurezza "Pwn2Own" per il 2016 ha come una delle sue competizioni, sfuggire a una macchina virtuale VMWare Workstation. (Altri includono l'escape di sandbox del browser o il rilevamento di macchine fisiche). Questo dovrebbe dare l'idea che 1) è almeno plausibile e 2) se è facile allora abbiamo un modo per ascoltarlo - basta controllare il risultato:)

Più in generale la sicurezza delle macchine virtuali potrebbe in teoria essere sfuggita in molti modi. Ad esempio -

• Ospite per ospitare comandi e API (es. strumenti VMware)

• Debolezze sfruttabili nel sistema operativo host stesso che non vengono mitigate dall'esecuzione in un processo VM (se alcune chiamate del SO guest vengono giudicate erroneamente "sicure" e passate direttamente da un driver guest al SO host o al driver di dispositivo per velocità, ma esiste un exploit)

• Errori nei driver dei fornitori o nel codice fornitore (ad esempio, un driver host consente il bridging di rete per il sistema operativo guest, forse un bug potrebbe consentire l'esecuzione di chiamate o codice sull'host a livello di kernel). / p>

• Vulnerabilità derivante da altri software sull'host (esempio forzato - se l'antivirus locale intercetta tutto il traffico di rete dall'host per la scansione, e il traffico guest viene scansionato come parte di esso (al contrario di essere ignorato a causa della scheda di rete virtuale dispositivo), quindi una vulnerabilità del motore a / v a un traffico o pacchetto pericoloso potrebbe essere in grado di consentire al traffico proveniente dalla VM di uscire dall'host)

• Bad configuration per utente (file host mappati o non sufficientemente protetti / separati in modo che l'ospite possa raggiungerli)

L'ambito esiste e, data la sua prevalenza, è sicuramente esaminato attivamente per gli exploit. Sicuramente le vulnerabilità se non gli exploit verranno trovate regolarmente e necessitano di patching.

Gli exploit progettati specificamente per l'esecuzione in vms e bug di destinazione nel kernel host sottostante sono inevitabili. Cercali prima nelle popolari piattaforme cloud.