Według CERT Polska między 9 a 10 kwietnia pobrania CPU-Z oraz HW-Monitor z cpuid.com trafiały do zasobów napastnika. Zmodyfikowane instalatory zawierały szkodliwy plik CRYPTBASE.dll, którego normalnie w tym oprogramowaniu nie było. W poniedziałek 13 kwietnia wniosek dla firmy brzmi: sprawdź historię pobrań i instalacji, zanim uznasz adres producenta za wystarczający dowód bezpieczeństwa.
Czy odpowiedź „pobraliśmy z cpuid.com” wystarczy, żeby zamknąć sprawdzenie służbowego urządzenia? Po ustaleniach opisanych przez CERT Polska trudno przyjąć takie kryterium. Komunikat z 10 kwietnia dotyczy sytuacji, w której droga do zmodyfikowanego oprogramowania prowadziła ze strony producenta. Nie trzeba dopisywać do tego obrazu pracownika łamiącego zakaz korzystania z przypadkowych stron. Sam opis przekierowań wystarcza, by zakwestionować kontrolę kończącą się na adresie rozpoczęcia pobierania. Dla CPU-Z oraz HW-Monitor proponujemy więc sprawdzić ciąg zdarzeń: skąd i kiedy pobrano plik, co zainstalowano oraz jakie ślady można jeszcze zweryfikować. To punkt wyjścia do ustalenia ekspozycji własnej organizacji, bez przesądzania wyniku tej kontroli.
Przekierowanie z cpuid.com zmieniło miejsce pobrania
Jak podaje CERT Polska w komunikacie z 10 kwietnia, żądania pobrania ze strony cpuid.com trafiały między 9 a 10 kwietnia do zasobów kontrolowanych przez napastnika. To tam znajdowało się zmodyfikowane oprogramowanie. Opisany mechanizm rozdziela zatem adres, któremu ufał pobierający, od miejsca dostarczenia pliku. Z tego wynika teza tej analizy: zaufany początek pobierania nie zastępuje sprawdzenia jego rezultatu.
Drugim konkretem jest CRYPTBASE.dll. Według CERT Polska szkodliwy plik znalazł się w zmodyfikowanych instalatorach, choć normalnie nie występował w tym oprogramowaniu. Zalecamy traktować tę informację jako punkt kontroli zawartości związanej z CPU-Z oraz HW-Monitor. Nie rozszerzajmy jej na ocenę każdego pliku o takiej nazwie znalezionego gdziekolwiek na urządzeniu.
Podane fakty nie wyjaśniają sposobu uzyskania kontroli nad przekierowaniami ani dalszego działania szkodliwego pliku. Do decyzji o rozpoczęciu przeglądu wystarcza jednak udokumentowane połączenie pobrania z cpuid.com i zmodyfikowanej zawartości.
Adres producenta powinien być początkiem weryfikacji pobrania, a nie jej wynikiem.
Historia instalacji powinna uzupełniać spis narzędzi
Rozważmy hipotetyczną procedurę dopuszczającą instalację CPU-Z oraz HW-Monitor wyłącznie po pobraniu od producenta. Gdyby kontrola polegała tylko na potwierdzeniu wizyty na cpuid.com, opisane przekierowanie pozostałoby poza jej zakresem. Jest to test kompletności procedury, nie opis zachowania konkretnego administratora. Fakty przytoczone przez CERT Polska nie pozwalają przypisać nikomu naruszenia firmowych zasad.
Proponujemy zestawić spis urządzeń z tymi narzędziami z dostępną historią pobrań i instalacji. Przy każdej pozycji zapiszmy oddzielnie datę pobrania oraz datę instalacji, o ile da się je ustalić. Okres 9–10 kwietnia dotyczy przekierowań pobrań; nie przypisujmy go automatycznie wszystkim późniejszym czynnościom na urządzeniu. Jeśli znamy wyłącznie dzień instalacji, pozostawmy datę pobrania jako nieustaloną.
W takim przeglądzie odpowiedź „mamy CPU-Z” powinna prowadzić do sprawdzenia konkretnego urządzenia i związanych z nim plików. Odpowiedź „nie wiemy, kiedy pobrano instalator” powinna trafić na listę brakujących ustaleń. Rekomendujemy zachować ten podział także w raporcie dla przełożonego: potwierdzone informacje, zakres wykonanej kontroli i pytania nadal otwarte.
Zarząd powinien przypisać odpowiedzialność za reakcję
Przegląd CPU-Z oraz HW-Monitor proponujemy oprzeć na trzech decyzjach: ustaleniu ekspozycji, zasadach izolacji podejrzanego urządzenia oraz weryfikacji śladów. Dla każdej z nich wskażmy osobę odpowiedzialną. Zlecenie „sprawdźcie temat” zastąpmy pytaniem o konkretne urządzenia, dostępne materiały i termin przekazania ustaleń.
Przed rozpoczęciem kontroli ustalmy też, kto może zdecydować o izolacji urządzenia powiązanego ze zmodyfikowanym instalatorem. Poprośmy tę osobę o opis wpływu takiej decyzji na pracę użytkownika. Z przytoczonych ustaleń nie wynikają straty ani koszty incydentu, więc nie ma podstaw do kwotowych porównań. Własną decyzję operacyjną oprzyjmy na ustaleniach dotyczących danego urządzenia i warunkach pracy organizacji.
Zalecamy osobno zatwierdzić sposób zachowania materiałów do analizy: historii pobrania, informacji o instalacji i podejrzanych plików. Przy CRYPTBASE.dll zapiszmy, gdzie go znaleziono i jaki ma związek z kontrolowanym oprogramowaniem. Wynik przeglądu powinien wskazywać podstawę każdej decyzji, także wtedy, gdy dostępne dane nie pozwalają jeszcze rozstrzygnąć, czy incydent objął urządzenie.
Brak ustalonej daty pobrania to zadanie do wyjaśnienia, a nie potwierdzenie bezpieczeństwa urządzenia.
Komunikat CERT Polska wyznacza zakres poniedziałkowego przeglądu
Dla polskiego odbiorcy punktem odniesienia pozostaje komunikat CERT Polska z 10 kwietnia. W przeglądzie rozpoczętym 13 kwietnia odnośmy ustalenia do wskazanego okresu 9–10 kwietnia. Poniedziałkowej daty kontroli nie mylmy z datą pobrania, które chcemy odtworzyć.
W wewnętrznej notatce przytoczmy oba ustalenia: przekierowania z cpuid.com oraz obecność szkodliwego CRYPTBASE.dll w zmodyfikowanych instalatorach. Następnie oddzielmy je od wyników sprawdzenia własnych urządzeń. Sam komunikat nie rozstrzyga, które komputery w naszej organizacji miały kontakt z tymi plikami.
Opisane fakty nie dają również podstaw do oszacowania liczby poszkodowanych firm w Polsce ani skali ich strat. Proponujemy więc raportować zakres własnej kontroli, zamiast dopisywać lokalną skalę incydentu. Odpowiedź dla zarządu powinna wskazywać, co sprawdzono w związku z CPU-Z oraz HW-Monitor i czego nadal nie udało się ustalić.
Co z tym zrobić w poniedziałek
Każde z poniższych działań ogranicz do 30 minut; zapisz rezultat oraz pozostałe braki, bez deklarowania zakończenia całego przeglądu.
- Rozpocznij ustalanie ekspozycji. Przejrzyj dostępny spis oprogramowania pod kątem CPU-Z oraz HW-Monitor. Wypisz znalezione urządzenia i dostępne daty pobrania oraz instalacji. Zaznacz pobrania z 9–10 kwietnia i pozycje bez ustalonej daty; zapisz również zakres sprawdzonego spisu.
- Ustal tryb izolacji. Z osobą odpowiedzialną za reakcję na incydenty zapisz, kto podejmie decyzję o izolacji urządzenia powiązanego ze zmodyfikowanym instalatorem i kto ją wykona. Ustal sposób przekazania takiego ustalenia oraz poinformowania użytkownika o decyzji.
- Zleć weryfikację śladów. Wskaż administratorowi jedno urządzenie z listy do sprawdzenia. Zakres zadania obejmuje historię pobrania, instalację oraz pliki związane z CPU-Z lub HW-Monitor, przede wszystkim CRYPTBASE.dll. Ustal zachowanie materiałów i termin przekazania wyniku.
Przy CPU-Z oraz HW-Monitor uzasadnienie zaufania do pliku powinno sięgać dalej niż nazwa strony producenta. Wymagajmy wyniku kontroli konkretnego urządzenia, z podanym zakresem i granicami ustaleń. Odpowiedź „pobrano z cpuid.com” pozostawmy jako informację o początku tej drogi.
Źródła
Redakcja cyberinsight.pl.