Google i Microsoft usunęły ModHeader, popularne rozszerzenie przeglądarki do edycji nagłówków HTTP, po tym jak badacze znaleźli ukryty system zbierania historii przeglądania w oficjalnej wersji ze sklepu.
Rozszerzenie miało około 1,6 mln instalacji w Chrome i Edge. Z badania wynika, że mechanizm zbierający znajdował się w autentycznym, podpisanym rozszerzeniu, a nie w podrobionej kopii.
Najważniejszy szczegół jest taki, że mechanizm zbierający wydaje się być uśpiony. Pusta wewnętrzna lista dozwolonych (allow-list) utrzymywała go w stanie wyłączonym, a badacze nie znaleźli dowodów, że faktycznie zbierał lub przesyłał domeny odwiedzanych stron.
Mimo to sama konstrukcja budzi poważne obawy.
Kompletny potok zbierania danych był już obecny na komputerach użytkowników. Rutynowa aktualizacja mogła go aktywować bez żądania nowych uprawnień i bez żadnej dodatkowej czynności ze strony użytkownika.
Czym jest ModHeader
ModHeader to rozszerzenie przeglądarki przeznaczone dla programistów, testerów i specjalistów ds. bezpieczeństwa.
Jego podstawowe zastosowanie jest legalne: pozwala modyfikować nagłówki żądań i odpowiedzi HTTP. Może to być przydatne przy debugowaniu API, testowaniu przepływów uwierzytelniania, zmianie wartości user-agent, pracy z CORS lub symulowaniu różnych warunków przeglądarki.
Z uwagi na tę funkcjonalność rozszerzenia do edycji nagłówków często wymagają szerokiego dostępu.
Właśnie dlatego zaufanie ma tu takie znaczenie.
Gdy narzędzie, które może obserwować lub modyfikować ruch przeglądarki, zawiera ukrytą logikę zbierania danych, ryzyko jest znacznie większe niż w przypadku prostego rozszerzenia wizualnego lub motywu.
Co znaleźli badacze
Analizę przeprowadziła firma Stripe OLT, brytyjska firma z branży bezpieczeństwa.
Badacze przeanalizowali oficjalną wersję z Chrome Web Store i potwierdzili, że podejrzany kod został uwzględniony w autentycznym pakiecie rozszerzenia. Ma to znaczenie, ponieważ wyklucza prosty scenariusz fałszywego rozszerzenia.
Dotknięta wersja dla Chrome miała podobno około 900 000 użytkowników, a zewnętrzne serwisy śledzące szacują, że w Edge było około 700 000 dodatkowych użytkowników.
Microsoft usunął ofertę w Edge 3 lipca, a Google usunął ofertę w Chrome 10 lipca.
Wersją wskazaną w raporcie była ModHeader 7.0.18, o identyfikatorze rozszerzenia:
idgpnmonknjnojddfkpgkljpfnnfcklj
Ukryty potok zbierania danych
ModHeader nadal wykonywał reklamowaną funkcję edycji nagłówków.
Jednak ten sam zminifikowany kod działający w tle zawierał także drugi system.
Przy pierwszym uruchomieniu rozszerzenie mogło zbudować odcisk palca urządzenia i wczytać zaszyty na stałe klucz szyfrowania. Gdy użytkownik przeglądał strony, mechanizm zbierający był zaprojektowany tak, aby pobierać domenę z każdej odwiedzanej strony, szyfrować ją i zapisywać lokalnie.
Lokalny magazyn mógł przechowywać do 1000 różnych domen.
Zaplanowany proces był następnie zaprojektowany tak, aby łączyć zaszyfrowaną listę domen z odciskiem palca urządzenia i raz dziennie wysyłać je na adres:
api.stanfordstudies[.]com
Po przesłaniu lokalna kopia była usuwana.
Czas wysyłania był też przesunięty dla każdej instalacji z osobna, co oznacza, że w razie aktywacji systemu przeglądarki nie nawiązywałyby połączeń jednocześnie.
Taka konstrukcja wygląda na celową i przemyślaną operacyjnie.
Dlaczego się nie aktywował
Mechanizm zbierający uruchamiał się tylko wtedy, gdy przeglądarka pasowała do wewnętrznej listy dozwolonych.
Lista ta była dostarczana pusta.
Z tego powodu sprawdzenie za każdym razem kończyło się niepowodzeniem, a potok zatrzymywał się, zanim zebrał domeny przeglądania.
Dlatego badacze nie znaleźli dowodu, że mechanizm zbierający historię przeglądania faktycznie wykradał dane.
Obawę budzi jednak to, że stan nieaktywności mógłby się szybko zmienić.
Wypełnienie listy dozwolonych byłoby niewielką aktualizacją. Niekoniecznie wymagałoby nowych uprawnień, a użytkownicy nie musieliby niczego klikać.
Kluczowe elementy były już na miejscu:
- zaszyty na stałe klucz szyfrowania
- adres URL punktu końcowego
- harmonogram
- logika tworzenia odcisków palca (fingerprintingu)
- lokalny magazyn zaszyfrowanych domen
- mechanizm wysyłania
To właśnie sprawia, że ta uśpiona ścieżka kodu budzi tak duży niepokój.
Nie wszystko było uśpione
Chociaż główny mechanizm zbierający domeny przeglądania był wyłączony, inna aktywność była już włączona.
Rozszerzenie podobno łączyło się z drugą domeną:
extensions-hub[.]com
Działo się tak przy instalacji, aktualizacji i odinstalowaniu, a wysyłane były takie informacje jak produkt, wersja i przeglądarka.
Badacze stwierdzili również, że skrypt uruchamiany na każdej stronie zapisywał już w lokalnym magazynie rzeczywiste metadane żądań w postaci zwykłego tekstu.
Zatem choć najbardziej wrażliwy potok wysyłania domen przeglądania wydaje się pozostawać nieaktywny, rozszerzenie nie było całkowicie ciche.
Dlaczego zautomatyzowane skanery to przeoczyły
Jedną z największych lekcji z tego przypadku jest to, że automatyczne kontrole rozszerzeń można oszukać już na etapie projektu.
Niektóre zautomatyzowane narzędzia podobno oceniały ModHeader jako rozszerzenie niskiego ryzyka, z wynikami sięgającymi nawet 95 na 100 punktów.
Nie jest to zaskakujące, jeśli przyjrzeć się sposobowi, w jaki system został zbudowany.
Kod został zminifikowany wewnątrz legalnego rozszerzenia. Ścieżka wysyłania była bramkowana, więc testy w piaskownicy niekoniecznie wykryłyby wychodzącą eksfiltrację. Zebrane dane były zaszyfrowane, więc skanery statyczne widziałyby szyfrogram, a nie oczywistą historię przeglądania. Domeny nie miały jeszcze silnej złej reputacji. A rozszerzenie było podpisane i popularne, co często daje fałszywe poczucie zaufania.
Podpis sklepu dowodzi, że plik pochodzi z oficjalnego sklepu.
Nie dowodzi, że kod jest bezpieczny.
Podejrzana infrastruktura
Stripe OLT powiązała domeny z rzeczywistą, utrzymywaną infrastrukturą.
Domena stanfordstudies[.]com podobno nie miała żadnego związku ze Stanford i wyglądała na ponownie wykorzystaną starą domenę powiązaną z backendem OpenSearch.
Druga domena, extensions-hub[.]com, była powiązana z infrastrukturą reklamową.
W czasie analizy oba punkty końcowe API podobno wskazywały na ten sam serwer hostowany w Amazonie. Sugeruje to możliwego wspólnego operatora, choć nie dowodzi atrybucji.
Badacze zauważyli też słabe sygnały, które mogą wskazywać na operatora mówiącego po chińsku, w tym wskazówki dotyczące ustawień regionalnych i nazewnictwa, ale żadna konkretna grupa zagrożeń nie została wskazana.
Atrybucja pozostaje niepewna.
Sygnały ostrzegawcze przed usunięciem
Sytuacja z ModHeader nie pojawiła się całkowicie znikąd.
Rozszerzenie podobno wzbudzało skargi w 2023 roku z powodu wstrzykiwania reklam do wyników wyszukiwania i miało w tym okresie zacząć być finansowane z reklam.
Nie dowodzi to, kto odpowiadał za ukryty mechanizm zbierający.
Nie dowodzi też, czy zmienił się właściciel, ani czy zaangażowany był pierwotny deweloper.
Pasuje to jednak do szerszego wzorca obserwowanego w ekosystemie rozszerzeń przeglądarek: popularne narzędzia mogą być przejmowane, monetyzowane, modyfikowane lub stopniowo przekształcane w narzędzia do zbierania danych.
Rozszerzenia przeglądarek są atrakcyjne, ponieważ już znajdują się w codziennym przepływie pracy użytkownika i często mają szerokie uprawnienia.
Dlaczego to ma znaczenie
Ten przypadek dotyczy nie tylko ModHeader.
Dotyczy ryzyka związanego z zaufanymi rozszerzeniami, które zawierają uśpioną funkcjonalność, możliwą do aktywowania później.
Rozszerzenie przeglądarki może wyglądać legalnie, działać zgodnie z opisem, przechodzić automatyczne kontrole, zbierać dobre oceny i mimo to zawierać ukryty system, który włącza się dopiero w określonych warunkach.
To trudny problem dla obrońców.
Przeglądy bezpieczeństwa nie mogą ograniczać się do sprawdzania tego, co dzieje się podczas krótkiego uruchomienia testowego. Muszą też badać uśpione ścieżki kodu, podejrzane punkty końcowe, mechanizmy aktualizacji i ukrytą logikę, którą można włączyć później.
Następne rozszerzenie zbudowane w ten sposób może wyglądać równie czysto.
Co powinni zrobić użytkownicy
Każdy, kto ma zainstalowany ModHeader, powinien usunąć go z Chrome i Edge.
Przeglądarki mogły już automatycznie go wyłączyć, ale użytkownicy powinni mimo to sprawdzić to ręcznie.
Do ważnych kroków należą:
- usunięcie ModHeader z Chrome i Edge
- upewnienie się, że synchronizacja przeglądarki nie zainstaluje go ponownie
- sprawdzenie zasad zarządzanych rozszerzeń w środowiskach korporacyjnych
- zmiana wszelkich sekretów wklejanych do rozszerzenia
- zmiana kluczy API, tokenów typu bearer i plików cookie sesji, jeśli były obsługiwane przez ModHeader
- szerszy przegląd uprawnień rozszerzeń przeglądarki
Funkcja historii nagłówków jest szczególnie ważna, ponieważ badacze stwierdzili, że pełne nagłówki HTTP były przechowywane na dysku. Jeśli używano tam wrażliwych tokenów lub plików cookie, należy traktować je jako ujawnione.
Co powinni zrobić obrońcy
Zespoły bezpieczeństwa powinny traktować to jako zdarzenie w łańcuchu dostaw rozszerzeń przeglądarek.
Zalecane działania obejmują blokowanie i rejestrowanie:
stanfordstudies[.]comextensions-hub[.]com
Zespoły powinny również przeszukać logi punktów końcowych, serwerów proxy, DNS i narzędzi do zarządzania przeglądarkami pod kątem identyfikatora rozszerzenia ModHeader:
idgpnmonknjnojddfkpgkljpfnnfcklj
Przydatne obszary polowania na zagrożenia (threat hunting) to:
- żądania POST do
api.stanfordstudies[.]com - zdarzenia instalacji i aktualizacji rozszerzeń
- nieoczekiwane zachowanie synchronizacji rozszerzeń przeglądarki
- zapisana historia nagłówków HTTP
- używanie wrażliwych tokenów w rozszerzeniach przeglądarki
- zarządzane zasady, które mogą ponownie instalować rozszerzenie
Organizacje powinny też sprawdzić, czy narzędzia deweloperskie i rozszerzenia przeglądarek są zatwierdzane, monitorowane i okresowo oceniane na nowo.
Podsumowanie
Usunięcie ModHeader z Chrome i Edge pokazuje, jak kruche może być zaufanie do rozszerzeń przeglądarek.
Rozszerzenie było popularne, podpisane, funkcjonalne i szeroko instalowane. Mimo to badacze znaleźli w jego oficjalnej wersji kompletny potok zbierania historii przeglądania.
To, że główny mechanizm zbierający był uśpiony, jest istotne. Nie czyni to jednak tej konstrukcji nieszkodliwą.
System był już na miejscu, a zwykła aktualizacja mogła go aktywować przez zmianę listy dozwolonych.
Bezpieczeństwa rozszerzeń przeglądarek nie można opierać wyłącznie na reputacji, liczbie instalacji, podpisach sklepów ani zautomatyzowanym zachowaniu w piaskownicy. Uśpione ścieżki kodu, podejrzane punkty końcowe, ukryta telemetria i szerokie uprawnienia wymagają znacznie dokładniejszej kontroli, zwłaszcza w rozszerzeniach, które mogą widzieć lub modyfikować ruch przeglądarki.
