Środowiska maszyn wirtualnych doczekały się dedykowanych rootkitów. Na jednej szali mamy więc oszczędności i wygodę zarządzania, na drugiej zaś bezpieczeństwo informacji. Czy to się da pogodzić?

Wirtualizacja środowisk do przetwarzania danych stała się modna. W wielu firmach zagościła na dobre, ułatwiając życie administratorom, podwyższając niezawodność, ułatwiając podział współdzielonych zasobów i dając nieosiągalną inaczej elastyczność w zarządzaniu środowiskiem. Producenci komercyjnych rozwiązań wirtualizacyjnych, oprócz poprawy stabilności, elastyczności oraz wygody zarządzania zasobami, sygnalizują, że ich rozwiązania oferują także lepsze bezpieczeństwo systemu jako całości. Dowód w tej ostatniej kwestii może być jednak co najmniej karkołomny.

Przestrzenie i maszyny

Pierwszym rozwiązaniem wirtualizacyjnym była przestrzeń wirtualna. To rozwiązanie, stosowane od dawna powszechnie w systemach typu Unix (jail w systemach z rodziny BSD, chroot w systemie Linux, zones w systemie Solaris i nie tylko) zostało wymyślone dla podwyższenia bezpieczeństwa. Trzeba przyznać, że jest to na tyle skuteczna technika, że jako jedna z niewielu jest stosowana z powodzeniem do dziś.

Wiele dystrybucji systemów Unix/Linux posiada serwery usług domyślnie umieszczane wewnątrz zwirtualizowanych środowisk. Najczęstszym kandydatem do "uwięzienia" jest oczywiście serwer WWW, a także poczty elektronicznej lub ewentualnie serwer bazy danych (najczęściej MySQL). Umieszczenie serwera podejrzewanego o błędy (np. Apache albo Bind) wewnątrz poprawnie skonfigurowanej wirtualnej przestrzeni daje znaczącą poprawę bezpieczeństwa, bowiem przezwyciężenie zabezpieczeń jednej usługi wcale nie musi ułatwiać dostępu do całego środowiska.

W systemach operacyjnych o innej konstrukcji, przede wszystkim w systemach z rodziny Microsoft Windows, realizacja takich rozwiązań jest trudna. Brak przestrzeni wirtualnej dla dowolnej usługi, a zwłaszcza niedostateczna separacja przestrzeni użytkownika od przestrzeni systemowej to od lat wskazywane najpoważniejsze niedostatki systemów Microsoftu.

Współczesne realizacje przestrzeni wirtualnych dla systemów Unix/Linux są dość szczelne w tym sensie, że etap automatycznego przełamania zabezpieczeń mają już za sobą. Pełna wiara w ich niezłomność byłaby jednak przesadą, to w końcu jedynie środowiska programowe, które zawsze mogą zawierać błędy. Tym bardziej więc należy być ostrożnym, gdy mamy do czynienia z podejściem reprezentowanym przez nową falę rozwiązań wirtualizacyjnych, w których nie część systemu, lecz cały system działa w przestrzeni wirtualnej.

Różnica między tymi podejściami jest w praktyce zasadnicza. Wirtualizacja systemowa daje możliwość uruchomienia na jednym serwerze fizycznym systemu o zupełnie innej konstrukcji. Znane (i często wykorzystywane) są możliwości uruchomienia systemu Microsoft Windows wewnątrz maszyny wirtualnej pracującej w samodzielnym środowisku wirtualnym VMware ESX Server obok równolegle działającego systemu Linux. Istnieją też instalacje, w których maszyny wirtualne uruchomione w środowisku Linux są środowiskiem dla serwerów Windows.

Zalety takiego rozwiązania są rozliczne. Po pierwsze, system uruchomiony wewnątrz maszyny wirtualnej jest stabilniejszy z tej prostej przyczyny, że działa w środowisku emulującym dowolny sprzęt. Najczęściej są to starsze karty sieciowe, prostsze karty graficzne itd., nie ma więc ograniczeń związanych z niemożnością dobrania stabilnych sterowników i w konsekwencji konflikty sprzętowe praktycznie się nie zdarzają. Mając wiedzę na temat działania rozwiązań wirtualizacyjnych, o zwiększeniu bezpieczeństwa mówić jednak nie można.

Błędy - nic nowego

Wirtualizacja zasobów sprzętowych nie rozwiązuje w magiczny sposób problemu słabości zabezpieczeń. System słabo zabezpieczony jest równie niebezpieczny działając na sprzęcie fizycznym, jak i na sprzęcie wirtualnym. O tej prostej prawdzie nie można zapominać także dlatego, że zdobycie przez włamywacza władzy nad systemem działającym w jednej maszynie stwarza całkiem realne ryzyko uzyskania kontroli nad systemami działającymi w pozostałych maszynach wirtualnych.

Możliwe jest także przejęcie kontroli nad samym środowiskiem wirtualizacyjnym. Przyczyna jest prosta: błędy popełniane przez programistów tworzących środowiska wirtualne pozwalające z poziomu systemu-gościa sięgać do funkcji systemu-gospodarza. Błędy w oprogramowaniu - nic nowego pod słońcem, trudno oczekiwać, by dodatkowa warstwa oprogramowania była zdolna powstrzymać "młodych i zdolnych" przed zaspokojeniem ambicji.

Nie można także liczyć na to, że włamywacze "nie zauważą", że włamali się do systemu działającego wewnątrz maszyny wirtualnej. Sprawdzą to w pierwszej kolejności i, jeśli tylko upewnią się, że tak właśnie jest, sięgną po odpowiednie techniki i narzędzia. Istnieją już nawet gotowe podręczniki "wyzwalania się" z ograniczeń maszyn wirtualnych uruchamianych wewnątrz starszych wersji VMware. Pojawienie się gotowych zestawów narzędzi celujących w rozwiązania Microsoftu jest tylko kwestią czasu i znalezienia stosownego błędu polegającego np. na przepełnieniu bufora.

W każdym przypadku należy aktualizować nie tylko wszystkie systemy operacyjne, ale także łatać samo oprogramowanie wirtualizujące. Bez załatania wszystkich elementów środowiska cała operacja będzie nieskuteczna. W praktyce więc administrator ma więcej pracy i więcej spraw, o których musi pamiętać. Czy podwyższa to bezpieczeństwo? Pozostawiam to Państwa ocenie.

Przymiarki do uszczelniania

Aby włamać się na kilka kluczowych serwerów w sieci, należy przełamać ich zabezpieczenia - każdego z osobna. Wymaga to dużo więcej pracy i wyższego poziomu umiejętności niż w przypadku środowiska wirtualnego. Poza tym stałe "odpisywanie" logów za pomocą stosownych narzędzi do pracującego na innej maszynie dobrze skonfigurowanego centralnego rejestratora logów daje kilka chwil przewagi nad włamywaczami. Nawet jeśli włamywacz przezwycięży zabezpieczenia systemu operacyjnego, kasując od razu wpisy w logach zawartych w nim (gotowe narzędzia do tego celu dla większości systemów istnieją od dawna), to prawdopodobnie nie zdąży usunąć wpisów, nim te zostaną przesłane do centralnej bazy.

Wniosek nasuwa się sam. Wykorzystanie środowisk wirtualnych wymaga bezwzględnie centralnego gromadzenia logów na dobrze zabezpieczonym, oddzielnym serwerze fizycznym. To nie fanaberia, lecz absolutna konieczność. Bardzo dobrym wyborem w tym wypadku będzie serwer z odpowiednio skonfigurowanym systemem OpenBSD.

Kolejna sprawa to samo wykrywanie włamań. Jak to zrobić w sieci LAN, wiadomo od dawna, tymczasem środowiska wirtualizacyjne znacząco utrudniają to zadanie. Można monitorować ruch przechodzący przez interfejs sieciowy serwera-gospodarza, niemniej, jeśli nie przypisze się maszyn wirtualnych do konkretnych portów fizycznych na stałe (co może być wbrew założeniom odnośnie do działania aplikacji) nie do końca można być pewnym, z której konkretnie maszyny wirtualnej ruch wychodzi.

I znów, serwer z jednym systemem operacyjnym nie sprawia takich dylematów - po prostu wystarczy podłączyć całkowicie niewidoczny dlań sensor IDS, za pomocą takiego narzędzia jak tap (albo przesłać kopię wszystkich pakietów na port sensora za pomocą opcji duplikowania ruchu ustawionej na przełączniku sieciowym). Można zaryzykować tezę, że hybrydowy system detekcji intruzów przy wykorzystaniu maszyn wirtualnych jest koniecznością. Systemom wykrywania opartym wyłącznie na agentach monitorujących odwołania do funkcji systemowych (Host-based IDS) w przypadku środowisk wirtualnych raczej nie można ufać.

"Udany" eksperyment

Zapewnienie "szczelności" systemu maszyn wirtualnych to zupełnie inny problem. Producenci rozwiązań wirtualizacyjnych mieli już kilka wpadek związanych z przepełnieniem bufora (np. Secunia SA18162). Eksploity dla wykrytych luk pojawiały się bardzo szybko, co nie powinno pozostawiać wątpliwości jeśli chodzi o rzeczywiste zagrożenia. Wykrycie takiej luki w systemie-gospodarzu daje włamywaczowi możliwość uzyskania kontroli nad wszystkimi maszynami wirtualnymi działającymi w jego środowisku. Wiele serwerów fizycznych z własnymi systemami operacyjnymi nie oferuje możliwości takiego "hurtowego" włamania. Tym bardziej będzie to trudne, im bardziej systemy będą się różnić konfiguracjami.

Dziury w systemie wirtualizacji nie są jedynym zmartwieniem administratorów. Wystarczy pomyśleć, co by było, gdyby jakiś włamywacz postanowił zainstalować rootkita wewnątrz środowiska wirtualnego. W ten sposób możliwa jest całkowita kompromitacja wszystkich uruchomionych w środowisku wirtualnym systemów operacyjnych w sposób dla nich samych niewidoczny. Czego chcieć więcej?

Mając na względzie taki scenariusz, naukowcy z Uniwersytetu Stanowego Michigan wspólnie z inżynierami Microsoftu stworzyli testowego rootkita o nazwie SubVirt. Celem ćwiczenia było unaocznienie światu, że jest to możliwe, i pokazanie, jakie mogą być konsekwencje działania takiego oprogramowania. SubVirt eksploituje znane luki w zabezpieczeniach systemów, w których działają środowiska wirtualne i pozostawia w nich kod odpowiedzialny za uzyskanie nieautoryzowanego dostępu do maszyn wirtualnych.

Rezultaty badania są przejmujące. Systemy operacyjne uruchamiane wewnątrz maszyn wirtualnych nie podlegają żadnej widocznej zmianie. Ich stan można sprawdzać dowolnymi narzędziami, które zgodnie wykażą, że wszystko jest w porządku. Nieświadomi zagrożenia administratorzy przeważnie sprawdzą tylko stan systemów wewnątrz maszyn wirtualnych oraz systemu-gospodarza. Pomyślą, że skoro specjalistyczne sondy nic nie wykazują, to zagrożenie nie istnieje. Prawda będzie jednak inna.

Trzeba widzieć całość

Powstanie rootkita SubVirt udowadnia ważną tezę - aby móc pracować nad zapewnieniem bezpieczeństwa systemom, należy je traktować jako całość. Uszczelnianie systemów uruchamianych wewnątrz maszyn wirtualnych, a niezależnie od tego także systemu-gospodarza nie da pożądanych efektów. Kluczowy jest punkt styku między systemem-gospodarzem a maszynami wirtualnymi - tylko w tym miejscu można wychwycić cichą modyfikację. To jednak wymaga podejścia całościowego, angażującego znacznie więcej czasu i zasobów, niż w przypadku standardowych systemów niekorzystających z dobrodziejstw wirtualizacji.