Tysiące osób hostuje dzisiaj swoje maszyny wirtualne w zewnętrznych serwerowniach, wyposażając je w Full Disk Encryption i licząc na to, iż będą one odporne na zakusy operatorów jak i służb. W szczególności wtedy, gdy mowa o tzw. ukrytych usługach w sieci Tor. Czy ich biznesy są przez cały czas bezpieczne?
W 2014 niejaki Tamas Kristof Lengyel rozpoczął pracę nad projektem DRAKVUF – początkowo miał to być po prostu eksperyment do jego pracy doktorskiej, stopniowo rozwinął się jednak do działającego i relatywnie prostego w użyciu narzędzia. Prawdziwym przełomem było jednak dołączenie do projektu Michała Leszczyńskiego (a zaraz potem kilku innych osób) z CERT Polska, który w marcu-kwietniu 2020 stworzył podprojekt DRAKVUF Sandbox, automatyzujący pracę z DRAKVUF. Zaś we wrześniu 2020 całość została poszerzona o eksperymentalną obsługę makr Microsoft Office.
Czym adekwatnie jest DRAKVUF?
Jest to system do analizy zachowania maszyn wirtualnych pod kątem wykrywania niepożądanych aktywności (np. wirusów). Analizy nie wymagającej instalacji na maszynie wirtualnej żadnego dodatkowego oprogramowania.
A więc np. dostawca usług VPS jest w stanie analizować zachowanie maszyn wirtualnych swoich Klientów bez ich wiedzy i zgody – np. deanonimizując ukryte usługi w sieci Tor, czy narażając swojego Klienta na inne przykre konsekwencje.
Ograniczenia projektu DRAKVUF
Procesor
DRAKVUF używa sprzętowych rozszerzeń wirtualizacyjnych (VT-x i EPT), wbudowanych w procesory Intela (w prawie wszystkie modele z serii Core i Xeon pochodzące z 2008 lub późniejszych lat). Potrafi także (w nieco ograniczonym zakresie) działać na 64-bitowych procesorach ARM.
DRAKVUF nie jest w stanie działać na procesorach:
- AMD – choćby na modelach z rozszerzeniami SVM
- 32-bitowych ARM
- modelach Intela bez obsługi VT-x i EPT (np. Intel Atom, Celeron, Pentium)
System operacyjny gościa
Na chwilę obecną oficjalnie wspierane są Windows 7 i nowsze, oraz Linux od 2.6.x do aktualnego – zarówno wersje 32- jak i 64-bitowe, również dla platformy ARM. Nie są wspierane inne systemy, np. FreeBSD, OpenBSD itd. – jednakże biblioteka LibVMI, będąca jednym z istotnych komponentów DRAKVUF, zawiera już przynajmniej częściowe wsparcie dla FreeBSD.
W przypadku Windows powstał też cały szereg pluginów, analizujących pojedyncze aktywności i dekodujących z nich konkretne działania, np.:
- edycja kluczy rejestru Windows
- działania na plikach i katalogach
- działania na socketach i łączność sieciowa
- podział działań na konkretne procesy
- możliwość selektywnego zrzutu pamięci, np. konkretnych procesów
- możliwość uruchomienia z poziomu hosta dowolnego pliku wykonywalnego na gościu
Typ wirtualizacji
Wg zapewnień autorów, DRAKVUF działa najlepiej na platformie Xen. Natomiast biblioteka LibVMI, będąca jednym z istotnych komponentów DRAKVUF, zawiera także pełne wsparcie dla KVM oraz projektu Bareflank – istnieje więc ryzyko, iż DRAKVUF w niedalekiej przyszłości również zacznie w pełni wspierać te hiperwizory.
Co robić, jak żyć?
Jeśli posiadasz serwer wirtualny z danymi na tyle „gorącymi”, iż nie możesz pozwolić sobie na konsekwencje ich wycieku, jak najszybciej uciekaj z nim od dostawcy, który może potencjalnie stosować DRAKVUF do takiego, który nie jest w stanie tego robić.
Ale jak to sprawdzić?
Przede wszystkim sprawdź typ procesora i typ hiperwizora – w Linuksie możesz to zrobić, uruchamiając z konsoli następujące polecenia:
- cat /proc/cpuinfo
- grep -i xen /sys/class/dmi/id/*_vendor /sys/hypervisor/type 2>/dev/null
W przypadku niektórych hiperwizorów, model procesora może być ukryty, np. pod nazwą modelu „QEMU Virtual CPU” – to jednak oznacza platformę KVM, a więc inną niż Xen. jeżeli zobaczysz procesor Intela, a drugie z poleceń zwróci jakikolwiek wynik (czyli serwer działa pod kontrolą Xen), zacznij się przygotowywać do ucieczki.
Dokąd uciec?
Szukaj dowolnego dostawcy, działającego w dowolnym modelu rozliczeniowym, który spełnia kilka prostych warunków:
- nie wymaga instalowania po stronie serwera-gościa żadnych dodatków, ani choćby konfigurowania standardowych usług systemowych pod kątem współpracy z systemami dostawcy (a więc odpada np. Google Cloud)
- umożliwia upload pełnego, już zaszyfrowanego obrazu dysku w ramach setupu nowego serwera
- serwer działa na procesorze innym niż Intel lub 64-bitowy ARM – lub też na platformie innej niż Xen (bardzo dobrze, aby spełnione były jednocześnie oba wymogi)
- lub po prostu jest to serwer dedykowany, w którym płacisz za 100% fizycznych zasobów i nie ma miejsca na jakąkolwiek wirtualizację
Obserwuj ruchy wroga
Dobrym pomysłem jest też śledzenie rozwoju projektu DRAKVUF, aby zawczasu przygotować się na kolejne ruchy różnych wspierających go instytucji:
- Twitter: CERT Polska, Michał Leszczyński, Tamas Kristof Lengyel
- strona domowa projektu DRAKVUF
- oficjalne Wiki projektu (tu pojawiają się informacje, o których nie ma ani słowa na stronie domowej, np. o architekturze ARM)
Aktualizacja
Mamy odpowiedź Michała Leszczyńskiego:
„Myślę iż obawy przed wykorzystaniem DRAKVUFa przez operatorów hostingów w chmurze są mocno przesadzone. Spadek wydajności jest odczuwalny, toteż masowe wdrożenie czegoś takiego przez firmy hostingowe wiązałoby się ze znacznym wzrostem kosztów operacyjnych. Poza tym, to nie jest tak, iż to monitorowanie jest idealne, całkowicie niewidzialne i bez efektów ubocznych. Żaden provider nie zaryzykuje obniżenia stabilności. To po prostu nie jest narzędzie do inwigilacji, tylko do monitorowania złośliwego oprogramowania.”
Wytłuszczony fragment jest już od nas. My też uważamy, iż raczej nie ma mowy o wdrażaniu tego rozwiązania w roli narzędzia do masowej inwigilacji prewencyjnej – natomiast jak najbardziej jest możliwe jego dyskretne wdrożenie przeciwko konkretnym klientom.
