Jak przenieść się do chmury – bezpieczeństwo środowiska wirtualnego

dodał 29 sierpnia 2018 o 07:22 w kategorii HowTo  z tagami:
Jak przenieść się do chmury – bezpieczeństwo środowiska wirtualnego

Przeniesienie się do chmury w wielu przypadkach oznacza wykorzystanie w znaczącym stopniu mechanizmów wirtualizacji. Warto znać ich charakterystykę oraz możliwe zagrożenia z nimi związane, by odpowiednio obronić swoje zasoby.

Koncepcja wirtualizacji miała swój początek w 1960 roku wraz z rozwojem IBM System/360 model 67. W ostatniej dekadzie stała się fundamentem w rozwoju usług chmurowych. Oprócz niewątpliwych korzyści generuje też ryzyka, jak każda technologia. W dzisiejszym artykule omówimy, jakie są zagrożenia i najlepsze praktyki w kontekście bezpieczeństwa środowiska wirtualnego w chmurze. Zaczniemy od zagrożeń – a na końcu znajdziecie przegląd technik zabezpieczeń.

Warto jednocześnie zauważyć, że dbanie o bezpieczeństwo środowisk wirtualizacyjnych często jest skomplikowanym zadaniem – mnogość technologii i stopień złożoności infrastruktury nie ułatwia aktualizacji oprogramowania i prawidłowej jego konfiguracji. Tym bardziej warto w tym zakresie zaufać doświadczonym dostawcom tego rodzaju rozwiązań, którzy potrafią sprostać temu zadaniu.

Cykl artykułów

Artykuł jest częścią zaplanowanego na cały rok cyklu artykułów oraz webinarów sponsorowanych przez firmę Aruba Cloud – dostawcę usług chmurowych z centrum przetwarzania w Polsce. Przed nami jeszcze pięć artykułów i kilka webinarów, a w poprzednich artykułach i webinarach poruszone zostały zagadnienia:

Koncepcje wirtualizacji

Na początek kilka definicji i pojęć w celu wyjaśnienia czasami subtelnych różnic pomiędzy koncepcjami wirtualizacji. Generalnym założeniem wirtualizacji jest umożliwienie różnym użytkownikom zarządzania i współdzielenia fizycznych zasobów sprzętowych poprzez zmultiplikowane środowiska, które są od siebie logicznie wyizolowane.

Źródło: Ibm.com

Hipernadzorca (hypervisor) – komponent, który pośredniczy w przekazywaniu żądań między maszynami wirtualnymi a sprzętem w celu uzyskania zasobów (np. moc obliczeniowa, pamięć, przestrzeń dyskowa, interfejsy sieciowe).

  • Hipernadzorca typu 1 (natywny, bare metal) – aplikacja uruchamiana bezpośrednio na poziomie sprzętu. Kontroluje i monitoruje uruchomione systemy operacyjne Gości działające na poziomie wyżej. Zazwyczaj jeden z systemów jest uprzywilejowany i służy jako domena zarządzająca pozostałymi systemami Guest. Sam monitor (VMM) działa w trybie Ring 0 (opis pierścieni poniżej),  podczas gdy systemy Guest działają w przestrzeni Ring 1,  a aplikacje standardowo w trybie Ring 3. Przykładami implementacji tego typu hypervizorów są: Oracle VM, Microsoft Hyper-V, VMWare ESXi, Xen.
  • Hipernadzorca typu 2 (hostowany) – hipernadzorca tego typu działa jako program uruchomiony na danym systemie operacyjnym gospodarza. W tym przypadku zwirtualizowane systemy działają dwa poziomy ponad sprzętem. Przykładami są VMware Workstation, VMware Server, Oracle VirtualBox.

VMM (virtual machine monitor, virtual machine manager) – pojęcie często używane zamiennie z hypervisorem. Jest to komponent hypervisora odpowiedzialny za tworzenie maszyn wirtualnych i wsparcie dzielenia zasobów pomiędzy nimi.

Maszyna wirtualna, gość (VM, guest machine) – instancja wirtualnego środowiska z systemem operacyjnym  i aplikacjami, wykorzystująca zasoby sprzętowe maszyny fizycznej (host machine) dostarczone za pośrednictwem VMM. Specjalnym rodzajem wirtualnej maszyny, w szczególności wykorzystywanym w chmurze, jest kontener, gdzie jądro systemu operacyjnego umożliwia tworzenie wielu oddzielonych od siebie instancji.

Gospodarz  (host machine, gospodarz) – maszyna fizyczna z systemem operacyjnym, która jest gospodarzem dla środowiska wirtualnego. Zarządza bezpośrednio fizycznymi zasobami sprzętowymi.

Serwer zarządzający (management server)platforma wirtualizacji złożona z zestawu komponentów, umożliwiająca m.in. bezpośrednie zarządzanie maszynami wirtualnymi, przydzielanie zasobów itd. Przykładem serwera zarządzającego jest VMware vSphere lub XEN XenCenter.

Konsola zarządzająca (management console) komponent umożliwiający dostęp do interfejsu zarządzającego do konfigurowania i zarządzania maszynami wirtualnymi.

Komponenty sieciowe – umożliwiają tworzenie wirtualnych sieci, w których wirtualne urządzenia (np. przełączniki, routery) są kontrolowane przez oprogramowanie, a protokoły sieciowe są symulowane jako fizyczne.

Wirtualny storage – komponenty umożliwiające zasymulowanie fizycznej przestrzeni składowania, która może być dostępna przez sieć lub bezpośrednie połączenie.

Źródło: Security aspects of virtualization, ENISA

Uprzywilejowane pierścienie (protection rings) – architektura x86 wspiera cztery poziomy uprzywilejowanych pierścieni. Pierścień 0 (Ring 0) jest najwyższym  poziomem uprzywilejowania i  umożliwia bezpośredni dostęp do sprzętu (kernel mode) . Ring 1 i 2 są praktycznie nieużywane (wsteczna kompatybilność, portowanie kodu). Ring 3 posiada najmniejsze uprawnienia dla aplikacji.

Używane technologie

Technologie wirtualizacji można podzielić na kilka zasadniczych rodzajów. Każdy rodzaj wirtualizacji prezentuje nieco odmienne podejście do tematu oraz są związane z nim różne rodzaje podatności.

a) Pełna wirtualizacja

Może być realizowana zarówno za pomocą hypervisora typu 1, jak i 2. W przypadku pełnej wirtualizacji emulowany jest cały wirtualny komputer oraz wszystkie urządzenia. VMM jest uruchamiany na poziomie Ring 0, a uruchamianie wszystkich instrukcji gościa odbywa się na poziomie wyższym. System operacyjny gościa jest odizolowany od sprzętu i nie ma „świadomości”, że uruchomiony jest w środowisku wirtualnym. Technologie pełnej wirtualizacji umożliwiają zasadniczo uruchomienie dowolnego systemu operacyjnego w maszynie wirtualnej i dostarczają największy poziom izolacji i bezpieczeństwa. Niestety konieczność emulacji każdego urządzenia znacznie obciąża procesor fizycznej maszyny. Przykładami rozwiązań są VirtualBox, Virtual PC, VMware,  Xen.

b) Parawirtualizacja

Parawirtualizacja wykorzystuje hypervisor typu 1, VMM działa bezpośrednio na sprzęcie. Jeden z wirtualizowanych systemów jest uprzywilejowany i pełni rolę zarządzającą. Podejście umożliwiające rozwiązanie problemu dostępu do określonych rejestrów procesora jednocześnie przez wiele systemów operacyjnych. Wywołania zwane hypercalls, które symulują wywołania systemowe, mogą być wykonywane przez zmodyfikowane systemy operacyjne gościa i odwoływać się do usług hypervisora. Tryb ten zapewnia dobrą wydajność wirtualnego środowiska, ponieważ usunięta została dodatkowa warstwa emulacji programowej. Rozwiązania: VirtualBox, Xen PV, KVM/QEMU, Parallels, Microsoft Hyper-V.

c) Wirtualizacja sprzętowa, pełna wirtualizacja ze wsparciem sprzętowym (HVM, hardware-assisted virtualization)

Jest to odmiana wirtualizacji pełnej, która korzysta ze sprzętowych rozszerzeń wirtualizacji architektury x86 – dla procesorów Intel (VT-x), dla procesorów AMD (AMD-V). Schemat wykorzystania pierścieni nieco się zmienia. Rozszerzenia sprzętowe dostarczają również dodatkowe tryby: root mode oraz non root mode. Każdy z tych trybów zawiera niezależne tryby Ring 0-3. Hypervisor typu 1 działa w trybie root mode, mając pełny dostęp do prawdziwego sprzętu, podczas gdy niezmodyfikowany guest działa w standardowych dla siebie trybach Ring 0-3 w trybie non root mode, a jego dostęp do sprzętu jest w pełni kontrolowany przez hypervisora. Obecnie większość dostępnych na rynku procesorów spełnia te wymagania. Przykłady rozwiązań: KVM/QEMU, Xen HVM, VMware ESXi, vSphere, MS Hyper-V.

d) Wirtualizacja na poziomie systemu operacyjnego (Operating System-Based Virtualization)

W tym rodzaju wirtualizacji mamy do czynienia z uruchamianiem tego samego (lub zbliżonego) systemu operacyjnego w tak zwanym kontenerze. Kontener izoluje określony kod, aplikację lub proces. Kontenery są uruchamiane na podbudowie systemu operacyjnego, więc nie wymagają uruchamiania systemu operacyjnego za każdym razem, gdy są tworzone lub uruchamiane. Kontener zawiera aplikacje, pliki użytkownika oraz dane środowiskowe. Każdy kontener jest budowany z obrazu, który przekazuje informacje, co dany kontener zawiera, jakie procesy są uruchamiane wraz z uruchomieniem kontenera, a także zawiera dane konfiguracyjne i środowiskowe. W tym podejściu, jeśli atakujący dokona wstrzyknięcia skryptu umożliwiającego przejęcie kontroli nad systemem operacyjnym gospodarza, przejmie kontrolę nad istniejącymi lub utworzonymi w przyszłości maszynami wirtualnymi. Przykładami tego rodzaju wirtualizacji są Docker, Virtuozzo, OpenVZ,, Solaris Containers.

e) Wirtualizacja na poziomie aplikacji (Application-based virtualization)

Zakłada emulację osobnych wirtualnych maszyn zawierających swój własny system operacyjny i powiązane aplikacje. Środowiska składają się z wielu komponentów, takich jak interpretery, kompilatory, weryfikator kodu bajtowego i bibliotek. Przykładami rozwiązań wspierających wirtualizację na poziomie aplikacyjnymi są Java VM, Microsoft.NET, Perl, Python, Ruby.

Źródło: Security aspects of virtualization, ENISA

Podatności

Do klasyfikacji i posługiwania się przykładami słabości związanych z poszczególnymi komponentami środowisk wirtualnych posłużę się bazą CWE (Common Weakness Enumeration) oraz  słownikiem CVE (Common Vulnerability Exposure).

Mapowanie pomiędzy słabościami wirtualizacji i CWE – Security aspects of virtualization, ENISA

Systemy operacyjne gości (Guest OS) i gospodarzy (Host OS)

Obie grupy systemów posiadają krytyczne podatności związane z modelem wirtualizacji opartym o system operacyjny oraz możliwością uzyskania dostępu na poziomie administratorskim. Dodatkowo można w nich znaleźć wiele podatności związanych  z lukami w aplikacjach.

Wykorzystanie słabości w systemach operacyjnych gości i gospodarzy stanowi punkt wyjścia dla wielu dalszych ataków wycelowanych w maszyny wirtualne (direct attack), hypervisora, zasoby sprzętowe czy architekturę gospodarza (side-channel attack), np. ostatnia luka wykryta w procesach intela. Poniżej kilka przykładów słabości systemów operacyjnych gości i gospodarzy oraz związanych z nimi konsekwencji.

Przykładami ataków wykorzystujących niewłaściwą konfigurację lub walidację wejść (improper input validation) są side channel attacks z jednej maszyny wirtualnej na drugą i eskalacja uprawnień w systemach operacyjnych gościa. Pierwszy może prowadzić do ujawnienia istniejącej aplikacji lub plików na innej maszynie wirtualnej. Ciekawy przykład ataku z zastosowaniem deduplikacji pamięci jest opisany w tym artykule.  Drugi wykorzystuje podatności (np. CVE-2015-6933) do podniesienia uprawnień na Guest OS.

Kolejnym przykładem jest atak za pośrednictwem luki w systemie operacyjnym Windows 10 umożliwiającej  uruchomienie aplikacji w celu ominięcia zabezpieczeń hypervisora Hyper-V (HVCI).

Kontenery

Kontenery różnią się w swym działaniu od systemów operacyjnych gościa oraz maszyn wirtualnych, ale posiadają wspólne słabości związane z kontrolą dostępu czy eskalacją uprawnień. W szczególności podatności mogą prowadzić do tzw. ucieczki z maszyny wirtualnej (VM Escape) i uzyskania dostępu do warstwy wyższej (hypervisor, OS host), ataków na aplikacje uruchomione na VM, atakach na całe kontenery czy architekturę gospodarza. W ostatnich latach pojawiło się kilkanaście podatności pozwalających na „wyskoczenie” z maszyny wirtualnej, takich jak np. Directory Traversal we współdzielonych katalogach Vmware czy możliwość zdalnego wykonania kodu w Hyper-V.  Najbardziej znanym i najlepiej opisanym przykładem był atak nazwany VENOM (Virtualized Environment Neglected Operations Manipulation) dotyczący środowisk zwirtualizowanych Xen, KVM i QEMU. Był on możliwy poprzez wykorzystanie błędu typu buffer overflow znajdujący się w wirtualnym kontrolerze dyskietek wykorzystywanym we wspomnianych wyżej platformach wirtualizacyjnych.

Kolejną grupa komponentów posiadającą wspólne podatności są hypervisory/VMM/Serwery i konsole zarządzające.  Z punktu widzenia bezpieczeństwa najlepiej by było, gdyby hypervisor był możliwie jak najprostszym systemem posiadającym podstawową funkcjonalność w celu zminimalizowania możliwości ataku. Jednakże jest to bardzo skomplikowany i rozbudowany system z wieloma podatnościami stanowiącymi łakomy kąsek dla atakujących, związanymi m.in. z izolacją maszyn wirtualnych, kanałami do komunikacji z VM, dodatkowymi API. Żeby móc je wyeksploatować do ataku często wykorzystywane są słabości innych komponentów, najczęściej na poziomie gościa i gospodarza. Są to zazwyczaj klasyczne luki w oprogramowaniu wywołań (hypercalls), metod uwierzytelniania czy autoryzacji. Aby wykorzystać niektóre podatności, musi wystąpić odpowiedni kontekst środowiskowy. Dla przykładu, jeśli fizyczne jednostki CPU są wysycone, pewne błędy w oprogramowaniu wywołań mogą być wykorzystane do przepełnienia bufora (np. luka w XEN związana ze słabością Numeric Errors).

Hypervisory posiadają też wiele podatności związanych z możliwością wstrzyknięcia, takich jak VMM oriented-injection, OS-command inection czy software library injection. Jedną z metod ataków jest tzw. hyperjacking polegający na instalacji oprogramowania udającego nadzorcę. System operacyjny jest nieświadomy kompromitacji na niższym poziomie, ponieważ fałszywy hypervisor działa w trybie stealth i tradycyjne zabezpieczenia nie wykrywają zagrożenia. Atakujący może umieścić podstawionego nadzorcę nad oryginalnym hypevisorem i w ten sposób przejąć nad nim kontrolę. Choć ataki tego typu zakończone powodzeniem nie zostały jeszcze odnotowane w realnym środowisku, aby się przed nimi uchronić, należy ograniczyć ruch do narzędzi zarządzania bezpieczeństwem w hypervisorze oraz zablokować dostęp z konta gościa.

Nadzorcy mają wiele funkcji ułatwiających zarządzanie i udostępnianie zasobów VM, takich jak migracja i klonowanie, powodujących wiele podatności związanych z prostym kopiowaniem i wklejaniem obrazów maszyn wirtualnych. Jednym z przykładów ataków wykorzystujących tego typu słabości jest Cloudburst VM Escape. Używa on luki w VMWare Workstation działającej w połączeniu z Cloudburst, oprogramowaniem IBM służącym dostawcom chmurowym do zarządzania usługami. Podatność umożliwia atakującemu uruchomienie kodu na wirtualnej maszynie, który powoduje, że system operacyjny gościa może oddziaływać bezpośrednio na nadzorcę i uzyskać dostęp do hosta i innych uruchomionych na nim VM-ów.

Hypervisory są narażone również na ataki na zwirtualizowane zasoby sprzętowe. Niektóre z nich wykorzystują rootkity ukryte w oprogramowaniu sprzętowym (firmware rootkits), które mogą tworzyć tylne drzwi (backdoors).

Sieci wirtualne (virtual networks) łączą maszyny wirtualne w podobny sposób jak fizyczne. Posiadają też podobne do nich podatności, jak zatrucie tablic ARP. Zarządzanie siecią jest emulowane poprzez oprogramowanie, więc posiada też luki typowe dla software’u oraz programowalnych sieci komputerowych (Software Defined Networks, SDN). Poniżej kilka przykładów podatności sieci wirtualnych.

Podatność CVE-2013-6398 związana z luką w wirtualnym ruterze Apache CloudStack umożliwiała ominięcie ograniczeń dla źródeł po jego restarcie.

Szereg krytycznych luk w Openswitch umożliwiających przepełnienie bufora

Wirtualna przestrzeń (virtual storage)

Problemy w architekturze wirtualnej przestrzeni mogą wynikać z łączenia technologii różnych dostawców np.  integracja IBM Tivoli Storage Manager for Virtual Environments z VMware vSphere GUI skutkowała pojawieniem się podatności:

  • Cross-site scripting (XSS) spowodowany niewłaściwą walidacją wejść. Podatność może być wykorzystana do wstrzyknięcia skryptu lub kodu HTML poprzez odpowiednio spreparowany URL i spowodować wykradzenie ciasteczek zawierających dane uwierzytelniające.
  • Luka umożliwiająca przywrócenie maszyn wirtualnych i w konsekwencji uzyskanie dostępu do danych wrażliwych

Podatności mogą również pojawiać się w wyniku niewłaściwego zarządzania danymi uwierzytelniającymi czy nieodpowiedniej kontroli dostępu. Przykładem jest luka w HP StoreOnce Virtual Storage Appliance umożliwiająca zdalny, nieautoryzowany dostęp do storage’u.

Jak się zabezpieczyć

Na koniec chciałbym przedstawić kilka rekomendowanych praktyk (ISACA, NIST, ISC², Cloud security Alliance) oraz narzędzi, które pomogą zwiększyć poziom bezpieczeństwa poszczególnych komponentów środowiska wirtualnego i tym samym usług chmurowych, z których korzystamy. Wybierając usługę, upewnijmy się, czy dostawca umożliwia korzystanie z nich bądź czy będziemy mogli samodzielnie je zastosować. Głównie dotyczą one usług IaaS w modelu chmury publicznej.  Szczegółowy sposób wdrożenia, niektórych z wymienionych poniżej praktyk oraz innych, które powinny być stosowane przez dostawcę (m.in. z zakresu bezpieczeństwa fizycznego, środowiskowe, GRC), została szczegółowo opisana w artykułach i webinarach poświęconych bezpieczeństwu chmury.

Komponent Słabość / Możliwy atak Praktyka
Guest/Host OS/kontenery
  • możliwość uzyskania nieautoryzowanego dostępu, eskalacja uprawnień
  • niewłaściwa izolacja pomiędzy VM, podsłuchiwanie ruchu, podszywanie się
  • wysycenie zasobów/DoS
  • nieautoryzowany dostęp do obrazów/ luki w obrazach
  • złośliwe oprogramowanie
  • uwierzytelnianie i kontrola dostępu, hardening
  • aktualizacje i patchowanie
  • segmentacja sieciowa, np. zastosowanie VLAN, firewalli
  • monitoring ruchu (IPS/IDS)
  • właściwa konfiguracja i ochrona przed DoS
  • zarządzanie cyklem życia obrazów, aktualizacja obrazów, szyfrowanie
  • 0programowanie antywirusowe, antyszpiegowskie, aktualizacja, hardening, świadomość użytkowników
Hypervisor/VMM
  • VM Escape
  • instalacja fałszywego guest OS
  • hyperjacking
  • aktualizacje i patchowanie
  • segmentacja sieci i konfiguracja interakcji pomiędzy VM, kontenerami, guest OS i host OS
  • wdrożenie mechanizmów kryptograficznych
  • hypersafe do kontroli integralności, hardening
  • ograniczenie dostępu administratorskiego do interfejsu zarządzającego
  • odłączenie niewykorzystywanego sprzętu
  • wyłączenie zbędnych usług takich jak clipboard- czy file-sharing between
  • monitorowanie bezpieczeństwa guest OS

Hypervisor typu 1 ze wsparciem sprzętowym:

  • zapewnia wyższy poziom bezpieczeństwa niż typu 2 poprzez wyeliminowanie dodatkowego wektora ataku w postaci host OS
  • zwiększa ochronę przed buffer overflow poprzez sprzętowe wsparcie zarządzania pamięcią
  • lepiej zabezpiecza przed VM escape (np. dzięki Direct Memory Access)
Sieci wirtualne podatności jak w fizycznych sieciach umożliwiających podsłuchiwanie, przejęcie czy uniemożliwienie transmisji
  • segmentacja i izolacja sieci
  • użycie mechanizmów kryptograficznych
  • kontrola dostępu
  • ochrona przed DDoS
  • wyłączenie zbędnych usług sieciowych
  • monitoring ruchu
Wirtualny storage
  • nieautoryzowany dostęp bądź modyfikacja danych
  • utrata danych
  • brak dostępu do danych
  • kontrola dostępu
  • mechanizmy zapewniające integralność danych (np. sumy kontrolne)
  • szyfrowanie danych
  • kopie zapasowe
  • redundancja
  • partycjonowanie
  • aktualizacja i patchowanie

Z pomocą powyższej tabelki możecie przepytać dostawcę swojej usługi chmurowej (lub kilku), by porównać, na ile profesjonalnie podchodzą do zapewnienia bezpieczeństwa infrastruktury.

Dla zachowania pełnej przejrzystości: za opublikowanie tego artykułu pobieramy wynagrodzenie.