CERT Polska poinformował 17 sierpnia o aktywnie wykorzystywanej podatności OS Command Injection w Zimbra. Według komunikatu luka dotyczy konfiguracji z powiadomieniami SNMP i usługą swatchdog, a usunięto ją w wersji 10.1.20. Przegląd firmowej poczty powinien objąć konfigurację usług pomocniczych, aktualizację oraz poszukiwanie śladów kompromitacji w logach i nowych plikach.

Czy odpowiedź „mamy Zimbra na liście systemów” wystarczy, żeby ocenić to ostrzeżenie? Po komunikacie CERT Polska zapytajmy również o powiadomienia SNMP i usługę swatchdog. Wyobraźmy sobie przegląd, podczas którego administrator przedstawia wykaz serwerów pocztowych, lecz nie ma w nim informacji o włączonych funkcjach pomocniczych. To hipotetyczny przykład do sprawdzenia własnej dokumentacji, bez przypisywania komukolwiek zaniedbania. We wtorek 18 sierpnia zacznijmy od zestawienia takiego wykazu ze stanem działającej usługi. Poprośmy o ustalenie konfiguracji i wersji, a obok zapiszmy osobne zadanie dotyczące śladów wykorzystania luki. W ten sposób pytanie o obecność produktu w organizacji zamieniamy w przegląd konkretnego wdrożenia.

SNMP i swatchdog wyznaczają zakres sprawdzenia

Jak podaje CERT Polska, opisywana podatność należy do klasy OS Command Injection, czyli wstrzykiwania poleceń systemowych. W ocenie własnej instalacji Zimbra uwzględnijmy łącznie powiadomienia SNMP oraz usługę swatchdog. Nie zastępujmy tego sprawdzenia samą nazwą oprogramowania wpisaną do rejestru zasobów.

Zalecany zapis inwentaryzacyjny powinien wskazywać, którego wdrożenia Zimbra dotyczą ustalenia, jakie funkcje są włączone i kto potwierdził ich stan. Przy SNMP oraz swatchdog umieśćmy wynik weryfikacji, zamiast pozostawiać administratorowi domyślne pole „bez uwag”. Jeśli konfiguracja pozostaje nieznana, nazwijmy ją nieustaloną i wskażmy osobę odpowiedzialną za uzupełnienie danych.

Wersję 10.1.20 potraktujmy jako punkt odniesienia podany przez CERT Polska dla usunięcia tej luki. Poprośmy administratora o zestawienie go z wersją działającej instalacji oraz o określenie potrzebnej aktualizacji. W protokole przeglądu zachowajmy podstawę tej oceny, żeby osoba odbierająca pracę mogła odtworzyć, jak zapadła decyzja.

Inwentaryzację Zimbra uznajmy za kompletną dopiero po opisaniu włączonych usług pomocniczych.

Aktualizację i sprawdzenie śladów rozliczajmy osobno

Komunikat CERT Polska mówi o aktywnym wykorzystaniu podatności. Dlatego w proponowanej procedurze obsługi ostrzeżenia obok aktualizacji Zimbra umieśćmy przegląd logów i nowych plików. Dla każdego z tych działań określmy oczekiwany wynik. Potwierdzenie wersji oprogramowania przypiszmy do zadania aktualizacyjnego, a ustalenia dotyczące możliwej kompromitacji do przeglądu śladów.

Wróćmy do hipotetycznego formularza inwentaryzacji. Jeśli zawiera tylko pole „Zimbra zaktualizowana”, dodajmy miejsce na zakres sprawdzonych logów i plików oraz rezultat ich przeglądu. Nie przedstawiajmy samego zaznaczenia aktualizacji jako ustalenia, że wcześniej nie doszło do wykorzystania podatności. W odbiorze prac wymagajmy odpowiedzi na oba pytania.

Przegląd logów Zimbra opiszmy tak, aby było wiadomo, jakie materiały administrator rzeczywiście sprawdził. Przy nowych plikach zapiszmy, które wymagają wyjaśnienia i komu przekazano dalsze ustalenia. Gdy materiałów brakuje, umieśćmy ten brak w wyniku kontroli. Sformułowanie „nie ustalono” powinno pozostać widoczne dla osoby podejmującej decyzję o zakończeniu prac.

Potwierdzenie aktualizacji Zimbra i wynik poszukiwania śladów kompromitacji powinny mieć osobne miejsce w raporcie.

Właściciel poczty powinien odebrać dowody wykonania prac

Dla osoby odpowiedzialnej za firmową pocztę proponowany zakres reakcji na ostrzeżenie CERT Polska obejmuje konfigurację, poprawkę i ślady wykorzystania. Przypiszmy odpowiedzialność za każde ustalenie, nawet jeśli wszystkie czynności wykona ten sam administrator. Przy odbiorze poprośmy o wynik odnoszący się do wskazanej instalacji Zimbra oraz o listę spraw wymagających dalszego wyjaśnienia.

W raporcie dla zarządu połączmy status wdrożenia Zimbra z podstawą jego nadania. Przy aktualizacji wskażmy potwierdzoną wersję; przy SNMP i swatchdog wynik sprawdzenia konfiguracji; przy śladach kompromitacji zakres przeglądu. Taki układ proponujemy jako kryterium odbioru pracy. Nie opisuje on procedur ani zachowania organizacji dotkniętych kampanią, których komunikat nie dokumentuje.

Koszt reakcji na lukę Zimbra pozostaje w materiale nieokreślony. Zamiast dopisywać kwotę, poprośmy administratora o oszacowanie prac we własnym środowisku i wskazanie zależności wymagających decyzji właściciela poczty. Termin zakończenia powiążmy z zakresem sprawdzenia. Jeżeli przegląd logów lub plików wymaga kontynuacji, pozostawmy go jako otwarte zadanie także po potwierdzeniu aktualizacji.

CERT Polska daje punkt odniesienia dla krajowych administratorów

Polskim punktem odniesienia jest komunikat CERT Polska z 17 sierpnia. Oprzyjmy na nim zlecenie przeglądu Zimbra i zachowajmy w nim wskazane warunki dotyczące powiadomień SNMP i swatchdog. Do informacji przekazanej osobie odpowiedzialnej za pocztę dołączmy źródło, aby mogła porównać zakres zamówionej pracy z ostrzeżeniem.

Komunikat nie określa liczby poszkodowanych organizacji w Polsce ani ich strat. W komunikacji wewnętrznej nie przypisujmy więc kampanii zasięgu, którego ten materiał nie potwierdza. Uzasadnieniem przeglądu Zimbra jest zgłoszone aktywne wykorzystanie podatności, a ocenę własnego wdrożenia oprzyjmy na zebranych danych. Krajowe pochodzenie ostrzeżenia nie zastępuje ustalenia konfiguracji konkretnej instalacji.

Co z tym zrobić w poniedziałek

Każdy punkt ogranicz do 30 minut wstępnej pracy nad jednym wdrożeniem Zimbra. Pełną aktualizację i dalsze badanie śladów zaplanuj zgodnie z ustalonym zakresem.

  1. Sprawdź konfigurację SNMP i swatchdog. Zbierz dostępne potwierdzenia stanu powiadomień i usługi. Zapisz wynik przy wybranej instalacji Zimbra, wraz z podstawą ustalenia. Jeśli danych brakuje, przypisz administratorowi ich uzupełnienie.
  2. Zweryfikuj status aktualizacji Zimbra. Odczytaj dostępne potwierdzenie wersji i porównaj je z informacją CERT Polska o usunięciu luki w 10.1.20. Zapisz potrzebny następny krok, wykonawcę i sposób potwierdzenia rezultatu zmiany.
  3. Rozpocznij przegląd śladów. Na podstawie komunikatu CERT Polska ustal dostępność logów Zimbra i informacji o nowych plikach. Wykonaj wstępny przegląd dostępnego materiału; zapisz jego zakres, wynik i pozycje wymagające dalszego sprawdzenia.

Po ostrzeżeniu CERT Polska wymagajmy inwentaryzacji poczty, która pozwala ocenić włączone usługi pomocnicze. Dla Zimbra przyjmijmy jako warunek odbioru prac potwierdzenie konfiguracji i aktualizacji oraz udokumentowany wynik poszukiwania śladów kompromitacji. O zakończeniu przeglądu decydujmy na podstawie tych ustaleń, a wszystkie niewyjaśnione sprawy zostawmy widoczne.

Źródła

Redakcja cyberinsight.pl.