Hipernadzorca, goście i sieć

Skoro hiperwizor został wywołany do tablicy, to zacznijmy od niego, jako najbardziej oczywistego newralgicznego punktu bezpieczeństwa w wirtualizacji. Od kilku lat mówi się o tzw. hyperjackingu, czyli atakach mających na celu przejęcie kontroli nad hiperwizorem. Standardowe mechanizmy ochronne gości byłyby tutaj bezradne - nie wiedziałyby o przełamaniu zabezpieczeń systemu bazowego. Do dzisiaj nie doszło jednak do spektakularnego ataku tego typu. Historycznie do dobrze nagłośnionych form ataków należą: rootkit BluePill, stworzony przez Joannę Rutkowską, oraz Vitriol, którego autorem jest Dino Dai Zovi. BluePill wywołał nagonkę na autorkę, gdyż postawiła ona śmiałą tezę o możliwości stworzenia rootkita niewykrywalnego, który wzorcowo podszywałby się pod hiperwizora. Ostatecznie, ani twierdzenia autorki, ani jej oponentów nie doczekały się jednoznacznego potwierdzenia.

Ale nie należy oglądać się wstecz. Niedawno ujawniono podatność w procesorach Intela, wynikającą ze sposobu implementacji instrukcji SYSRET. W rezultacie część platform wirtualnych podatna jest na atak VM Escape. Intel twierdzi, że nie jest to żaden błąd, a cecha wynikająca z realizacji udokumentowanych funkcjonalności. Według komunikatu US-CERT KB VU#649219: "Atakujący z poziomu ring3 (aplikacji) może tak spreparować ramkę stosu, by była wykonana na poziomie ring0 (jądra), po wyjątku #GP (General Protection Exception). Błąd zostanie obsłużony przed przeładowaniem stosu, co znaczy, że mechanizm obsługi wyjątku (exception handler) zostanie uruchomiony na poziomie ring0, z wybranym przez użytkownika wskaźnikiem stosu (RSP), powodującym podwyższenie uprawnień".

Na szczęście nie każda platforma wirtualizacji będzie podatna. Odporny okazał się VMware - jego hiperwizor zwyczajnie nie wykorzystuje instrukcji SYSRET. Jednak, żeby uniknąć zarzutu faworyzowania tego producenta, śmiało dorzucamy łyżkę dziegciu. Wystarczy szybki rzut oka na bazę Secunię i już widzimy, że w przeciągu ostatnich 6 miesięcy ESX cierpiał na kilkanaście podatności, z których część umożliwiała eskalację uprawnień.

Podobne bolączki trapiły pozostałych dostawców. Pomimo tego, że realne ataki na hiperwizora występują na razie tylko na papierze (przestępcy też liczą i jak dotąd ROI nie bardzo im wychodzi), to warto podjąć pewien wysiłek i ograniczyć wektory ataku. Możliwe jest wykorzystanie TPM (Trusted Platfrom Module) i powiązanie z nią hiperwizora. To zwielokrotni trudność przeprowadzenia skutecznego hyperjackingu. Dobrze też po instalacji platformy wirtualnej przeprowadzić rzetelny hardening. Można w tym celu wesprzeć się bardzo dobrymi materiałami udostępnianymi przez Center for Internet Security. W ramce przedstawiamy kilkanaście wybranych przykładów zaleceń dla hardeningu ESX 4. Z racji tego, że hiperwizor ma tutaj wiele wspólnego z Linuksem, część zaleceń jest dość uniwersalna.

Jak na razie hiperwizor nie ma dostępu do internetu, więc przynajmniej ten wektor ataku chwilowo odpada. Warto natomiast wprowadzić kontrolę dostępu do platformy wirtualnej, chociażby poprzez umieszczenie elementów zarządczych (np. vCenter) w dedykowanej podsieci administracyjnej. Dostęp powinny wspierać również mechanizmy silnego uwierzytelniania. Niektórzy stoją na stanowisku, że dostęp do sieci zarządczej farmy wirtualnej powinien być dodatkowo chroniony przez np. dedykowanego firewalla oraz wymuszać korzystanie z VPN.

Problemem związanym z hiperwizorem są technologie migracji zasobów wirtualnych z jednej platformy do drugiej (np. vMotion). Niestety, w trakcie przenoszenia maszyny można bez większych przeszkód podsłuchać ruch (otwarty tekst) i wyciągnąć informacje chronione znajdujące się akurat w danej chwili w pamięci RAM.