Przejdź do treści
Infrastruktura

Luka w Androidzie 16 omija VPN. Google nie zamierza jej naprawiać

Badacz bezpieczeństwa odkrył, jak aplikacja z podstawowymi uprawnieniami może ominąć VPN w Androidzie 16 i ujawnić prawdziwy adres IP. Google uznało problem za „Won’t Fix”. Podpowiadamy, jak się chronić.

3 min read
An abstract composition of a fragmented shield made of translucent glass panels, with a single beam of light piercing through a crack, surrounded by a dark cloud of tangled cables and small glowing data packets.

Badacz bezpieczeństwa o pseudonimie Yusu odkrył, że zwykła aplikacja w systemie Android 16 może ominąć włączony VPN i ujawnić prawdziwy adres IP urządzenia. Problem występuje nawet przy aktywnych opcjach „Always-On VPN” i „Block connections without VPN”. Google uznało zgłoszenie za „Won’t Fix”, co oznacza, że nie planuje łatania luki. Dla użytkowników to sygnał, że systemowe zabezpieczenia VPN nie są w pełni skuteczne.

Jak działa obejście VPN w Androidzie 16?

Mechanizm wykorzystuje funkcję QUIC teardown, dodaną w Androidzie 16 do obsługi połączeń QUIC. Gdy aplikacja kończy działanie, system może wysłać ramkę CONNECTION_CLOSE w jej imieniu, aby poinformować serwer o zamknięciu połączenia. Yusu odkrył, że metoda registerQuicConnectionClosePayload w ConnectivityManager akceptuje dowolny bufor bajtów i gniazdo UDP od każdej aplikacji z uprawnieniami INTERNET i ACCESS_NETWORK_STATE – oba przyznawane automatycznie.

Jak opisuje serwis Sekurak, złośliwa aplikacja przekazuje dane do procesu system_server, który nie podlega ograniczeniom routingu VPN. System_server otwiera gniazdo UDP i wysyła pakiet bezpośrednio przez fizyczne połączenie sieciowe, całkowicie pomijając tunel VPN. Filtry odpowiedzialne za opcję „Block connections without VPN” nie biorą pod uwagę procesów systemowych, a jedynie same aplikacje.

Kto jest zagrożony i jakie są konsekwencje?

Problem dotyczy wszystkich urządzeń z Androidem 16, na których użytkownik zainstaluje złośliwą aplikację. Do wykorzystania luki wystarczą podstawowe uprawnienia, które aplikacja otrzymuje automatycznie – nie wzbudzają one podejrzeń. Nawet przy włączonym VPN i trybie lockdown, atakujący może poznać prawdziwy adres IP ofiary.

Yusu zademonstrował działanie na smartfonie Google Pixel 8 z Androidem 16 i włączonym Proton VPN wraz z trybem lockdown. Przygotowana aplikacja ujawniała publiczny adres IP urządzenia zdalnemu serwerowi. Warto podkreślić, że nie chodzi o wyciek całego ruchu – problem dotyczy jedynie możliwości wysłania wybranych pakietów poza tunel. Mimo to dla osób dbających o prywatność, aktywistów czy pracowników zdalnych korzystających z firmowych VPN może to stanowić poważne ryzyko.

Reakcja Google i alternatywne rozwiązania

Yusu zgłosił problem zespołowi bezpieczeństwa Androida 12 kwietnia 2026 roku. Google sklasyfikowało go jako „Won’t Fix” oraz NSBC (Not Security Bulletin Class), stwierdzając, że nie spełnia kryteriów podatności. Mimo odwołania Yusu, który argumentował, że potencjalnie każda aplikacja może ujawniać adres IP bez wiedzy użytkownika, Google utrzymało swoje stanowisko i 29 kwietnia wyraziło zgodę na publiczne ujawnienie problemu.

Na szczęście istnieje alternatywa. Twórcy GrapheneOS, custom ROM-u skoncentrowanego na prywatności i bezpieczeństwie, całkowicie wyłączyli optymalizację registerQuicConnectionClosePayload w najnowszej wersji systemu. Dzięki temu skutecznie zneutralizowali potencjalne zagrożenie. Użytkownicy GrapheneOS są bezpieczni, ale pozostali muszą liczyć się z ryzykiem.

Jak się chronić?

Ponieważ Google nie zamierza łatać luki, użytkownicy muszą polegać na własnych środkach ostrożności. Przede wszystkim należy instalować aplikacje wyłącznie z zaufanych źródeł i unikać podejrzanych programów. W przypadku urządzeń z Androidem 16, które nie mogą korzystać z GrapheneOS, kluczowe jest zachowanie czujności.

Dla zaawansowanych użytkowników rozwiązaniem może być przejście na GrapheneOS, jeśli posiadają kompatybilne urządzenie (głównie Google Pixel). Należy też rozważyć korzystanie z VPN na poziomie routera, co uniezależnia ochronę od systemu operacyjnego. Administratorzy firmowi powinni rozważyć dodatkowe zabezpieczenia, takie jak polityki MDM (Mobile Device Management) blokujące instalację nieautoryzowanych aplikacji.

Odkrycie badacza pokazuje, że nawet zaawansowane funkcje bezpieczeństwa mogą mieć luki, a decyzje producentów nie zawsze idą w parze z oczekiwaniami użytkowników. W przypadku Androida 16 jedynym pewnym sposobem na ochronę przed tym konkretnym zagrożeniem pozostaje zmiana systemu na GrapheneOS lub rezygnacja z zaufania wbudowanym mechanizmom VPN.

Redakcja sekuret.pl

Redakcja sekuret.pl

AUTHOR