it-swarm-eu.dev

Jak bezpečné jsou virtuální stroje opravdu? Falešný pocit bezpečí?

Četl jsem to CompTIA Security + SYO-201 kniha a autor David Prowse tvrdí, že:

Ať už VM, kterou vyberete, VM nemůže překročit nastavené softwarové hranice). Například virus může infikovat počítač, když je spuštěn a rozšířen do jiných souborů. v OS. Avšak virus spuštěný v VM se bude šířit skrze VM), ale neovlivní základní skutečný operační systém.

Pokud tedy provozuji přehrávač VMWare a spouštím malware na operačním systému mého virtuálního počítače, nemusím si dělat starosti s kompromitací mého hostitelského systému na všechny?

Co když virtuální počítač sdílí síť s hostitelským počítačem a jsou povoleny sdílené složky?

Není stále možné, aby se červ červi zkopíroval tímto způsobem do hostitelského počítače? Není uživatel stále náchylný k automatickému spuštění, pokud je operační systém Windows a vkládají úložné zařízení USB?

Jak bezpečné jsou virtuální stroje, opravdu? Kolik chrání hostitelský počítač před malwarem a útoky?

163
T. Webster

VM mohou určitě překročit. Obvykle je máte připojené k síti, takže jakýkoli malware se síťovou součástí (tj. Červy) se bude šířit kamkoli jim to umožní jejich adresování/směrování. Pravidelné viry mají tendenci fungovat pouze v usermode, takže i když nemohli zjevně komunikovat, mohli si přesto vytvořit skrytý kanál. Pokud sdílíte CPU, může zaneprázdněný proces na jednom VM efektivně komunikovat stav s jiným VM (to je váš prototypový skrytý kanál prototypu)). být o něco těžší, protože virtuální disky mají na ně tendenci mít pevný limit, takže pokud nemáte systém, který dokáže nadměrně uvolnit místo na disku, nemělo by to být problém.

Nejzajímavější přístup k zabezpečení virtuálních počítačů se nazývá separační jádro . Je to výsledek článku Johna Rushbyho z roku 1981 , který v podstatě uvádí, že aby byly virtuální počítače izolovány způsobem, který by mohl být ekvivalentní fyzickému oddělení, musí počítač exportujte své zdroje do konkrétních virtuálních počítačů tak, aby v žádném okamžiku nebyly sdíleny žádné prostředky, které mohou ukládat stav mezi VM. To má hluboké důsledky, protože vyžaduje, aby základní počítačová architektura byla navržena takovým způsobem, aby to bylo možné provést bez přemostění.

30 let po tomto článku máme konečně několik produktů, které to tvrdí. x86 pro ni není největší platformou, protože existuje mnoho instrukcí, které nelze virtualizovat, aby plně podporovaly myšlenku „no share“. Pro běžné systémy to také není příliš praktické, protože pokud máte čtyři virtuální počítače, budete potřebovat čtyři pevné disky zavěšené na čtyřech diskových řadičích, čtyři grafické karty, čtyři řadiče USB se čtyřmi myšmi atd.

91
Marcin

V průběhu let vyšlo několik publikací popisujících způsoby, kterými se vědcům podařilo zamořit hostitelský operační systém z VM. Obvykle se na ně správně nahlíží jako na bezpečnostní chyby dodavatelů VM) a zachází se s nimi jako s takovými. Od té doby, co jsem tyto papíry poprvé viděl, Intel provedl některá významná vylepšení sady instrukcí pro procesory umožňující oddělení VM a hypervisor).

Těch několik zranitelností, které vidím v těchto dnech, je založeno více v části „vmtools“. Toto je software, který instalujete, aby zajistil efektivnější provoz hostujícího OS (pro VMWare to umožňuje to, aby bylo možné zachytit kurzor za letu a sdílet mezi hostem a hostitelem bez sítě). Toto je speciální softwarová cesta k infekci; neinstalujte nástroje, nemají chybu zabezpečení.

Některé malware ukázaly schopnost detekovat, že jsou prováděny uvnitř a VM a tím změnit své chování, hodně ke zhoršení výzkumníků malwaru, kteří se pokoušejí používat VM) jako způsob, jak testovat malware. Nevím však, jak je v dnešní době převládající.

63
sysadmin1138

Příklad provádění kódu host-to-Host lze nalézt ve využití cloudburst. K dispozici je video demonstrující a papír od Immunity podrobně jejich úspěch na VMware Workstation 6.5.0 build118166 na Windows Vista SP1, VMware Workstation 6.5.1 build126130 na Windows Vista SP1 a (ještě strašidelnější) VMware ESX Server 4.0.0 build133495.

To pravděpodobně poskytuje malé pohodlí, ale nikdy jsem neslyšel o tom, že se to používá ve volné přírodě a jeho využití je z roku 2009. Tato kniha byla vydána v roce 2010, takže autor by měl toto prohlášení vyčistit.

24
harley

Virtuální stroj je přesně to, logicky samostatný stroj, takže musí na něm být umístěny stejné bezpečnostní vrstvy jako u holého kovového systému. Používání virtuálního počítače nezastaví vul, pokud používá normální kanály pro přístup k hostitelskému počítači.

Skutečnou krásou virtualizace je schopnost vrátit VM do stavu, ve kterém nebyly provedeny, a také schopnost lépe spravovat dostupné zdroje.

Pokud jsou podniknuty správné kroky k ochraně hostitelského počítače, může být virtualizace velmi bezpečná. Postupy, jako je správa serverů ESX/VM na jiné logické síti a nepoužívání nástrojů rozhraní VM-Host, udržují útočníky většinou nevšímaví skutečnosti, že počítač je virtuální, natož jak se dostat k hostiteli.

Existují také známé exploity, které ovlivňují hostitele VM hosts (s nimi jsem si hrál v VMWare a Hyper-V)). V současné době jsem si vědom zneužití hostitele DoS, pokud jde o hyper- v (viz toto ), ale jsem si jistý, že v horizontu existují i ​​další nálezy. VMWare má také něco ve své historii (tj. toto , je to založeno na nástrojích VMWare, ale stále platí).

V závislosti na tom, co děláte, existuje několik online nástrojů, které mohou být schopny odnést vaši potřebu provést analýzu na vašem vlastním počítači. Zde je několik stránek, na které se můžete podívat:
- Threatexpert.com
- anubis.iseclab.org
- virustotal.com

19
Ormis

Materiálem Security + se míní to, že malware dosud nebyl schopen uniknout z karantény VM prostřednictvím využití skutečnosti, že jde o VM) a nějak zasáhne hypervizora. Další mechanismy, jako je šíření po sdílené síti, jsou stejné, jako kdyby šlo o různé fyzické schránky.

7
K. Brian Kelley

Nejsou zcela bezpečné, jak dokazuje tato exploitace:

VENOM, CVE-2015-3456, je chyba zabezpečení, která ovlivňuje některé běžné platformy virtualizace počítačů, zejména Xen, KVM, VirtualBox a nativního klienta QEMU.

Tato chyba zabezpečení může útočníkovi umožnit, aby unikl z omezení hosta ohroženého virtuálního počítače (VM) a případně získal přístup k hostiteli k provádění kódu. Více podrobností o zranitelnosti najdete zde.

5

Myslím, že tvrzení autora je ne úplně pravda. Ve virtualizační oblasti jsou ve skutečnosti dva typy hypervisor. Hypervisor je část počítačového softwaru, firmwaru nebo hardwaru, která vytváří a běží virtuální stroj s . Jedná se o tyto typy:

  • Typ 1 hypervizorů
  • hypervizory typu 2

Hypervisor typu 1 spouští přímo na hardwaru hostitele pro ovládání hardwaru a pro správu hostovaných operačních systémů. Z tohoto důvodu se někdy nazývají holý kov hypervizory zatímco Hypervisor typu 2 běží na konvenčním operačním systém stejně jako jiné počítačové programy. VMWare nebo VirtualBox jsou příklady hypervizoru typu 2, protože jsou spouštěny jako programy v hostiteli [~ # ~] os [~ # ~ ] s.

Pro hypervizory typu 2 existuje RoboLinux projekt, který má jedinečnou funkci nazvanou Stealth VM. Stealth VM instalační program softwaru, který vám umožní vytvořit klon Windows 7 spuštěný v zabezpečeném linuxovém oddíl. Systém je chráněn před malwarem, vše, co stáhnete, bude obsaženo w ithin the virtual machine a je určeno pro lidi, kteří musí mít specifický program Windows s pohodlím, aby mohli obnovit operační systém jako nové pouhými dvěma kliknutími.

Jako příklad pro --- existuje Qubes OS, který je vyvinut na Linux a Xen Hypervizory typu 1. Operační systém Qubes používá přístup zvaný zabezpečení pomocí izolace, což v této souvislosti znamená udržovat věci, které děláte na svém počítači, bezpečně izolované v různých virtuálních počítačích, takže jeden VM nebude mít na ostatní dopad. Na rozdíl od hypervizorů typu 2 má zabezpečený inter-VM systém přenosu souborů, který zvládne riziko sdílení složek. Teoreticky je tato organizace bezpečnější než virtualizace typu 2 podle vývojářů.

Stručně řečeno, autor by měl uvést který hypervisor nebo virtuální systém.

Reference:

4
JackSparrow

Zajímavé a významné je, že soutěž o bezpečnost „Pwn2Own“ pro rok 2016 má jako jednu ze svých soutěží uniknout z virtuálního počítače VMWare Workstation. (Mezi další patří únikové karantény prohlížeče nebo převzetí fyzických strojů). To by mělo dát představu, že 1) je to alespoň věrohodné a 2) pokud je to snadné, máme způsob, jak to slyšet - stačí zkontrolovat výsledek :)

Obecněji by zabezpečení VM mohlo teoreticky uniknout mnoha způsoby. Například -

  • Příkazy a API hosta hostitele (např. Nástroje VMware)

  • Využitelné slabiny v samotném hostitelském operačním systému, které nejsou zmírněny spuštěním v procesu VM (pokud jsou některá volání hostujícího operačního systému chybně posouzena jako „bezpečná“ a rychlost předává hostující ovladač přímo hostitelskému operačnímu systému nebo ovladači zařízení, ale existuje exploit)

  • Chyby v ovladačích dodavatelů nebo v kódu dodavatele (například ovladač Host umožňuje přemostění sítě pro hostující OS; možná chyba v něm může umožnit volání nebo kód na hostitele na úrovni jádra).

  • Zranitelnosti vyplývající z jiného softwaru v hostiteli (příklad vynálezu - pokud místní antivirus zachytí veškerý síťový provoz z hostitele ke kontrole a návštěvnický provoz je skenován jako součást tohoto (na rozdíl od ignorování kvůli virtuálnímu NIC) , pak zranitelnost a/v motoru vůči škodlivě vytvořenému provozu nebo paketu by mohla být schopna umožnit úniku pocházejícímu z VM k hostiteli)

  • Špatná konfigurace uživatelem (hostitelské soubory mapovány nebo nedostatečně zabezpečeny/odděleny, aby je host mohl k nim získat)

Rozsah existuje a vzhledem k jeho převahě je jeho aktivně zkoumáno jeho zneužití. Pravidelně budou nalezeny zranitelnosti, pokud nebudou zneužity, a je třeba je opravit.

4
Stilez