18:59
17/1/2011

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.


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

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: