ИТ-убежище от эффективных сов. Read-Only для твоей нервной системы.
Упал прод — ложись и ты.
🤝Реклама: @sysodmin
💚Предложка: @sysmeme_bot
🔴Баны_разбаны: @sysmeme_bot
РКН: vk.cc/cJ0Tm9
Post #29790
8.38K
😮 Любой Android 12+ сливает реальный IP через NAT-T Keepalive
Сегодня в рубрике "безопасность мобильных ОС" будет архитектурный факап от Гугла. Исследователь выкатил репорт с анализом того, как функция блокирования соединения без VPN в Android оказалась дырявой на уровне системного API.
Для начала освежим теорию. Когда в Android тыкают на "Блокировать соединения без VPN", система обещает изоляцию, где любой пакет от любого приложения, которое завернуто в VPN, должен либо уйти в шифрованный TUN-интерфейс, либо умереть, если VPN отвалился. Трафик не должен миновать туннель и засветить реальный IP-адрес 👺
Но, ВНЕЗАПНО, была найдена дыра, которая позволяет обычному приложению (даже без рута и хитрых доступов) слать
В Android есть публичный API для поддержания NAT-T соединений (NAT Traversal, используется для IPsec). Приложение может дернуть
Дальше запрос проваливается в метод
Раньше этот метод был привилегированным (требовал пермишен
Но потом что-то пошло не так и Гугл... просто выпилил эти проверки владения ресурсом и привязку к политике VPN, заменив их обычными квотами на количество слотов.
В итоге обычная аппка (имея только базовое разрешение) дублирует файловый дескриптор, передает его в этот дырявый метод, и система передает задачу на аппаратный оффлоад.
Железо начинает раз в 10 секунд, плевать UDP-пакеты на порт 4500 по указанному адресу. И делает оно это на самом низком уровне, в обход всех правил маршрутизации андроида и ограничений VPN Lockdown 🤬
Уязвимость подтверждена на дампах трафика Pixel 8 Pro, Samsung и Nothing Phone. Получается, что дыра охватывает 91% всех Android-устройств в мире (так как баг сидит в фреймворке начиная с 12 версии ОС и затрагивает чипы Qualcomm, Broadcom, MediaTek и etc).
Юзающий этот баг не может передать через эту дыру полезную нагрузку (содержимое пакета фиксировано системой), но ему это и не нужно. Сам факт того, что телефон с включенным VPN-локадауном стабильно шлет пинги на его сервер с вашего реального IP-адреса, полностью убивает всю концепцию приватности и деанонимизирует ⚰️
Типичный 🥸 Сисадмин
Сегодня в рубрике "безопасность мобильных ОС" будет архитектурный факап от Гугла. Исследователь выкатил репорт с анализом того, как функция блокирования соединения без VPN в Android оказалась дырявой на уровне системного API.
Для начала освежим теорию. Когда в Android тыкают на "Блокировать соединения без VPN", система обещает изоляцию, где любой пакет от любого приложения, которое завернуто в VPN, должен либо уйти в шифрованный TUN-интерфейс, либо умереть, если VPN отвалился. Трафик не должен миновать туннель и засветить реальный IP-адрес 👺
Но, ВНЕЗАПНО, была найдена дыра, которая позволяет обычному приложению (даже без рута и хитрых доступов) слать
UDP/4500 пакеты напрямую, в обход VPN-туннеля и любых правил. В Android есть публичный API для поддержания NAT-T соединений (NAT Traversal, используется для IPsec). Приложение может дернуть
IpSecManager.UdpEncapsulationSocket и попросить систему чтобы ConnectivityManager держал сокет открытым и слал пакеты поддержания связи, чтобы NAT провайдера не закрыл сессию.Дальше запрос проваливается в метод
startNattKeepaliveWithFd(). И вот тут начинается весь карнавал с правами доступа:Раньше этот метод был привилегированным (требовал пермишен
PACKET_KEEPALIVE_OFFLOAD). Но в 2019 году в Гугле решили пустить туда обычные приложения для работы с IPsec. Чтобы всё было безопасно, они ввели проверки... система должна была убедиться, что приложение реально владеет этим IPsec-ресурсом. Но потом что-то пошло не так и Гугл... просто выпилил эти проверки владения ресурсом и привязку к политике VPN, заменив их обычными квотами на количество слотов.
В итоге обычная аппка (имея только базовое разрешение) дублирует файловый дескриптор, передает его в этот дырявый метод, и система передает задачу на аппаратный оффлоад.
Железо начинает раз в 10 секунд, плевать UDP-пакеты на порт 4500 по указанному адресу. И делает оно это на самом низком уровне, в обход всех правил маршрутизации андроида и ограничений VPN Lockdown 🤬
Уязвимость подтверждена на дампах трафика Pixel 8 Pro, Samsung и Nothing Phone. Получается, что дыра охватывает 91% всех Android-устройств в мире (так как баг сидит в фреймворке начиная с 12 версии ОС и затрагивает чипы Qualcomm, Broadcom, MediaTek и etc).
Юзающий этот баг не может передать через эту дыру полезную нагрузку (содержимое пакета фиксировано системой), но ему это и не нужно. Сам факт того, что телефон с включенным VPN-локадауном стабильно шлет пинги на его сервер с вашего реального IP-адреса, полностью убивает всю концепцию приватности и деанонимизирует ⚰️
Типичный 🥸 Сисадмин
- ✍ 20
- ❤ 8
- 🗿 5
- 😱 4
- 💔 2
- 😁 1










