Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Rozszerzenia przeglądarkowe wyposażone w uprawnienia do modyfikowania ruchu HTTP należą do najbardziej uprzywilejowanych komponentów w środowisku użytkownika. Mogą ingerować w nagłówki żądań, obserwować metadane połączeń oraz uzyskiwać szeroki wgląd w aktywność realizowaną z poziomu przeglądarki. Właśnie dlatego każdy incydent dotyczący takiego dodatku należy traktować jak potencjalne zagrożenie dla prywatności, bezpieczeństwa operacyjnego i integralności sesji.
W centrum najnowszego przypadku znalazł się ModHeader, popularny dodatek dla Google Chrome i Microsoft Edge, szeroko wykorzystywany przez deweloperów, testerów i administratorów. Ujawniona analiza wykazała, że oficjalnie dystrybuowana wersja rozszerzenia zawierała ukryty mechanizm przygotowany do gromadzenia historii odwiedzanych domen oraz ich późniejszej transmisji do zewnętrznej infrastruktury.
W skrócie
- ModHeader był popularnym rozszerzeniem do edycji nagłówków HTTP, używanym na dużą skalę.
- W oficjalnej wersji wykryto dodatkowy kod odpowiedzialny za fingerprinting urządzenia, buforowanie odwiedzanych domen i przygotowanie ich do szyfrowanej wysyłki.
- Mechanizm pozostawał uśpiony dzięki pustej liście dopuszczeń, ale cała logika wykonawcza była już obecna w dodatku.
- Microsoft usunął rozszerzenie ze sklepu Edge 3 lipca 2026 roku, a Google wycofał je z Chrome Web Store 10 lipca 2026 roku.
- Incydent pokazuje, że obecność dodatku w oficjalnym sklepie i jego podpisanie nie są równoznaczne z bezpieczeństwem.
Kontekst / historia
Przez lata ModHeader funkcjonował jako rozpoznawalne narzędzie wspierające testy aplikacji webowych, analizę ruchu oraz manipulację nagłówkami HTTP. Tego typu rozszerzenia są szczególnie cenione w środowiskach deweloperskich i QA, ale jednocześnie wymagają bardzo szerokich uprawnień, co automatycznie podnosi poziom ryzyka. Użytkownik, instalując takie narzędzie, de facto przekazuje mu dostęp do wrażliwego kontekstu pracy w przeglądarce.
Nie był to pierwszy sygnał ostrzegawczy związany z ModHeader. Wcześniej pojawiały się doniesienia o zmianach modelu działania rozszerzenia i skargi dotyczące wstrzykiwania reklam. Najnowsze ustalenia są jednak poważniejsze, ponieważ nie dotyczą fałszywej kopii ani złośliwego klonu, lecz oficjalnej, podpisanej wersji dostępnej w legalnych kanałach dystrybucji. To istotny aspekt z punktu widzenia bezpieczeństwa łańcucha dostaw, ponieważ pokazuje, że reputacja produktu może maskować obecność ryzykownej logiki.
Analiza techniczna
Analiza wersji 7.0.18 wskazała, że rozszerzenie realizowało swoją deklarowaną funkcję, ale równolegle zawierało dodatkowy, zminifikowany komponent odpowiedzialny za ukryty przepływ danych. Podczas pierwszego uruchomienia mechanizm generował odcisk urządzenia i inicjalizował osadzony klucz szyfrujący. Następnie, w trakcie zwykłego przeglądania stron, pobierał domeny odwiedzanych witryn, szyfrował je i zapisywał lokalnie do osiągnięcia określonego limitu unikalnych wpisów.
Kolejnym elementem był zaplanowany harmonogram dobowy. Jego zadaniem miało być pakowanie zgromadzonych danych wraz z identyfikatorem środowiska oraz ich wysyłka do zdalnego API. Po zakończeniu transmisji dane lokalne miały być usuwane. Zastosowano również mechanizm rozłożenia komunikacji w czasie, co ograniczałoby ryzyko wykrycia masowego beaconingu przez systemy monitorujące ruch.
Najważniejszym szczegółem technicznym była wewnętrzna lista dopuszczeń, od której zależało uruchomienie kolektora. W badanym momencie lista pozostawała pusta, więc pełna ścieżka zbierania i przesyłania danych nie była aktywna. Nie oznacza to jednak, że zagrożenie było czysto teoretyczne. W praktyce cały mechanizm był już wdrożony po stronie użytkownika: endpoint komunikacyjny, logika buforowania, harmonogram, szyfrowanie i warunkowa aktywacja. Wystarczyłaby zwykła aktualizacja rozszerzenia, aby włączyć funkcję bez dodatkowej zgody użytkownika i bez żądania nowych uprawnień.
Badacze zwrócili również uwagę, że część funkcji nie była całkowicie uśpiona. Rozszerzenie miało wysyłać sygnały telemetryczne przy instalacji, aktualizacji i odinstalowaniu, przekazując informacje o wersji produktu i używanej przeglądarce. Dodatkowo skrypt wykonywany na każdej stronie zapisywał metadane żądań w local storage w postaci jawnego tekstu. Oznacza to, że elementy związane z obserwowaniem aktywności działały jeszcze przed potencjalną aktywacją pełnego kolektora.
Incydent jest również interesujący z perspektywy wykrywalności. Rozszerzenie korzystało z reputacji legalnego, popularnego produktu, a ukryta logika była osadzona w prawidłowo działającym kodzie. Brak aktywnej transmisji w środowisku testowym, użycie szyfrowania i warunkowe uruchamianie funkcji znacząco utrudniały automatyczną ocenę ryzyka. To przypomnienie, że podpis kryptograficzny potwierdza źródło pakietu, ale nie gwarantuje bezpieczeństwa jego zawartości.
Konsekwencje / ryzyko
Najpoważniejszym problemem w tej sprawie jest model uśpionego kolektora, czyli kompletnej funkcji szpiegującej, która nie działa od razu, ale może zostać uruchomiona później. Taki wzorzec jest wyjątkowo niebezpieczny, ponieważ pozwala ominąć część procedur kontrolnych i przez długi czas pozostawać poza zainteresowaniem użytkowników oraz zespołów bezpieczeństwa.
Dla użytkowników indywidualnych ryzyko obejmuje profilowanie aktywności sieciowej, ekspozycję historii odwiedzanych domen oraz możliwość ujawnienia prywatnych lub zawodowych wzorców zachowań. W środowiskach firmowych stawka jest wyższa, ponieważ rozszerzenia ingerujące w nagłówki i sesje często działają w pobliżu danych uwierzytelniających, tokenów API, ciasteczek sesyjnych i informacji wykorzystywanych podczas testów lub administracji systemami.
Jeżeli użytkownicy korzystali z rozszerzenia podczas pracy z sekretami, należy przyjąć ostrożnościowe założenie, że takie dane mogły zostać narażone. Nawet przy braku publicznie potwierdzonej, pełnej eksfiltracji historii domen samo lokalne zapisywanie nagłówków i metadanych stanowi poważne ryzyko operacyjne, prywatnościowe i zgodnościowe. Na poziomie całego ekosystemu jest to kolejny przykład zagrożeń wynikających z zaufania do dodatków przeglądarkowych dostępnych w oficjalnych sklepach.
Rekomendacje
Podstawowym działaniem powinno być natychmiastowe usunięcie ModHeader ze wszystkich przeglądarek, zarówno na stacjach prywatnych, jak i w środowiskach organizacyjnych. Warto dodatkowo sprawdzić, czy rozszerzenie nie zostało przywrócone automatycznie przez synchronizację konta, kopię profilu lub polityki zarządzania przeglądarkami.
Następnie należy przeprowadzić rotację wszystkich sekretów, które mogły być używane w kontekście rozszerzenia. Dotyczy to przede wszystkim:
- kluczy API,
- tokenów Bearer i sesyjnych,
- nagłówków autoryzacyjnych,
- poświadczeń tymczasowych,
- danych wykorzystywanych do testów integracyjnych i administracyjnych.
Zespoły SOC, administratorzy i analitycy bezpieczeństwa powinni ponadto:
- zweryfikować obecność rozszerzenia w środowisku na podstawie inwentaryzacji przeglądarek,
- przeszukać logi proxy, DNS, EDR i telemetrykę przeglądarek pod kątem artefaktów związanych z ModHeader,
- sprawdzić local storage oraz dane profilowe przeglądarek,
- monitorować lub blokować komunikację do powiązanych domen i endpointów,
- przeanalizować polityki dopuszczające instalację rozszerzeń o wysokich uprawnieniach.
W dłuższej perspektywie organizacje powinny wdrożyć bardziej restrykcyjny model zarządzania dodatkami przeglądarkowymi. Obejmuje to listy dozwolonych rozszerzeń, okresowe przeglądy ich uprawnień, ocenę zmian właścicielskich i biznesowych oraz kontrolę aktualizacji pod kątem nowych ścieżek kodu, mechanizmów telemetrycznych i komunikacji wychodzącej. Szczególny nadzór powinien dotyczyć narzędzi mających dostęp do nagłówków, cookies, treści stron i danych sesyjnych.
Podsumowanie
Sprawa ModHeader pokazuje, że nawet popularne i powszechnie używane rozszerzenie może zawierać kompletny, warunkowo aktywowany mechanizm zbierania danych. Usunięcie dodatku przez Google i Microsoft ogranicza bezpośrednie ryzyko, ale nie rozwiązuje szerszego problemu zaufania do wysoko uprzywilejowanych rozszerzeń przeglądarkowych. Dla zespołów bezpieczeństwa to wyraźny sygnał, że ocena ryzyka powinna obejmować nie tylko aktualnie obserwowane zachowanie dodatku, lecz także ukryte funkcje, które mogą zostać aktywowane w przyszłości.
Źródła
- The Hacker News — https://thehackernews.com/2026/07/google-and-microsoft-pull-modheader.html
- Stripe OLT — https://stripeolt.com/modheader-and-the-risks-of-browser-extensions/
- Yunus Aydin — https://aydinnyunus.github.io/posts/modheader-analysis/
- HackIndex — https://hackindex.io/blog/modheader-extension-analysis/
- Krebs on Security — https://krebsonsecurity.com/2021/12/the-danger-of-browser-extensions-that-get-bought/