it-swarm.it

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

Stavo leggendo questo CompTIA Security + SYO-201 book e l'autore David Prowse afferma che:

Qualunque sia VM selezionato, il VM non può oltrepassare i confini del software impostati in atto. Ad esempio, un virus potrebbe infettare un computer quando eseguito e diffuso in altri file nel sistema operativo. Tuttavia, un virus eseguito in un VM si diffonderà attraverso il VM ma non influenzerà il sistema operativo reale sottostante.

Quindi, se eseguo VMWare player ed eseguo malware sul sistema operativo della mia macchina virtuale, non devo preoccuparmi che il mio sistema Host venga compromesso, in tutto ?

Cosa succede se la macchina virtuale condivide la rete con la macchina host e le cartelle condivise sono abilitate?

Non è ancora possibile che un worm si copi sulla macchina host in quel modo? L'utente non è ancora vulnerabile ad AutoRun se il sistema operativo è Windows e inserisce un dispositivo di archiviazione USB?

Quanto sono sicure le macchine virtuali, davvero? Quanto proteggono la macchina host da malware e attacchi?

163
T. Webster

Le macchine virtuali possono sicuramente attraversare. Di solito li hai collegati in rete, quindi qualsiasi malware con un componente di rete (ad esempio worm) si propagherà ovunque dove il loro indirizzamento/routing lo consente. I virus regolari tendono a funzionare solo in modalità utente, quindi mentre non sono in grado di comunicare apertamente, possono comunque creare un canale nascosto. Se condividi CPU, un processo occupato su uno VM può comunicare efficacemente lo stato a un altro VM (questo è il tuo canale nascosto di temporizzazione prototipo). essere un po 'più difficile in quanto i dischi virtuali tendono ad avere un limite rigido su di essi, quindi a meno che non si disponga di un sistema in grado di impegnare eccessivamente lo spazio su disco, non dovrebbe essere un problema.

L'approccio più interessante per proteggere le VM è chiamato Separation Kernel . È il risultato del 1981 paper di John Rushby, che afferma sostanzialmente che per far isolare le VM in un modo che potrebbe essere equivalente alla separazione fisica, il computer deve esportare le sue risorse su VM specifiche in un modo in cui nessun punto qualsiasi risorsa che può memorizzare lo stato è condivisa tra macchine virtuali. Ciò ha conseguenze profonde, in quanto richiede che l'architettura del computer sottostante sia progettata in modo tale da poter essere eseguita in modo non bypassabile.

30 anni dopo questo articolo, abbiamo finalmente pochi prodotti che affermano di farlo. x86 non è la migliore piattaforma per esso, poiché ci sono molte istruzioni che non possono essere virtualizzate, per supportare pienamente l'idea di "nessuna condivisione". Inoltre, non è molto pratico per i sistemi comuni, in quanto per avere quattro VM, avresti bisogno di quattro hard disk sospesi su quattro controller del disco, quattro schede video, quattro controller USB con quattro mouse, ecc.

91
Marcin

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 macchina virtuale. Questi sono di solito visti, giustamente, come vulnerabilità di sicurezza dai venditori VM e trattati come tali. Da quando ho visto quei documenti per la prima volta, Intel ha apportato alcuni significativi miglioramenti alle istruzioni del processore per consentire la separazione di VM e hypervisor.

Le poche vulnerabilità che vedo in questi giorni si basano maggiormente nella parte "vmtools". Questo è il software che installi per far funzionare il SO guest in modo più efficiente (per VMWare questo è ciò che consente l'acquisizione al volo del cursore e la condivisione tra guest e Host senza una rete). Questo è un percorso software speciale per l'infezione; non installare gli strumenti, non hanno la vulnerabilità.

Alcuni malware hanno mostrato la capacità di rilevare che vengono eseguiti all'interno di un VM e quindi cambiano il loro comportamento, con grande aggravamento dei ricercatori di malware che tentano di usare VM come un modo per testare il malware. Non so quanto sia prevalente in questi giorni, però.

63
sysadmin1138

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

Ciò probabilmente fornisce poco conforto, ma non ho mai sentito parlare di questo uso in natura e l'exploit è del 2009. Quel libro è stato pubblicato nel 2010, quindi l'autore dovrebbe ripulire questa affermazione.

24
harley

Una macchina virtuale è esattamente quella, una macchina logicamente separata, 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 arresterà una vul se utilizza canali normali per accedere alla macchina host.

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

Se vengono prese le misure appropriate per proteggere la macchina host, la virtualizzazione può essere estremamente sicura. Pratiche come mantenere la gestione del server ESX/VM su una diversa rete logica e non utilizzare gli strumenti di interfaccia VM-Host manterranno gli aggressori per lo più ignari del fatto che una macchina è virtuale, figuriamoci su come raggiungere l'host.

Inoltre, ci sono exploit noti che effetti VM (ho giocato con loro in VMWare e Hyper-V). Al momento sono a conoscenza solo degli exploit di Host DoS quando si tratta di hyper- v (vedi this ), ma sono sicuro che ci sono altri risultati all'orizzonte. VMWare ne ha anche alcuni nella sua storia (es. this , è basato su strumenti VMWare, ma si applica ancora).

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

19
Ormis

Ciò che si intende per materiale Security + è che finora il malware non è stato in grado di sfuggire alla sandbox del VM sfruttando il fatto che è un VM e in qualche modo colpire l'hypervisor. Altri meccanismi, come la diffusione su una rete condivisa, sono gli stessi di una scatola fisica diversa.

7
K. Brian Kelley

Non sono perfettamente sicuri, come dimostrato con 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 della macchina virtuale (VM) interessata e potenzialmente ottenere l'accesso all'esecuzione di codice all'host. Maggiori dettagli sulla vulnerabilità può essere trovato qui.

5

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

  • Hypervisor di tipo 1
  • Hypervisor di tipo 2

L'hypervisor di tipo 1 viene eseguito direttamente sull'hardware dell'host per controllare l'hardware e gestire i sistemi operativi guest. Per questo motivo, a volte vengono chiamati hypervisor bare metal considerando L'hypervisor di tipo 2 viene eseguito su un sistema operativo convenzionale proprio come fanno altri programmi per computer. VMWare or VirtualBox sono esempi di hypervisor di tipo 2 perché eseguiti come programmi in Host [~ # ~] os [~ # ~ ] s.

Per gli hypervisor di tipo 2, esiste un progetto RoboLinux che ha una caratteristica unica chiamata VM invisibile . Stealth VM software installer che ti permette di creare un clone di Windows 7 in esecuzione in una partizione Linux sicura . Il sistema è protetto da malware, tutto ciò che scarichi sarà contenuto w all'interno della macchina virtuale ed è destinato a persone che devono avere un programma Windows specifico con la comodità di poter ripristinare il sistema operativo come nuovo in soli due clic.

Esiste Qubes OS sviluppato su Linux e Xen come esempio per hypervisor di tipo 1. Il sistema operativo Qubes adotta un approccio chiamato sicurezza per isolamento , che in questo contesto significa mantenere le cose che fai sul tuo computer in modo sicuro isolato in VM diverse in modo che una VM compromessa non influirà sulle altre. A differenza degli hypervisor di tipo 2, ha un sicuro sistema di trasferimento file inter-VM per gestire il rischio di condivisione delle cartelle In teoria, l'organizzazione è più sicura della virtualizzazione di tipo 2 secondo gli sviluppatori.

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

Riferimenti :

4
JackSparrow

Di interesse e rilevanza, il concorso di sicurezza "Pwn2Own" per il 2016 ha come uno dei suoi concorsi, la fuga da una macchina virtuale VMWare Workstation. (Altri includono la fuga dai sandbox del browser o l'assunzione di macchine fisiche). Ciò dovrebbe dare l'idea che 1) sia almeno plausibile e 2) se è facile, allora abbiamo un modo per ascoltarlo - basta controllare il risultato :)

Più in generale VM potrebbe in teoria essere sfuggita in molti modi. Ad esempio -

  • Comandi e API da ospite a host (ad esempio strumenti VMware)

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

  • Bug nei driver del fornitore o nel codice del fornitore (ad esempio, un driver host consente il bridging di rete per il sistema operativo guest; forse un bug al suo interno potrebbe consentire di effettuare chiamate o codice sull'host a livello di kernel).

  • Vulnerabilità risultanti da altri software sull'Host (esempio inventato - se l'antivirus locale intercetta tutto il traffico di rete dall'Host da scansionare e il traffico degli ospiti viene scansionato come parte di quello (invece di essere ignorato a causa di virtual NIC dispositivo), quindi una vulnerabilità del motore a/v a un traffico o pacchetto pericoloso può essere in grado di consentire il traffico proveniente dal VM per sfuggire all'host)

  • Configurazione errata da parte dell'utente (file host mappati o insufficientemente sicuri/separati in modo che l'ospite possa raggiungerli)

Il campo di applicazione esiste e, data la sua prevalenza, viene sicuramente esaminato attivamente alla ricerca di exploit. Sicuramente le vulnerabilità, se non gli exploit, verranno regolarmente rilevate e necessitano di patch.

4
Stilez