Wprowadzenie do problemu / definicja
Przejęcie wygasłej domeny wykorzystywanej wcześniej przez dostawcę CDN to istotny przykład ryzyka łańcucha dostaw po stronie przeglądarki. Zagrożenie nie wynika z bezpośredniego włamania do infrastruktury ofiary, ale z pozostawienia w kodzie strony odwołań do zewnętrznych zasobów, nad którymi pierwotny właściciel utracił kontrolę. Jeśli taka domena zostanie ponownie zarejestrowana, historyczne adresy skryptów, bibliotek czy arkuszy stylów mogą zacząć wskazywać na zasoby kontrolowane przez podmiot trzeci.
W skrócie
W opisywanym przypadku ponownie zarejestrowano domenę należącą wcześniej do nieaktywnej usługi CDN. Choć usługa przestała działać lata temu, wiele stron internetowych, repozytoriów i dokumentacji nadal zawierało twardo zakodowane odwołania do hostów w tej domenie. Nowy właściciel uzyskał kontrolę nad rekordami wildcard DNS, co oznacza, że historyczne subdomeny używane przez serwisy mogą dziś kierować ruch do niekontrolowanego źródła.
- Tysiące serwisów nadal może ładować zasoby z przejętej domeny.
- Zagrożenie dotyczy skryptów, stylów, fontów i innych komponentów ładowanych w przeglądarce.
- Problem może pozostać niewidoczny, ponieważ strona pozornie działa poprawnie.
Kontekst / historia
Incydent wpisuje się w szerszy problem zaufania do zewnętrznych zasobów osadzanych bezpośrednio w aplikacjach webowych. Organizacje od lat korzystają z bibliotek JavaScript, widżetów, trackerów, fontów i innych elementów hostowanych przez podmioty trzecie. Gdy usługa kończy działalność albo porzuca domenę, stare referencje często pozostają w kodzie produkcyjnym przez długi czas.
Z perspektywy bezpieczeństwa to szczególnie niebezpieczne, ponieważ kompromitacja może nastąpić po stronie klienta, bez naruszania backendu ofiary. Oznacza to, że klasyczne procesy zarządzania podatnościami, skoncentrowane na serwerach, bibliotekach aplikacyjnych i pipeline CI/CD, mogą nie wykryć realnego zagrożenia wynikającego z dynamicznie ładowanych zasobów zewnętrznych.
Analiza techniczna
Rdzeń problemu polega na tym, że przeglądarka ufa kodowi dostarczanemu z adresu wskazanego przez stronę. Jeśli aplikacja zawiera odwołanie do skryptu z domeny zewnętrznej, a DNS poprawnie rozwiązuje nazwę hosta, przeglądarka pobiera i uruchamia taki kod w kontekście witryny. W praktyce daje to skryptowi bardzo szerokie możliwości oddziaływania na sesję użytkownika.
Ryzyko rośnie jeszcze bardziej, gdy nowy właściciel domeny przejmuje wildcard DNS dla całej strefy. Wtedy nie musi odtwarzać pełnej infrastruktury dawnego CDN. Wystarczy, że odpowie na żądania dla historycznych nazw hostów, aby zacząć dostarczać własne treści do witryn, które nigdy nie usunęły starych odwołań.
Taki scenariusz omija wiele tradycyjnych narzędzi bezpieczeństwa. SAST nie wykryje złośliwego kodu, jeśli w repozytorium znajduje się jedynie poprawnie wyglądający adres URL. SCA także może okazać się nieskuteczne, ponieważ problem nie dotyczy zależności zarządzanej przez menedżer pakietów, lecz zasobu pobieranego dynamicznie podczas renderowania strony.
Skutki techniczne mogą być bardzo poważne. Złośliwy skrypt może przechwytywać dane z formularzy, odczytywać DOM, uzyskiwać dostęp do localStorage, modyfikować treść strony, osadzać fałszywe pola płatności, przekierowywać użytkowników albo ładować kolejne etapy ataku. Taki model jest zbliżony do kampanii web skimming i ataków typu Magecart, choć wektor wejścia wynika tutaj z odziedziczonego zaufania do porzuconej domeny.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem jest możliwość cichej kompromitacji dużej liczby serwisów jednocześnie. Jeśli jedna historycznie popularna domena była używana przez wiele witryn, jej ponowne przejęcie może stać się centralnym punktem masowego ataku na użytkowników końcowych.
- kradzież danych logowania,
- przechwytywanie danych kart płatniczych,
- wstrzykiwanie złośliwych przekierowań,
- naruszenie integralności treści prezentowanych użytkownikowi,
- problemy zgodności i audytu,
- straty reputacyjne mimo braku bezpośredniego włamania do infrastruktury.
Dodatkowym wyzwaniem jest niska widoczność takiego incydentu. Backend może działać poprawnie, logi serwera mogą nie pokazywać niczego podejrzanego, a realna aktywność złośliwego kodu zachodzi wyłącznie w przeglądarce użytkownika.
Rekomendacje
Organizacje powinny traktować zasoby third-party ładowane po stronie klienta jako pełnoprawny element powierzchni ataku. Ograniczenie ryzyka wymaga działań technicznych i organizacyjnych.
- Przeprowadzić pełną inwentaryzację zewnętrznych skryptów, iframe, fontów i bibliotek frontendowych.
- Usunąć nieużywane odwołania oraz zweryfikować właścicieli i stan domen źródłowych.
- W miarę możliwości hostować krytyczne komponenty samodzielnie lub dostarczać je z kontrolowanego repozytorium.
- Wdrożyć Content Security Policy, najlepiej rozpoczynając od trybu raportowania.
- Stosować Subresource Integrity dla krytycznych zasobów zewnętrznych, jeśli architektura na to pozwala.
- Monitorować wygasanie domen powiązanych z aplikacją, partnerami i dawnymi dostawcami.
- Rozbudować monitoring client-side o raporty CSP i analizę połączeń przeglądarki do zewnętrznych hostów.
Podsumowanie
Przejęcie wygasłej domeny CDN pokazuje, że bezpieczeństwo aplikacji webowej nie kończy się na ochronie backendu i aktualizacji zależności w repozytorium. Historyczne odwołania do zewnętrznych zasobów mogą przez lata pozostawać aktywnym kanałem dostarczenia złośliwego kodu. Dla organizacji to sygnał, że konieczna jest stała kontrola zależności third-party, ograniczanie zaufania do zewnętrznych domen oraz budowanie widoczności zagrożeń na poziomie przeglądarki użytkownika.