CERT Polska w komunikacie z 31 lipca opisuje podatności w ESXi, vCenter oraz powiązanych produktach VMware. Według zespołu luka w VMware Directory Service pozwala ominąć uwierzytelnianie, a inna luka vCenter może prowadzić do wykonania kodu. Dla zarządu to powód, by wskazać właściciela aktualizacji infrastruktury wirtualnej i ustalić termin weryfikacji dostępu do niej.

Czy odpowiedź „mamy plan awaryjny” wystarczy, gdy pytanie dotyczy stanu aktualizacji vCenter i ESXi? Proponujemy wykorzystać ostrzeżenie CERT Polska do rozmowy o tym, kto potrafi ten stan potwierdzić i na jakiej podstawie. W planie poszukajmy odpowiedzialności za warstwę zarządzania, a w dokumentacji technicznej dowodu wykonanych zmian oraz zakresu dozwolonego dostępu. Nie zakładajmy z góry, że ochrona działa, ani że ktoś coś zaniedbał, bo stan firmowej instalacji dopiero ustalimy. Na spotkanie z zarządem przygotujmy nazwisko właściciela zadania i termin sprawdzenia dostępu, a także listę pytań, na które zespół jeszcze nie odpowiedział. Tak proponujemy przełożyć ostrzeżenie o podatnościach na decyzje dotyczące własnej infrastruktury.

VMware Directory Service: uwierzytelnianie wymaga osobnej uwagi

Według CERT Polska podatność w VMware Directory Service umożliwia obejście uwierzytelniania. Osobno zespół opisuje lukę vCenter, której wykorzystanie może prowadzić do wykonania kodu. Zachowajmy to rozróżnienie w informacji dla kierownictwa: opis dotyczy różnych podatności, a nie udokumentowanego ciągu zdarzeń w zaatakowanej firmie. Komunikat nie potwierdza aktywnych ataków.

Z informacji o obejściu uwierzytelniania wyprowadzamy zalecenie, by w przeglądzie vCenter uwzględnić ograniczenia sieciowe. Poprośmy osobę odpowiedzialną za dostęp o wskazanie, skąd można łączyć się z instalacją oraz jakie potrzeby uzasadniają utrzymanie tych połączeń. Dla każdego dostępu bez rozpoznanego uzasadnienia zapiszmy zadanie weryfikacji i osobę, która rozstrzygnie jego dalszą potrzebę.

Przy luce pozwalającej ominąć uwierzytelnianie wymagajmy sprawdzenia, kto może dotrzeć do vCenter przez sieć.

Przegląd ograniczeń sieciowych prowadźmy obok kontroli aktualizacji VMware. Nie uznawajmy samego opisu zasad dostępu za dowód, że zespół zaktualizował konkretną instalację. Każda z tych kontroli powinna mieć własny wynik, powiązany z rozpatrywanym systemem.

Dla vCenter i ESXi poproś o dowód wykonanej aktualizacji

Ostrzeżenie CERT Polska obejmuje ESXi, vCenter i powiązane produkty VMware. Dlatego zakres odpowiedzi zespołu powinien wskazywać, które elementy własnej infrastruktury sprawdzono. Poprośmy o porównanie używanego oprogramowania z zakresem komunikatu oraz o zapis ustalonego stanu. Gdy zespół nie potrafi jeszcze go potwierdzić, oznaczmy pozycję jako wymagającą wyjaśnienia i przypiszmy termin odpowiedzi.

Jeżeli procedura przewiduje aktualizacje vCenter i ESXi, zestawmy jej zapis z potwierdzeniem wykonania pracy. Proponujemy, aby dowód wskazywał konkretną instalację, datę aktualizacji oraz potwierdzony po zmianie stan oprogramowania. Zapytajmy też, kto sprawdził ten zapis. To propozycja sposobu rozliczenia zadania; źródło nie opisuje procedur ani działań pracowników w żadnej konkretnej organizacji.

W ocenie postępu odróżnijmy zaplanowanie aktualizacji VMware od jej wykonania. Dla prac jeszcze niewykonanych zapiszmy wykonawcę i termin, a dla zakończonych dołączmy potwierdzenie. Jeżeli deklaracja wykonania nie ma jeszcze dokumentacji, poprośmy o jej uzupełnienie. Braku zapisu nie przedstawiajmy jako dowodu braku aktualizacji, lecz pozostawmy stan otwarty do wyjaśnienia. W ten sposób rozmowa o procedurze będzie prowadzić do sprawdzalnego ustalenia dotyczącego vCenter lub ESXi.

Zarząd powinien znać właściciela i termin sprawdzenia dostępu

Dla infrastruktury VMware proponujemy wskazać osobę odpowiedzialną za zebranie wyników aktualizacji i przeglądu dostępu. Wykonawcy poszczególnych prac mogą być różni; ustalmy jednak, kto przedstawi zarządowi całość ustaleń i nazwie pozostałe niewiadome. W informacji dla kierownictwa umieśćmy zakres sprawdzonych instalacji, dowody aktualizacji oraz termin zakończenia weryfikacji ograniczeń sieciowych.

Przy vCenter i ESXi rozdzielmy również odpowiedzialność za wykonanie zmiany od decyzji o pozostawieniu sprawy nierozstrzygniętej. Jeżeli aktualizacja albo ocena dostępu wymaga dalszych ustaleń, poprośmy właściciela o opis przeszkody i wskazanie kolejnego terminu. Nie wyznaczamy tu uniwersalnego czasu wdrożenia, bo zakres prac w konkretnej organizacji ustala jej zespół.

Plan awaryjny powinien wskazywać, kto potwierdzi stan vCenter i ESXi oraz kiedy zweryfikuje dostęp do tych systemów.

Podczas przeglądu planu awaryjnego postawmy pytanie warunkowe: które jego założenia trzeba sprawdzić, jeżeli stan aktualizacji albo dostępu do VMware pozostaje nieznany? Odpowiedź potraktujmy jako zadanie dla właściciela planu. Nie przypisujmy temu ostrzeżeniu określonego kosztu, długości przerwy czy skutków dla odtwarzania, których podane fakty nie pozwalają ustalić.

Ostrzeżenie CERT Polska wyznacza zakres pytań do własnego zespołu

Polskim punktem odniesienia jest komunikat CERT Polska z 31 lipca. Przekażmy go osobom odpowiedzialnym za vCenter, ESXi i dostęp sieciowy wraz z prośbą o odpowiedź dotyczącą ich zakresu pracy. Proponujemy zebrać ustalenia w jednym zapisie, aby zarząd mógł powiązać właściciela aktualizacji z osobą potwierdzającą zasady dostępu i terminem ich kontroli.

W informacji dla zarządu oznaczmy, co pochodzi z ostrzeżenia CERT Polska, a co ustalił własny zespół. Opis podatności nie jest wynikiem kontroli firmowej instalacji. Jeżeli sprawdzenie vCenter jeszcze trwa, podajmy zakres wykonanych czynności i brakującą odpowiedź zamiast ogólnej oceny bezpieczeństwa. Potwierdzenie dla ESXi również powinno odnosić się do sprawdzonego środowiska.

Komunikat CERT Polska nie daje podstaw do ogłaszania fali ataków na polskie firmy. W rozmowie o priorytetach pozostańmy przy opisanych podatnościach oraz ustaleniach dotyczących własnego dostępu i aktualizacji. Niepewność co do firmowej instalacji zapiszmy wprost, razem z odpowiedzialnością za jej wyjaśnienie.

Co z tym zrobić w poniedziałek

  1. Przypisz odpowiedzialność za vCenter i ESXi. W ciągu 30 minut przejrzyj dostępną listę opiekunów infrastruktury. Zapisz właściciela aktualizacji i termin zebrania wyników. Jeśli przypisania brakuje, skieruj do osoby uprawnionej zadanie jego ustalenia z terminem odpowiedzi.
  2. Zleć weryfikację dostępu sieciowego. Poświęć 30 minut na przejrzenie dostępnego opisu ograniczeń dla vCenter i ESXi. Wypisz brakujące uzasadnienia połączeń oraz wskaż osobę i termin sprawdzenia rzeczywistego dostępu. Pełną kontrolę konfiguracji zaplanuj jako dalszą pracę.
  3. Odszukaj dowód aktualizacji. Przez 30 minut sprawdź dostępne zapisy zmian dotyczących VMware. Zanotuj, których instalacji dotyczą i jaki stan potwierdzają. Brakujące potwierdzenia przypisz do wyjaśnienia; wdrożenie i sprawdzenie aktualizacji pozostaw jako osobne zadania techniczne.

W planie awaryjnym wymagajmy wskazania osoby, która odpowie za potwierdzenie stanu vCenter i ESXi. Zarząd powinien znać termin weryfikacji dostępu oraz otrzymać dowód wykonania aktualizacji. Dopóki tych ustaleń brakuje, zachowajmy pytania o warstwę zarządzania jako otwarte zadania z przypisaną odpowiedzialnością.

Źródła

Redakcja cyberinsight.pl.