Contents
Пълен курс по етичен хакерство: От нула до експерт
Хаквайте като хакери с черни шапки. Тестване за проникване, Kali Linux, WiFi и уеб хакерство, както и хакерският начин на мислене зад тях.
Телефонът ви продължаваше да изпраща адреса си на всеки 10 секунди, докато VPN kill switch беше включен, към сървър, избран от приложението. Mullvad съобщава, че всяко приложение може да го направи. Повечето телефони от Android 12 нататък са уязвими.
Android има настройка, наречена Блокиране на връзки без VPN. Включете я и се предполага, че телефонът ще откаже да изпраща каквото и да е в момента, в който трафикът би преминал извън тунела. Пълно блокиране при срив. Това обещание е причината хората да я включват и е това, на което много от вас разчитат в момента.
На 10 септември Mullvad предупреди своите потребители за изтичане на данни, което преминава директно покрай тази защита. Обикновено приложение от магазин може да накара телефона ви да изпраща малък пакет до адрес по негов избор, отново и отново, през 10 секунди. Нищо от това не показва подкана на екрана ви. Пакетът излиза през нормалната ви Wi-Fi връзка вместо през тунела и носи адреса, предоставен от вашата мрежа. Блокирането остава включено и нищо на екрана не се променя.
Изследването зад това е дело на Armin Šupuk, който публикува пълния анализ на 29 юли заедно с прихванатите от него пакети.
Това, с което се злоупотребява тук, е функция за пестене на батерията. Когато телефонът ви поддържа връзката отворена, нещо трябва от време на време да изпраща малък пакет, в противен случай рутерът по средата решава, че връзката е прекъсната, и я прекъсва. Събуждането на процесора за това изразходва енергия, така че Android прехвърля тази задача на Wi-Fi чипа. Чипът изпраща пакета по собствен график, докато останалата част от телефона спи. Собствената документация на Android го описва с едно изречение: тя позволява на приложенията да заявяват системата периодично да изпраща специфични пакети от тяхно име, използвайки хардкуерен offload за пестене на енергия от батерията.
Именно тук блокирането се проваля. Блокирането на връзки без VPN е правило на защитната стена (firewall), а правилото на защитната стена работи върху трафик, който идва от приложения. Този пакет не идва от приложение. Той идва от чипа, под слоя, където живее правилото, така че правилото никога не стига до него.
Три реда код са достатъчни и трите са документирани публични API:
Приложението се нуждае от INTERNET и ACCESS_NETWORK_STATE, двете обикновени мрежови разрешения, които никога не показват подкана на екрана ви. Root достъп не е необходим, нито debugging bridge, както и привилегированото разрешение, което Android поддържа точно за тази функция.
На рутер, разположен до телефона, резултатът изглежда така:
През 10 секунди, порт 4500, единен байт злонамерен код. Адресът отляво е телефонът, както го вижда мрежата, а адресът отдясно е каквото и да е решило да посочи приложението.
Собствените правила на Android казват, че телефон, който предлага това, трябва да поддържа поне три от тях едновременно. На устройствата, които той тества, след като системата беше взела своите, остана точно един за обикновено приложение. Следващото приложение, което поиска, получава обратно ERROR_INSUFFICIENT_RESOURCES, код за грешка -32, така че който пристигне пръв, го запазва. А 10 секунди е прагът, а не единствената настройка, тъй като Android приема всичко до 3600 секунди, което е един час. Приложение, което предпочита да остане незабелязано, може да се върне до веднъж на час и пак да прихване адреса ви 24 пъти на ден.
Това продължава и по-нататък. Изследователят постави телефона през това, което един обикновен ден прави с едно приложение. Той го изпрати във фонов режим, заключи екрана, принуди го да премине в режим на престой (idle), включи режима за пестене на батерията и го постави в ограничението за изчакване, където Android изолира приложенията, от които се е отказал. Пакетите продължиха да излизат. На един от тестовите телефони слот за keepalive остана активен повече от 24 часа и 32 минути без прекъсване. Принудителното спиране на приложението го прекратява, както и премахването му, загубата на мрежата или рестартирането на телефона. Тези четири са това, което е необходимо.
Изследователят тества три телефона от трима различни производители, всички с Android 16: Pixel 8 Pro, сгъваем Samsung и телефон Nothing. Самата функция за offload се съдържа в седем фамилии Wi-Fi фърмуер, сред които Qualcomm, Broadcom, MediaTek, Unisoc, Exynos и HiSilicon, което той изчислява на 91,24 процента от телефоните с Android, доставени между края на 2021 г. и началото на 2026 г. Кодът, който пропуска заявката, е споделен framework код, същият от Android 12 нататък. Същият телефон с Android 17 все още показва свободен слот. Той внимава какво доказва това: слотът е там, но самият bypass той не е измерил на тази версия.
Тази дупка не винаги е била там и установяването кога се е появила изискваше четене на седем години събмити (commits).
През януари 2019 г. пътят за keepalive беше въведен само за привилегировани потребители и Android прилагаше разрешението правилно. През март публичната версия премина на същия този път. През април се появи проверка: докажете, че сокетът, който предавате, наистина е ваш. През май някой отмени тази проверка поради притеснения за взаимно блокиране (deadlock) между системните услуги, и проста квота за приложение зае нейното място.
Проверката за собственост никога не се върна. Това, което работи днес, приема всеки file descriptor, който не е null, и не преглежда по съществен начин идентификатора на ресурса, който идва с него. В отделен тест, който се намира до основното констатиране, а не вътре в него, той подаде на системата 0, -2 и най-голямото и най-малкото цяло число, които тя може да съдържа. Тя прие всяко от тях. Това е състоянието на нещата от седем години.
Изследователите са преминали директно покрай него преди една година. Изследване от 2025 г. от Ватерло проучи рамката на Android Automotive за несъответствия в разрешенията и маркира точно този метод, този, който приема file descriptor. Неговият близнак изисква привилегировано разрешение, а този не го прави. Те съобщиха за несъответствието и продължиха напред. Нишката оттам до заобикаляне на VPN остана недокосната досега.
Той също така преброи кой въобще се нуждае от тази функция. В 4 679 отделни източника във F-Droid и IzzyOnDroid нито едно приложение не използва тези API. В Google Play той откри 26 листвания, които изглеждаха като потенциални кандидати, и успя да се сдобие с девет от тях. Две от тези девет всъщност ги извикват, общо за около 4,13 милиона инсталации, което прави най-много един потребител на Android на десет хиляди. Затварянето на вратата не би счупило почти нищо.
Той също така описва решението за отстраняване на уязвимостта и то не е голямо. Публичният извикващ субект трябва да докаже, че притежава активен капсулиращ сокет, а системата да откаже хардуерно разтоварване (offload) към физическата мрежа, когато блокирането за това приложение така или иначе би спряло трафика. Две правила в момента, в който постъпи заявката.
Неговата по-кратка версия се побира на един ред. В проследяващата система за проблеми на GrapheneOS той посочва една-единствена конфигурационна стойност, config_allowedUnprivilegedKeepalivePerUid. Задайте я на нула и обикновените приложения няма да получат слот. Неговите собствени думи за това: корекция от един ред. Отворена седем години, едно число да я затвори.
Изследователят подаде доклада до програмата Android Vulnerability Reward Program на 15 май, а екипът го триажира още същия ден. Допълнителни материали за валидация последваха два дни по-късно. На 19 май той беше отбелязан към съществуващ вътрешен проблем като дубликат с номер 386376240, който не е публичен: отворете го и получавате само екран за вход. През юни той уведоми Google, че възнамерява да публикува. Два маркера за актуализация бяха поставениъв файла на 12 и 15 юни, и двата редактирани (скрити), а това, което се върна към него, не съдържаше нито оценка за сериозност, нито дата за отстраняване. Докладът беше публикуван на 29 юли. Несъвършенството все още няма CVE номер. CyberInsider поиска коментар от Google по този въпрос, но нямаше отговор до момента на публикуването.
Mullvad го предостави на вниманието на своите потребители на 10 септември. Тяхното изречение оставя малко място за съмнение: новооткрита изтичане в Android позволява на всяко приложение да изпраща трафик извън VPN тунела.
Те също така заявяват директно, че няма да внедрят заобиколно решение в собственото си приложение. Всичко, което биха могли да изградят, би трябвало самото то да изпраща пакети извън тунела, макар и само до техните собствени сървъри, а злонамерено приложение може да работи преди VPN приложението да е стартирало. Техният съвет е да инсталирате само приложения, на които имате доверие, и когато е възможно, да използвате GrapheneOS.
Това е четвъртият път за четири години, в който същият този превключвател се оказва недостатъчен, и Mullvad са били там и при четирите случая.
- → Октомври 2022 г. Android изпраща своите проверки за свързаност извън тунела всеки път, когато телефонът се присъедини към Wi-Fi мрежа, независимо дали има пълно блокиране (lockdown) или не. Заключението на Mullvad по онова време: няма какво да направим в приложението, за да коригираме изтичанията, но можем да информираме нашите потребители, че те съществуват.
- → Май 2024 г. DNS трафикът изтича извън тунела. Mullvad пише, че настройката не отговаря на името си, нито на документацията си, и че има множество дефекти.
- → Април 2026 г. QUIC път за почистване позволява на дадено приложение да изтласка данни извън блокирането. Екипът по сигурността на Android затвори този проблем със статус Won’t Fix (Няма да се коригира). GrapheneOS пусна корекция във версия
2026050400, коммит7930a86931, като изключи оптимизацията. Коментарът на Google пред пресата беше, че това засяга само устройства, които са изтеглили злонамерено приложение, и че Play Protect защитава потребителите от известни злонамерени приложения. - → Септември 2026 г. Настоящият случай.
Четири пъти едно и също обещание и четири пъти приблизително един и същ отговор. Страната, която продължава да затваря тези вратички, е малка разклонение (fork) на Android, а не компанията, чието име стои върху настройката.
Даже четири са само онези случаи, които са стигнали до пресата. В същата проследяваща система за проблеми разработчик от GrapheneOS пише, че са открили и отстранили поне още десет изтичания, които все още не са качени в официалното издание, всички те ръчно. Той обяснява защо това не е на върха на приоритетите: има изтичания, които се случват без приложението изобщо да опитва каквото и да било, и те са с предимство. По отношение на парите той е директен. Google не ни плаща и няма да ви плати за изтичания през VPN. В същата тема изследователят пише, че човекът, открил изтичането през април, също не е получил възнаграждение и че обжалването му не е довело до нищо. Два известни маршрута вече изтласкват вашия адрес извън блокирането и нито един от тях не бива затворен при самия източник.
Вашите съобщения остават в тунела, както и вашето сърфиране и всичко, което въвеждате. Излиза само един байт от телефона. Това, което отсрещната страна събира, е адресът, който вашата мрежа вижда, знанието, че телефонът ви е включен, и неговият ритъм, на интервали от по 10 секунди. За преследвач или разследващ, който се опитва да свърже анонимен профил с човек, седящ в конкретна къща, това не е малка награда, но е нещо съвсем различно от четенето на вашия трафик.
Какво можете да направите днес:
- → Използвайте GrapheneOS, ако телефонът ви я поддържа. Те потвърдиха този проблем и работят по отстраняването на уязвимостта.
- → Поддържайте списъка си с приложения кратък и стандартен. Това изисква приложение на вашия телефон, за да проработи, и собственият отговор на Google разчита изцяло на това.
- → Принудителното спиране (Force stop) на приложението го прекратява, както и деинсталирането му или рестартирането на телефона. Заключването на екрана не го спира.
- → Наблюдавайте собствената си мрежа. Поставете телефона във вашия Wi-Fi, прихванете трафика на рутера и търсете UDP, насочен към порт
4500, докато тунелът е активен. Едно предупреждение, преди да правите заключения: 4500 е стандартният порт за IPsec NAT traversal, така че VPN, който използва IKEv2 или IPsec, също изпраща легитимен трафик там, и само номерът на порта няма да ви каже кой кой е. - → Преминаването към друг VPN доставчик не помага. Това се случва под нивото на VPN приложението, поради което никое VPN приложение не може да го спре.