WebKit omija iCloud Private Relay i ujawnia prawdziwy adres IP użytkownika - Security Bez Tabu

WebKit omija iCloud Private Relay i ujawnia prawdziwy adres IP użytkownika

Cybersecurity news

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali problem prywatności związany z iCloud Private Relay oraz sposobem, w jaki WebKit obsługuje wybrane funkcje sieciowe. W określonych scenariuszach część ruchu może ominąć ścieżkę proxy i zostać wysłana bezpośrednio z urządzenia, co prowadzi do ujawnienia rzeczywistego adresu IP użytkownika.

To istotne osłabienie modelu ochrony prywatności, ponieważ iCloud Private Relay ma ograniczać możliwość powiązania użytkownika z jego lokalizacją, aktywnością sieciową i historią przeglądania. Jeśli jednak wybrane mechanizmy przeglądarki nie korzystają z tego samego tunelu co główny ruch webowy, założenia anonimizacji przestają być w pełni spójne.

W skrócie

  • Problem dotyczy mechanizmów DNS prefetching, WebAuthn Related Origin Requests oraz WebTransport.
  • Wskazane funkcje mogą inicjować połączenia poza tunelem iCloud Private Relay.
  • Skutkiem jest możliwość ujawnienia prawdziwego adresu IP użytkownika.
  • Zjawisko obejmuje Safari oraz inne przeglądarki na iOS i iPadOS korzystające z WebKit.
  • Szczególnie istotny jest wektor związany z WebAuthn, który może działać bez aktywnej interakcji użytkownika.

Kontekst / historia

iCloud Private Relay to element usługi iCloud+, zaprojektowany jako mechanizm ochrony prywatności podczas przeglądania internetu. Rozwiązanie opiera się na architekturze dwuskokowej, której celem jest rozdzielenie informacji o użytkowniku i odwiedzanej witrynie pomiędzy dwa niezależne przekaźniki. W założeniu żadna pojedyncza strona pośrednicząca nie powinna mieć pełnego wglądu zarówno w tożsamość użytkownika, jak i jego aktywność sieciową.

To nie pierwszy przypadek, gdy deklaracje prywatności są weryfikowane przez praktykę działania przeglądarek i systemowych komponentów sieciowych. W nowoczesnych platformach część operacji realizowana jest poza standardowym torem ładowania stron, a dodatkowe API webowe mogą korzystać z innych ścieżek połączeń, walidacji lub rozwiązywania nazw. To właśnie na styku tych mechanizmów najczęściej pojawiają się luki osłabiające anonimizację.

Analiza techniczna

Sedno problemu polega na tym, że nie wszystkie żądania generowane przez przeglądarkę i powiązane z nią usługi systemowe przechodzą przez identyczną ścieżkę sieciową. Jeśli dana funkcja korzysta z odrębnego mechanizmu DNS, własnej walidacji pochodzenia lub bezpośrednio zestawia połączenie transportowe, może ominąć warstwę proxy wykorzystywaną przez iCloud Private Relay.

Pierwszy wektor dotyczy DNS prefetching, czyli wcześniejszego rozwiązywania nazw domen w celu przyspieszenia ładowania stron. Jeżeli taki proces odbywa się poza tunelem prywatności, resolver, operator sieci lub inny punkt obserwacyjny może zobaczyć zarówno nazwę domeny, jak i rzeczywisty adres IP źródła.

Drugi przypadek obejmuje WebAuthn Related Origin Requests. WebAuthn jest szeroko stosowany do logowania z użyciem passkeys i działa w szczególnie wrażliwym obszarze bezpieczeństwa oraz prywatności. Z opisu badaczy wynika, że odpowiednio przygotowana witryna może wywołać pobranie pliku walidacyjnego przez usługę poświadczeń systemu operacyjnego w taki sposób, że żądanie zostanie wysłane bezpośrednio z urządzenia. W efekcie prawdziwy adres IP może zostać ujawniony nawet bez faktycznego użycia passkeys i bez aktywnego logowania użytkownika.

Trzeci element to WebTransport, nowoczesny mechanizm komunikacji oparty na HTTP/3 i QUIC, przeznaczony do niskolatencyjnej, dwukierunkowej transmisji danych. Jeśli implementacja zestawia połączenie poza warstwą proxy, rzeczywiste parametry sieciowe klienta mogą zostać ujawnione stronie docelowej lub infrastrukturze pośredniej.

Z technicznego punktu widzenia nie oznacza to przejęcia sesji ani złamania szyfrowania. Problem polega jednak na tym, że sam wyciek adresu IP wystarcza do osłabienia modelu prywatności. Adres IP może służyć do korelacji sesji, przybliżonej geolokalizacji, śledzenia aktywności pomiędzy różnymi usługami oraz łączenia tych danych z innymi technikami fingerprintingu.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest naruszenie oczekiwań użytkowników, którzy włączyli iCloud Private Relay właśnie po to, aby ukryć swój rzeczywisty adres IP. Jeżeli witryna lub podmiot pośredniczący może go odzyskać dzięki funkcjom WebKit, mechanizm prywatności przestaje zapewniać pełną ochronę przed korelacją ruchu.

Ryzyko ma znaczenie nie tylko dla zwykłych użytkowników, ale również dla dziennikarzy, aktywistów, osób podróżujących oraz pracowników działających w środowiskach podwyższonego nadzoru. W scenariuszach komercyjnych wyciek może zostać wykorzystany do dokładniejszego profilowania, wzmacniania identyfikatorów śledzących i omijania rozwiązań ograniczających monitoring użytkownika.

Dla organizacji problem ma także wymiar operacyjny i compliance. Jeśli polityki bezpieczeństwa lub komunikacja wewnętrzna zakładają, że określony ruch jest anonimizowany przez proxy, a w praktyce część połączeń wychodzi poza tę ścieżkę, powstaje luka pomiędzy deklarowaną a rzeczywistą ochroną. Co ważne, taki wyciek może zachodzić całkowicie w tle, bez komunikatów błędu i bez zauważalnych objawów po stronie użytkownika.

Rekomendacje

Organizacje powinny traktować iCloud Private Relay jako warstwę wzmacniającą prywatność, ale nie jako gwarancję pełnej anonimizacji wszystkich typów ruchu generowanego przez przeglądarkę i usługi systemowe. W środowiskach wymagających wysokiego poziomu ukrycia tożsamości sieciowej konieczna jest dodatkowa walidacja tego, które mechanizmy rzeczywiście korzystają z kontrolowanej ścieżki wyjścia.

  • Monitorować aktualizacje WebKit oraz poprawki dla iOS, iPadOS i macOS.
  • Testować zachowanie przeglądarek w kontrolowanych środowiskach z analizą ruchu sieciowego.
  • W scenariuszach wysokiego ryzyka rozważyć dodatkową warstwę ochrony, taką jak VPN.
  • Nie zakładać automatycznie, że deklaracja „ruch przez proxy” obejmuje wszystkie pomocnicze API i komponenty systemowe.
  • Uwzględnić osobne testy prywatności dla DNS, WebAuthn, QUIC, HTTP/3 i WebTransport.

Z perspektywy zespołów blue team warto rozszerzyć obserwowalność ruchu wychodzącego. Sama kontrola klasycznego ruchu HTTP i HTTPS może być niewystarczająca. Potrzebna jest także analiza zapytań DNS, połączeń QUIC oraz żądań inicjowanych przez usługi systemowe, które mogą podlegać innym zasadom niż główny proces przeglądarki.

Podsumowanie

Opisany problem pokazuje, że skuteczność ochrony prywatności zależy nie tylko od projektu samej usługi relay, lecz również od spójności całego stosu sieciowego. Jeśli wybrane mechanizmy WebKit potrafią ominąć proxy, nawet dobrze zaprojektowany model anonimizacji może zostać osłabiony przez pojedyncze wyjątki implementacyjne.

Dla użytkowników oznacza to realne ryzyko ujawnienia prawdziwego adresu IP, a dla organizacji konieczność ostrożniejszego modelowania zagrożeń. Najważniejsza lekcja jest prosta: deklarowana prywatność powinna być regularnie weryfikowana testami technicznymi, zwłaszcza gdy w grę wchodzą nowe API webowe i usługi systemowe działające poza główną ścieżką przeglądania.

Źródła