W ostatnich latach bardzo popularne stały się rozmaite systemy wirtualizacji, do tego stopnia, że uruchamiania się nawet serwery produkcyjne właśnie w takich środowiskach. Równolegle, systemy wirtualizacji są wykorzystywane do analizy zagadnień związanych z bezpieczeństwem i ochroną informacji. W tym kontekście systemy te świetnie się nadają do przeprowadzania dynamicznej analizy działania złośliwego kodu. Wśród problemów z tym związanych wielokrotnie zwracano uwagę na fakt możliwości wykrycia przez złośliwe oprogramowanie środowiska wirtualnego, a co za tym idzie, nie wykonywania się na takich systemach w celu uniemożliwienia analizy działania.
Z naszych doświadczeń wynika, że zdecydowanie mniej uwagi poświecono stabilności tych rozwiązań. Na problem trafiliśmy w kontekście budowy wysokointeraktywnych klienckich honeypotów w ramach projektu HoneySpider Network. Wysokointeraktywne klienckie honeypoty to rozwiązania sterujące rzeczywistym systemem w celu wykrywania zmian w systemie przed i po uruchomieniu np. przeglądarki z danym URLem. Dzięki temu możliwe staję się wykrycie złośliwego URLa, znalezienie luki w przeglądarce, lub wręcz przechwycenie bota czy robaka. Do implementacji wysokointeraktywnych klienckich honeypotów wykorzystuje się najczęściej wirtualizację.
Struktura i zasada działania klienckiego honeypota jest zazwyczaj podobna. Istnieje pojedynczy serwer zarządzający, który zarządza włączaniem, wyłączaniem i odtwarzaniem do pierwotnego stanu jednego lub więcej honeypota, z którym komunikuje się przez sieć. W przypadku instalacji na jednej maszynie z użyciem wirtualizacji wykorzystywana jest sieć emulowana. W systemie honeypota pracuje program kliencki, który pobiera URLe do badania oraz monitoruje stan systemu, wykrywając infekcje, czyli zmiany nie zawarte na (wcześniej zdefiniowanych) listach zmian, jakie mogą zachodzić w normalnym, poprawnie działającym systemie, w którym jedyną pracującą aplikacją jest program kliencki. W przypadku wykrycia infekcji informacja przekazywana jest do serwera, który inicjuje przywracanie poprzedniego stanu (tzw. revert). Jeśli infekcji nie wykryto, klient otrzymuje kolejny URL.
Jednym z bardziej znanych rozwiązań wysokointeraktywnych jest Capture-HPC autorstwa Christiana Seiferta. Ogólne zasady działania jest taka jak powyżej, natomiast działanie klienta polega na modyfikacji wywołań systemowych i pozwala przechwytywać wszystkie zdarzenia w chwili ich wystąpienia. Rozwiązanie to stało się podstawą komponentu wysokointeraktywnego projektu HoneySpider Network.
Klasyczny Capture-HPC (obecnie w wersji 2.5.1) wykorzystuje VMware, w wersji VMware Server 1.0.x oraz 2.0. Serwer, do uruchamiania klienta korzysta z Vix API. W momencie wykrycia zmian – a więc teoretycznie po wykryciu złośliwego oprogramowania, po upływie stałego czasu, system wirtualny jest przywracany do wersji sprzed infekcji (następuje revert). Sam Capture-HPC zawiera wiele błędów w kodzie, które drastycznie wpływają na jego funkcjonalność (przepełnienia, słaby system logowania, gubione urle, bezpieczeństwo wątków … ). Okazuje się jednak, że kiedy wykorzystamy nawet już poprawionego Capture’a do przetworzenia dużych ilości URLi (np. rzędu kilku tysięcy), to instalacja VMware pod wpływem revertów (w szczególności jeśli revertowanych jest wiele maszyn), staje się niestabilna, do tego stopnia, że czasem konieczny jest reboot systemu hosta. Ponieważ wyniki wtedy zwracane stają się mało wiarygodne, rozwiązanie bazujące na VMware okazało się niewystarczające w kontekście projektu HoneySpider, które zakłada przetwarzanie dziesiątków tysięcy URLi dziennie i wysokiego poziomu niezawodności. Testy wykonywane były pod Linux Debian, w wersji Lenny, z jądrami 2.6.26 i wyżej.
Jak więc prezentują się alternatywne systemy wirtualizacji? Podobne testy przeprowadziliśmy dla VirtualBoxa (wersje 2.0.6 i 2.1.4), KVM/Qemu (wersje 84 i 72) oraz Xen (wersje 3.2.1 oraz 3.3). Okazało się, że każdy z tych systemów ma swoje poważne problemy. VirtualBox wykazał się średnim poziomem stabilności (procesy hosta – VBoxHeadless – padały po losowej ilości revertów z błędem naruszenia pamięci), który jednak udało się ‘obejść’ specyficznym revertem pilnującym, aby w jednym czasie był uruchomiony tylko jeden proces VBoxSVC sterujący obrazami wirtualnymi. Do ubijania już ‘zamykanych’ obrazów (np. po wykryciu stanu zainfekowania), konieczny okazał się sygnał SIGTERM, a nie standardowe narzędzie VirtualBoxa (VBoxManage), które okazało się zawodne. KVM/Qemu natomiast okazały się rozwiązaniami bardzo stabilnymi, jednakże … zwracane wyniki okazywały się mało wiarygodne, albowiem klient capture’a zwracał losowe wyniki (inny za każdym razem dla tego samego URLa). Podobny problem napotkaliśmy przy Xenie – co może nie dziwić, gdyż rozwiązanie również bazuje na Qemu (Xen w wersji 3.3 zawierał dodatkowe blędy w sterownikach, które w ogóle uniemożliwiały uruchomienie go w kontekście Capture’a).
Powyżej podsumowanie naszych doświadczeń i ocen dla systemów wirtualizacji w kontekście wykrywania złośliwych URL poprzez klienckie honeypoty. Wyniki okazały się sporym zaskoczeniem – systemy wirtualizacji okazały się być nie tak stabilne jak się spodziewano, w sytuacji wielu revertów, masowego otwierania złośliwych stron i wielu obrazów uruchamianych jednocześnie. Dodatkowym zaskoczeniem okazały się rozwiązania bazujące na Qemu – losowość zwracanych wyników. W tej sytuacji, najlepszym rozwiązaniem na dzień dzisiejszy okazał się VirtualBox, które po wprowadzeniu zabezpieczeń dla revert stał się podstawowym narzędziem systemu HoneySpider Network.
Conficker (znany także jako Downadup lub Kido), to najgłośniejszy medialnie i zarazem jeden z najgroźniejszych w ostatnim czasie robaków. Dla specjalistów zajmujących się bezpieczeństwem komputerowym jest ponadto bardzo interesujący ze względu na zastosowane przez jego twórców nieznane wcześniej rozwiązania. Na początku kwietnia informowaliśmy (zob. wiadomość Conficker – raport z pola walki), że monitorujemy ruch HTTP do pewnej liczby tzw. “polskich domen confickerowych”, z którymi miały się łączyć zarażone tym robakiem komputery. Nasze obserwacje kontynuowaliśmy przez miesiąc w ramach projektu nazwanego Confiture (skrót od Conficker capture). Realizowała go grupa specjalistów zwana NASK Conficker Working Group (w jej skład weszli specjaliści z trzech działów NASK: CERT Polska, Działu Domen, oraz Zespołu Integracji i Bezpieczeństwa). Wyniki obserwacji oraz płynące z nich wnioski umieściliśmy w raporcie, który można ściągnąć z naszej strony (plik PDF: Projekt Confiture). Poniżej przedstawiamy najistotniejsze fragmenty raportu.
W połowie stycznia 
