Monitoring wizualny strony WWW: jak SSIM pomaga wykrywać defacement

Strona internetowa może działać poprawnie z punktu widzenia monitoringu jej dostępności, a jednocześnie prezentować użytkownikom podmienioną i niechcianą treść.Analiza wizualna z wykorzystaniem SSIM pozwala wykrywać zmiany na stronie, gdy ich przyczyną nie jest bezpośrednia modyfikacja serwera www. To kluczowa różnica pomiędzy monitorowaniem skryptów a monitorowaniem rzeczywistej treści.

Defacement SSIM analizuje rzeczywisty, wyrenderowany wygląd strony internetowej i może wykryć anomalie w wyświetlanych treściach. Ich obecność może świadczyć o nieautoryzowanej modyfikacji kodu lub wykorzystaniu podatności elementów całej infrastruktury, odpowiedzialnych za dostarczenie tego co użytkownik widzi na stronie internetowej.

Podmiana treści na publicznie dostępnej stronie www może być jednym z pierwszych symptomów incydentu cyberbezpieczeństwa.
Źródeł takiego ataku może być wiele. Przejęcie systemu CMS, wykorzystanie podatności samej wtyczki, dostęp do konta administracyjnego, infrastruktury hostingowej, procesu CI/CD, DNS lub CDN. Należy pamiętać, że treści pochodzące z CMS-a strony internetowej to tylko jej fragment.

Treści, które dostarczamy dla użytkowników stanowią element integralności systemów, którymi zarządzamy. Wykrycie nieautoryzowanych zmian może, a nawet powinno być wykorzystane jako dodatkowe źródło sygnałów wspierających procesy CTI (Cyber Threat Intelligence).

Jak działa analiza wizualna strony?

W przeciwieństwie do prostego porównania wartości pojedynczych pikseli SSIM ocenia strukturalne podobieństwo obrazów. Pozwala dzięki temu określić skalę zmiany wizualnej pomiędzy kolejnymi obserwacjami strony.

Dla każdej monitorowanej podstrony wIDS cyklicznie:

1. uruchamia stronę w silniku Chromium (np. co 5 minut),
2. wykonuje kod JavaScript i oczekuje na wyrenderowanie wymaganych elementów,
3. przygotowuje stronę do wykonania powtarzalnego pomiaru,
4. wykonuje screenshot,
5. porównuje uzyskany obraz ze stanem referencyjnym,
6. oblicza poziom podobieństwa lub zmiany,
7. zestawia wynik ze skonfigurowanym progiem,
8. raportuje anomalię po przekroczeniu dopuszczalnego poziomu zmiany.

Takie działanie pozwala na wykrycie anomalii występujących na warstwie, gdzie prezentowana jest treść niezależnie od ich źródła. Dla mechanizmu detekcji nie ma znaczenia, jaki jest powód nieautoryzowanej zmiany. Analizie zostaje poddany końcowy rezultat, czyli to co faktycznie jest prezentowane użytkownikowi. Dlaczego analiza zmian jest bardziej skomplikowana niż mogłoby się wydawać, objaśnię w następnym akapicie.

Należy przy tym podkreślić, że SSIM nie identyfikuje samodzielnie przyczyn zmian. Zadaniem tego mechanizmu jest wykrycie i wskazanie zmiany podobieństwa obrazu względem stanu bazowego (do którego się odnosi). Połączenie tego wyniku z ustalonym poziomem dopuszczalnych zmian oraz innymi sygnałami bezpieczeństwa pozwala potraktować to jako potencjalną anomalię.

Dlaczego analiza wizualna jest kluczowym źródłem informacji ?

Współczesne serwisy internetowe są dynamiczne, ale ich zasadnicza struktura wizualna pozostaje stosunkowo stabilna. Sama treść na stronie nie jest dostarczana wyłącznie z poziomu CMS. To w dużej mierze tzw. third-party-apps, o których z resztą więcej napisałem tutaj. Zmieniają się treści, bannery, reklamy, produkty czy komunikaty, podczas gdy sam layout, branding, formularze oraz kluczowe elementy interfejsu tworzą charakterystyczny, względnie stabilny układ.

Właśnie to pozwala na wyznaczenie standardowego poziomu występujących zmian i łatwiejsze identyfikowanie odchyleń, które wykraczają poza jego typowe zachowanie.

Z perspektywy CTI szczególnie istotne są nagłe zmiany o nietypowym charakterze lub skali. Mogą one wtedy wskazać na potencjalny incydent i zainicjować dalszą analizę.

Kolejne artefakty analizy

Przykładowo, jednoczesne wystąpienie kilku obserwowanych czynników np.: znaczącej anomalii wizualnej, zmiany w DNS, pojawienia się nowych kodów, nowych domen zewnętrznych może wyzwalać natychmiastowy alert. Obserwacja i odnotowanie zmian tych parametrów osobno i bez wspólnego kontekstu może być bezskuteczna.

Defacement SSIM dostarcza zewnętrzne źródło sygnałów o nietypowych zmianach, które należy zidentyfikować i ocenić potencjalne zagrożenie.

Poniżej opisałem trzy przykłady zastosowania mechanizmu SSIM.

Use case 1 – przejęcie serwisu i klasyczny website defacement

Sytuacja

Strona instytucji publicznej jest monitorowana przez standardowy system dostępności. Serwer odpowiada prawidłowo, HTTPS działa, certyfikat jest ważny, a żądanie HTTP kończy się kodem 200 OK.

Z punktu widzenia prostego monitoringu dostępności usługa działa prawidłowo, i tak faktycznie jest.

Atakujący uzyskuje jednak dostęp do systemu CMS lub infrastruktury hostingowej i zastępuje stronę główną własną treścią. Użytkownicy zamiast właściwego serwisu zaczynają widzieć inne treści np. clickfix, przekierowanie do kasyna lub ostatecznie komunikat „Hacked by…”.

Detekcja przez wIDS

Podczas kolejnego pomiaru Defacement SSIM Chromium prawidłowo otwiera stronę. Serwer nadal zwraca kod HTTP 200, więc sama dostępność nie wskazuje problemu.

Wynik SSIM wskazuje na dużą zmianę względem stanu referencyjnego, a po przekroczeniu skonfigurowanego progu wIDS generuje alert dotyczący nieoczekiwanej zmiany wizualnej.

Zespół SOC nie otrzymuje alertu o niedostępności strony, ale o nieoczekiwanej zmianie jej rzeczywistego wyglądu i treści.

Znaczenie

Defacement wykonany na stronie www jest kluczowym sygnałem bezpieczeństwa. Jego przyczyny mogą leżeć w wielu obszarach od socjotechniki, poprzez malware i podatności komponentów.

Podmiana strony może być więc najbardziej oczywistym objawem ataku.

Przykład

W styczniu 2022 roku część ukraińskich organizacji rządowych padło ofiarą skoordynowanego ataku. Dokładnie 14 stycznia wiele ukraińskich serwisów rządowych zostało zmodyfikowanych bez autoryzacji. Pojawiał się na nich komunikat przygotowany przez atakujących w językach ukraińskim, rosyjskim i polskim.

W tym samym okresie doszło również do skoordynowanych podmian treści na ukraińskich stronach rządowych. Mandiant wskazywał na czasową zbieżność tych defacementów z destrukcyjną aktywnością wymierzoną w ukraińskie organizacje, nie należy jednak utożsamiać samego defacementu z działaniem WhisperGate.

WhisperGate został zaprojektowany jako malware o działaniu destrukcyjnym. Szyfruje dane, ale bez mechnizmu ich odszyfrowania.

Nieautoryzowana modyfikacja nie musi dotyczyć strony głównej.

Zmiana może zostać wprowadzona na jednej z setek lub tysięcy podstron serwisu np.: w zarchiwizowanej sekcji serwisu, podstronie konkretnej jednostki organizacyjnej, formularzu, starym landing page, lub w innych miejscach.

Atakujący może celowo unikać modyfikacji strony głównej. Ograniczenie zmian do mniej eksponowanych zasobów może zmniejszyć prawdopodobieństwo szybkiego zauważenia incydentu przez administratorów i użytkowników, a jednocześnie pozwolić wykorzystać zaufaną domenę i reputację zaatakowanej organizacji. W tym miejscu szczególnego znaczenia nabiera sposób działania wIDS.

Defacement SSIM może analizować zasoby pozyskane z całej sitemap serwisu, cyklicznie odwiedzając poszczególne podstrony, renderując je w Chromium i porównując ich aktualny wygląd ze stanem referencyjnym.

W praktyce oznacza to możliwość automatycznego poszukiwania anomalii wizualnych wszędzie, również głęboko w strukturze chronionego serwisu.

Od defacement detection do obserwacji powierzchni ataku

Jeśli spośród setek analizowanych adresów tylko pojedyncza podstrona nagle zaczyna prezentować zupełnie inną zawartość, pojawia się na niej komunikat atakującego albo jej dotychczasowy interfejs zostaje zastąpiony innym. Nawet gdy pozostała część serwisu funkcjonuje i wygląda całkowicie normalnie, jest to odnotowana anomalia.

wIDS nie odpowiada jedynie na pytanie: „Czy gdziekolwiek w obserwowanej stronie www danej organizacji pojawiła się nietypowa zmiana wizualna?”

W kontekście Cyber Threat Intelligence pojedyncza anomalia odnaleziona głęboko w strukturze serwisu może stanowić pierwszy zewnętrzny alert wskazujący na nieautoryzowany dostęp.

Jeżeli podobne anomalie pojawią się równocześnie na kilku podstronach albo zostaną skorelowane z innymi obserwowanymi przez wIDS elementami może powstać alert.

Przypadek ukraińskich serwisów rządowych dobrze pokazuje więc rolę, jaką może pełnić Defacement SSIM: automatycznego mechanizmu obserwacji zmian wizualnych działającego na szerokiej powierzchni publicznie dostępnych zasobów organizacji i dostarczającego CTI zewnętrznych sygnałów potencjalnej kompromitacji.

Use case 2 – Przykład infrastrukturalnej podmiany tego, co otrzymuje użytkownik

Sytuacja

Atakujący nie musi przejąć serwera www, aby zmienić treść prezentowaną użytkownikom. Jednym z możliwych scenariuszy jest wykorzystanie manipulacji routingiem BGP w celu przekierowania ruchu do infrastruktury kontrolowanej przez atakującego.

Przygotowana zostaje kopia strony logowania przypominająca oryginalny serwis. Strona działa prawidłowo, odpowiada kodem HTTP 200 OK i z perspektywy prostego monitoringu jest dostępna.

Celem może być przechwycenie danych uwierzytelniających użytkowników.

Detekcja przez wIDS

Fałszywa strona wyłudzająca dane może być bardzo podobna do tej którą naśladuje. Interfejs, który jest pod spodem już niekoniecznie. Mogą pojawić się różnice w położeniu elementów, czcionkach, formularzu logowania, grafikach, komunikatach albo innych fragmentach layoutu. Bardzo często strony wyłudzające dane mają nieaktywne linki, aby użytkownik z nich nie uciekł.

Defacement SSIM rejestruje finalny obraz prezentowany przez przeglądarkę i porównuje go ze stanem referencyjnym.

Jeżeli skala zmian przekracza poziom charakterystyczny dla normalnego funkcjonowania aplikacji, wIDS może wygenerować alert dotyczący anomalii wizualnej.

Co istotne, mechanizm zawsze analizuje efekt końcowy obserwowany z zewnątrz, a nie techniczną przyczynę jego powstania.

Znaczenie

Chroniony serwer może pozostawać nienaruszony, podczas gdy użytkownicy otrzymują treść pochodzącą z infrastruktury atakującego. Monitoring wykonywany wyłącznie na warstwie serwera nie zauważy takiego incydentu.

Przykład – MyEtherWallet i BGP hijacking

W kwietniu 2018 roku użytkownicy MyEtherWallet stali się celem ataku wykorzystującego BGP hijacking. Atakujący ogłosili fałszywe trasy do części prefiksów wykorzystywanych przez infrastrukturę Amazon.
W efekcie część ruchu DNS została przekierowana do infrastruktury kontrolowanej przez atakujących.

Pozwoliło im to serwować użytkownikom fałszywe odpowiedzi DNS dla domeny MyEtherWallet.com i kierować ich do podstawionej strony phishingowej, gdzie wyłudzano dane logowania.

Podmiana trwała około dwóch godzin. Według BleepingComputer skradziono 215 ETH, wówczas wycenianych na około 160 tys. dolarów.

Z perspektywy systemu wspierającego CTI jest to szczególnie interesujący przypadek. Kompromitacja nie wymagała modyfikacji oryginalnej aplikacji MyEtherWallet. Manipulacja nastąpiła w warstwie routingu i infrastruktury DNS, a jej końcowym rezultatem była zmiana treści prezentowanej użytkownikowi.

Zewnętrzna obserwacja i dostarczenie niezależnego wyniku, następnie korelowanie go z innymi anomaliami na warstwie DNS, zmianą adresacji IP/ASN pozwala na utworzenie alertu w systemie wIDS.

Co daje monitoring wizualny zespołowi SOC?

W rozbudowanych i dynamicznych serwisach prosta analiza wizualna, oparta tylko na sprawdzaniu HTML i CSS nie da sobie rady ponieważ występowanie zmian jest naturalnym elementem funkcjonowania aplikacji.

Monitoring wizualny nie mówi, dlaczego strona się zmieniła. Mówi, że z perspektywy użytkownika zmieniło się to, co zostało dostarczone. Dopiero korelacja z innymi sygnałami pozwala ocenić, czy jest to incydent bezpieczeństwa.

Źródła:

• https://www.microsoft.com/en-us/security/blog/2022/01/15/destructive-malware-targeting-ukrainian-organizations/
• https://www.cisa.gov/sites/default/files/publications/AA22-057A_Destructive_Malware_Targeting_Organizations_in_Ukraine.pdf
• https://cloud.google.com/blog/topics/threat-intelligence/information-operations-surrounding-ukraine
• https://medium.com/%40myetherwallet/a-message-to-our-community-a-response-to-the-dns-hack-of-april-24th-2018-26cfe491d31c
• https://www.bleepingcomputer.com/news/security/hacker-hijacks-dns-server-of-myetherwallet-to-steal-160-000/

Projekt „wIDS – Web-based Intrusion Detection System – system monitorujący występowanie anomalii serwisów i aplikacji webowych w zakresie detekcji incydentów cyberbezpieczeństwa”, jest współfinansowany przez Unię Europejską z programu Fundusze Europejskie dla Nowoczesnej Gospodarki.