18:59
17/1/2011

Czy jestem zwirtualizowany?

Natknąłem się niedawno na ciekawy skrypt, pozawalający sprawdzić, czy środowisko w którym go uruchamiamy jest “zwirtualizowane”. Skrypt sprawdza w tym celu kilka charakterystycznych ścieżek i logów oraz stara się precyzyjnie podać nazwę hypervisora.

imvirt

Skrypt po uruchomieniu wyświetla tylko jedną linię. W zrozumieniu wyników pomoże Wam ta tabelka:

Output Nazwa kontenera
HVM: <signature> Nieznany hypervisor
VirtualBox VirtualBox
Virtual Machine Microsoft Virtual PC/Virtual Server
VMware VMware Virtual Platform
VMware [Express | ESX/GSX Server |Workstation] VMware Virtual Platform
OpenVZ OpenVZ/Virtuosso
Physical Brak wirtualiazacji
QEMU QEMU/KVM (based)
UML User Mode Linux
Xen Xen hypervisor
Xen 3.x (PV|HVM) Xen hypervisor

Autorem skryptu jest Thomas Liske.
Źródła imvirt znajdziecie tutaj, a debianową paczkę tu.

P.S. Warto wspomnieć, że oprócz powyższego skryptu, podobne zadanie wykonują: virt-what autorstwa Richarda Jonesa z Red Hat oraz moduł perlowy autorstwa Dave’a O’Neilla.

Przeczytaj także:

17 komentarzy

Dodaj komentarz
  1. hmm.. a jakie jest zastosowanie praktyczne ;>?

  2. void -> Prosty przykład: piszemy OSa ;) i chcemy w zależności od tego czy nasz kernel uruchomiony jest na maszynie wirtualnej czy nie wypisywać dodatkowe informacje (debug). Ja korzystam w tym celu z BSWAP buga (opisany na blogu Gynvaela).

  3. Ja bym raczej podał przykład związany z bezpieczeństwem. Zakładając, że już zdobyliśmy root access na guest-host, to jeśli wiemy w jakim nasz kontener jest środowisku, możemy wykorzystać odpowiedni exploit, żeby przejąć kontrolę nad hypervisorem (a zdarzały się i takie eksploity na niektóre z metod wirtualizacji podanych powyżej).

  4. Dawno sie nie interesowałem honeypotami – ale czy przypadkiem nie używa się w pułapkach zwirtualizowanych systemów ? Wirus mógłby wykrywać, czy przypadkiem nie jest w pułapce i odpowiednio reagować.

  5. “pozawalający” – literówka.
    Ciekawe to trochę. ;d

  6. facter tez to umie.

  7. @gadulix
    Niektóre “wirusy” (a raczej malware) tak robią, co trochę irytuje przy ich analizie (szczególnie, że analizę powinno się robić w odizolowanym środowisku, którym zazwyczaj jest VMka).

    @NIXin
    Sądzę, że trafiłeś w sedno. Znajomi robili kiedyś research na ten temat i afair “załatwili” większość VMek które wtedy były na rynku (http://www.cr0.org/paper/jt-to-virtualisation_security.pdf).

    @Kuba
    Fajny pomysł – np. wykrywać BOCHS i korzystać z BGA do wyświetlania obrazu ;>

  8. To news? Myślałem, że to w tym środowisku chleb powszedni.
    Jakiś rok temu zostałem przyatakowany przez wirka umieszonego po lokalu i on już takie zabezpieczenia posiadał (w sensie nie dał się odpalać na virtualu w momencie próby rozbijania go na części pierwsze).
    Jeszcze wcześniej patche do prywatnych serwerów lineage’a miały takie zabezpieczenia aby nie dało się odpalać kilku procesów tej samej aplikacji na jednym komputerze (co oczywiście po czasie i tak się jakoś dało obejść).
    Aaaa, żeby nie było – wyżej przytoczone przykłady odnoszą się do środowiska M$

  9. @void: zastosowania rozciągają się nie tylko na zagadnienia związane z security. Pracuję dla bardzo dużego telekoma zajmując się tuningiem aplikacji javowych. Dla javy to b. ważne czy działa w środowisku zwirtualizowanym czy nie. Jak się weźmie pod uwagę fakt, że masz do czynienia z kilkuset środowiskami, tego typu narzędzia okazują się bezcenne.

  10. @void: w moim przypadku zastosowaniem praktycznym było sprawdzenie podczas pentestu, czy możliwa jest ucieczka z VM.

    Jak słusznie zauważył Stoper, sporo malwaru ma wbudowane podobne mechanizmy wykrywające wirtualizację i “wstrzymujące” w przypadku jej wykrycia “złe” funkcje — aby analiza była trudniejsza.

  11. @gynvael: a zerkałeś na kody? te metody to są dobre jak chcesz stestować “własną” VMkę własnym programem. in-the-wild to one średnio sensowne :)

  12. @G-Man
    (zakładam, że mówisz o imvirt)
    Hmmm, czemu?
    Z tego co widzę to jest to zbiór wcześniej znanych metod, tj cpuid, adresy GDT/LDT, niestandardowe urządzenia na PCI, etc. Brzmi jak aplikowalne in-the-wild. W najgorszym wypadku wymaga roota.

  13. Dokonac krotkiej analizy i opisania tych cech charakterystycznych to juz nie laska?

  14. @a: a spojrzeć w źródło skryptu to nie łaska?

  15. To teraz czekamy na pomysły jak ukryć przed programem, że jest uruchomiony w VM.

  16. Nie bawię się z malware’em, ale czy w niektórych przypadkach owe “wstrzymywanie” pod VMką (poza oczywistym utrudnianiem analizy) nie jest sporadycznie równoznaczne ze zmniejszeniem jego szkodliwości właśnie? Wówczas można się pokusić o rozważenie sytuacji odwrotnej, tj. ukrywania przed programem, że jest uruchomiony na maszynie fizycznej.

  17. Skrypt – skryptem, ale za identyfikowanie VM głównie odpowiadają strzępki programu napisanego w asm i C (C++)… Bo się zastanawiałem wcześniej po przeczytaniu nagłówka, czy to możliwe żeby skrypt w bash czy innym czymś mógł grzebać pod maską procesora? :) .

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: