Cisco Talos w analizie opublikowanej 20 sierpnia opisuje narzędzia UAT-10147 używane wobec serwerów IIS i Linux. Według badaczy SPECTRE łączy zdalne sterowanie, kradzież poświadczeń i omijanie narzędzi ochronnych. Dla firmy to powód, by przegląd zabezpieczeń objął również pytanie, czy wykrywanie zadziała, gdy napastnik zdobędzie wysokie uprawnienia.

Czy potrafisz wskazać, skąd zespół dowie się o działaniach na serwerze IIS, jeśli napastnik zdoła ominąć działającą tam ochronę? Odpowiedź „mamy zainstalowane narzędzie” pozostawia to pytanie otwarte. Poprośmy o pokazanie konkretnego źródła logów, sposobu sprawdzania jego działania i osoby odpowiedzialnej za reakcję. Publikacja o SPECTRE daje punkt wyjścia do takiej rozmowy. Proponowany przegląd przyjmuje trudny scenariusz: napastnik już zdobył dostęp i ma wysokie uprawnienia. Jego celem powinno być ustalenie, co firma nadal potrafi zobaczyć i na jakiej podstawie to ocenia. Taki zakres pozwala przejść od deklaracji o ochronie do pytań o to, co faktycznie sprawdzono.

SPECTRE łączy dostęp z omijaniem ochrony

W analizie Cisco Talos dla tego przeglądu liczy się zestawienie funkcji SPECTRE. Zdalne sterowanie, kradzież poświadczeń i omijanie ochrony uwzględnijmy łącznie przy ustalaniu zakresu weryfikacji. Nie ma tu podstaw, by dopisywać konkretny przebieg włamania do firmy czy przesądzać, które z jej zabezpieczeń napastnik pokona. Można natomiast postawić wymaganie: ocena ochrony serwera ma uwzględniać próbę ograniczenia widoczności obrońców.

Przełóżmy funkcje SPECTRE na pytania do zespołu. Jak sprawdzamy wykrywanie zdalnego sterowania? Jak weryfikujemy sygnały dotyczące kradzieży poświadczeń? Czym potwierdzamy, że narzędzie ochronne nadal dostarcza użytecznych informacji? Przy każdej odpowiedzi poprośmy o wskazanie dowodu lub zapisanie braku wiedzy. Sam opis możliwości implantu nie rozstrzyga, jak zachowa się konkretne środowisko IIS albo Linux. Właśnie tę lukę powinien wypełnić firmowy przegląd.

Przegląd ochrony IIS i Linux powinien sprawdzać także to, co zespół zobaczy, gdy napastnik zdobędzie wysokie uprawnienia.

Procedurę dla IIS i Linux trzeba powiązać z dowodem

Opis UAT-10147 nie daje podstaw do oceniania zachowania administratorów w konkretnej firmie. Zderzenie procedury z praktyką przeprowadźmy więc we własnym środowisku: wybierzmy serwer IIS lub Linux i porównajmy zapis o monitorowaniu z dowodem, że monitoring rzeczywiście obejmuje przyjęty scenariusz. Niech osoba odpowiedzialna za ochronę pokaże, co potwierdza działanie wykrywania oraz jakie ograniczenia pozostają niesprawdzone.

W tym ćwiczeniu oddzielmy potwierdzenie instalacji narzędzia od potwierdzenia jego odporności na omijanie. Dla wybranego serwera zapiszmy, jaki zakres obejmowała ostatnia weryfikacja i czy uwzględniała wysokie uprawnienia napastnika. Jeśli odpowiedzi brakuje, oznaczmy ten punkt jako niezweryfikowany. Nie zastępujmy wyniku testu założeniem wynikającym z samej obecności ochrony.

Osobno przejrzyjmy niezależne źródła logów dla IIS i Linux. Poprośmy o wskazanie miejsca ich odbioru, osób mających dostęp oraz sposobu sprawdzania, czy zapis nadal dociera. Oceńmy również, na czym polega deklarowana niezależność: co pozostanie dostępne do analizy w przyjętym scenariuszu przejęcia serwera? To pytania kontrolne wynikające z kąta przeglądu, a nie opis udokumentowanej konfiguracji którejś z ofiar.

Zarząd powinien dostać zakres niewiedzy i właściciela sprawdzenia

Przegląd inspirowany analizą SPECTRE powinien zakończyć się materiałem do decyzji. Dla IIS i Linux poprośmy o krótkie zestawienie: co zweryfikowano, czego nie sprawdzono, kto odpowiada za uzupełnienie braków i jaki dowód będzie oznaczał zakończenie zadania. Nie przypisujmy opisanej aktywności kwoty strat ani prawdopodobieństwa ataku na własną firmę. Fakty będące podstawą tej wiadomości nie pozwalają na takie wyliczenie.

Zamiast zaczynać rozmowę o SPECTRE od zakupu kolejnego narzędzia, ustalmy oczekiwany wynik weryfikacji obecnej ochrony. Może nim być potwierdzenie zakresu wykrywania albo wskazanie, co wymaga osobnego testu. Przy braku dowodów zarząd powinien otrzymać jasny zapis „nie sprawdzono”, wraz z właścicielem dalszego działania. Taki zapis pozwala zatwierdzić konkretną pracę i później ocenić jej wykonanie.

Dla serwera IIS lub Linux wymagajmy dowodu działania wykrywania w przyjętym scenariuszu, zamiast uznawać samą instalację ochrony za wynik przeglądu.

Polski kontekst wyznacza technologia, nie lista ofiar

Opis dotyczy technologii dostępnych także polskim firmom. Nie ma jednak potwierdzonych danych o polskich ofiarach tej aktywności. Z obecności IIS albo Linux w organizacji nie wyciągajmy wniosku, że UAT-10147 ją zaatakował. Wykorzystajmy zgodność technologii do wyznaczenia zakresu kontroli. Ocenę konkretnego incydentu zostawmy odrębnemu postępowaniu.

Analiza Cisco Talos z 20 sierpnia nie jest również podstawą do ogłoszenia wzrostu zagrożenia w ostatnich trzech miesiącach. Odbiorcy tej wiadomości bardziej przyda się sprawdzenie własnych założeń dotyczących wykrywania po włamaniu. Przy przeglądzie IIS i Linux zacznijmy od ekspozycji serwerów, odporności narzędzi ochronnych i niezależnych logów. Nie rozszerzajmy wniosków na wszystkie firmowe systemy bez osobnej weryfikacji. Jeśli zakres kontroli obejmie tylko wybrany serwer, zapiszmy to w wyniku, aby decyzja o dalszych pracach odnosiła się do faktycznie sprawdzonego fragmentu środowiska.

Co z tym zrobić w poniedziałek

  1. Przejrzyj ekspozycję IIS i Linux. W ciągu 30 minut sprawdź dostępny wykaz serwerów i wskaż te, których ekspozycja wymaga potwierdzenia. Przy każdym braku wpisz osobę odpowiedzialną za wyjaśnienie. Wynikiem ma być lista do weryfikacji, bez deklarowania pełnego audytu środowiska.
  2. Sprawdź dowód odporności ochrony. Poświęć 30 minut na przegląd dokumentacji ostatniej weryfikacji wybranego serwera IIS albo Linux. Ustal, czy obejmowała wysokie uprawnienia napastnika i omijanie narzędzi ochronnych. Zapisz potwierdzony zakres albo brak takiego sprawdzenia oraz właściciela dalszego zadania.
  3. Wskaż niezależny zapis zdarzeń. W 30 minut przejrzyj konfigurację logowania wybranego serwera IIS lub Linux. Zapisz źródło, miejsce odbioru i sposób potwierdzania dopływu logów. Jeśli nie potrafisz ustalić, co pozostanie widoczne po przejęciu serwera, oznacz to jako pytanie wymagające testu.

SPECTRE uzasadnia postawienie w przeglądzie trudniejszego warunku: wykrywanie trzeba oceniać również dla scenariusza, w którym napastnik zdobył wysokie uprawnienia. Dla IIS i Linux oczekujmy dowodów odnoszących się do tego warunku, z jasno opisanymi ograniczeniami. Brak takiego dowodu powinien prowadzić do przypisanego zadania weryfikacyjnego.

Źródła

Redakcja cyberinsight.pl.