Android приложения, опирающиеся на sing-box, по своему дизайну используют открытое для всех приложений соединение на localhost. Помимо возможности обойти обход proxy соединения, приложения могут достичь DoS атаки, потенциально доведя падение до DNS утечки благодаря Google Issue Tracker. Предлагаю сообществу изучить этот вектор атаки со мной.
Мне также интересно, додумалось ли какое-либо государство до обнаружения VPN серверов таким образом.
Интересно.
Для начала, данную уязвимость может быть реализована не только через DoS. В той же ссылке что Вы скинули чуть ниже ТС (Топик Стартер, тот кто создал тему) написал что ещё при некоторых ситуациях может такое происходить, например при Force Kill приложения.
А при каких условиях происходит утечка?
- При отсутствии интернет-соединения через VPN-туннель
- При переключении между VPN-профилями
- При сбое или принудительной остановке VPN-службы
- При использовании нативных вызовов getaddrinfo()
А что насчёт sing-box в этом плане?
Для начала: sing-box использует TUN-интерфейс для перехвата сетевого трафика и реализует собственную DNS-подсистему. Что вроде бы должно огорождать от утечки?
Да ведь?
Но sing-box при этом использует стандартную модель VPN на Android через API, это видно здесь:
experimental/libbox/platform/interface.go
12 Initialize(networkManager adapter.NetworkManager) error
13 UsePlatformAutoDetectInterfaceControl() bool
14 AutoDetectInterfaceControl(fd int) error
А в файле protocol/tun/inbound.go вообще явно указано создание VPN конфигурации через API
302 if C.IsAndroid && t.platformInterface == nil {
303 t.tunOptions.BuildAndroidRules(t.networkManager.PackageManager())
304 }
А что дальше?
С учётом что ещё есть репорты о том же самом на Reddit где представитель VPN ответил следующее (перевод):
Привет! Kill Switch на Android является зависимой от операционной системы реализацией, а не зависящей от нашего клиента (поэтому другие пользователи также сообщали о подобном поведении с другими VPN, например, Mullvad и нативным WireGuard – источник).
Это поведение было передано нашим разработчикам, и мы продолжаем исследовать, можем ли мы что-то сделать со своей стороны, чтобы решить эту проблему.
Кроме того, существует специфическая для GrapheneOS проблема, которая может быть связана с этим:
Apps can bypass VPN with killswitch by sending multicast packets · Issue #3443 · GrapheneOS/os-issue-tracker · GitHubСпасибо, что сообщили. Мы обновим этот пост, если появятся новости по этому вопросу.
Оригинал
Hi! Kill Switch on Android is an OS-dependent implementation, rather than dependent on our client itself (which is why other users have also reported this behavior with other VPNs, viz. Mullvad & native WireGuard - source).
The behavior has been flagged to our developers, and we’re investigating further if there’s anything we can do from our end in order to address this.
Additionally, there’s a GrapheneOS specific issue that might be related to this:
Apps can bypass VPN with killswitch by sending multicast packets · Issue #3443 · GrapheneOS/os-issue-tracker · GitHub
Thanks for flagging. We’ll update this post if we have any news regarding the matter.
Разработчик GrapheneOS (ОС, который использовал реддитор выше) почти разделяет моё итоговое мнение
Итог
Можно ли как-то избежать этого?
Да, но с достаточным ущербом.
Схема следующая: В Android устройстве ставяться фиктивные DNS сервера, например 10.172.168.1, а в самом sing-box корректные, например 8.8.8.8 или 1.1.1.1. В итоге если соединение в sing-box падает и DNS начинает идти напрямую — они не дойдут. Только придёться все приложения через VPN тунелировать или только DNS запросы что тоже выглядит подозрительно.
А ещё?
Второй вариант решения это запрет 53 порта и другие виды надругательств через iptables/nftables и т.д
Третий - возможно поднять свой DNS сервер, например AdGuard DNS Home? Тут если честно не уверен в целесобразности для “антиобнаружения VPN”, но чтобы небыло leak настоящего гео, как вариант
А если не трогать?
Ну, будет у Вас уязвимость. Стоит ли беспокоиться? Это на Вашей совести, поступайте как знаете, ничего критичного в этом нет
Я думаю может и додумывались, но это забивание гвоздей микроскопом, есть другие более эффективные и менее ресурсозатратные методы по обнаружению VPN серверов. Например как в Иране путём анализа количества трафика до сервера и его паттерна.
Плохая формулировка с моей стороны.
Ещё DoT, DoH, которые нативные с Android 13, можно выставить в качестве системных. Единственное - я предполагаю, что можно совершить даунгрейд атаку, так что лучше перестраховаться и воспользоваться сервером с ограниченным/отсутвующим незашифрованным резолвером.
А по мне так античит доктрина, где нужно перетянуть ресурсы разработчика. Переписать интеграцию с sing-box - нетривиальная задача. К тому же, это сломает множество сделал и забыл решений.
Как вариант кстати, но использует ли Android всегда DOH/DOT аюсолютно для всего - вопрос интересный.
??? А при чём тут GUI натянутая на sing-box, если это проблема sing-box, а не условного nekobox? Как вариант я описал в возможных решениях, тогда да, разработчик условного nekobox сможет у себя такое реализовать.
Или может я вприницпе неправильно понял Вас?
Думаю, вы не поняли суть костыля. Любое установленное приложение может просканировать локалхост на предмет наличия прокси, и сделать запрос через него, тем самым установив айпи адрес впн сервера. Это не ресурсозатратное решение.
Нет, это проблема именно nekobox, v2rayng и других. sing-box предполагает использование tun интерфейса, а не прокси.
Для того чтобы использовать свой tun - пользователю нужны root права
Без root прав - только Android VPN API и мы опять возвращаемся к началу дискусии
Ну, допустим чтобы отправить запрос vless серверу нужно как минимум UUID знать? Не? Иначе он себя поведёт как обычный веб сервер, откинет HTTP 200 OK или что-то в том роде. Как приложение должно узнать UUID для подключение? Это самая интересная часть
Речь идёт о socks/http прокси, создаваемых v2rayng, nekoray по умолчанию на порту 10808. Вы можете убедиться в этом, отправив запрос курлом.
Эта часть моего ответа касалась источника проблемы. sing-box им не является т.к в принципе не предполагает раскрытия socks/http прокси.
Ещё раз: Речь идёт о прокси сервисе на локалхосте, создаваемом V2RayNG, Nekoray при старте приложения.
Запустите V2RayNG на телефоне и подключитесь к любому серверу. Откройте Termux/скомпилируйте curl+busybox и отправьте запрос:
curl --proxy http://localhost:10808 “https://ipinfo.io”
Емаё, я уже сонный, пол 4-го, не сразу понял что на телефоне делать надо)) Сейчас попробую
Не интересовался ситуацией на десктопе т.к в принципе не использую Nekoray из-за постоянных утечек днс. Предполагаю, что там по умолчанию отключен прокси сервис для упоротой схемы маршрутизации/обратились не к тому порту.
Ниразу не встречал пока что, ну или не замечал
На скрине видно что к тому, как и на телефоне сейчас проверил если к порту 2080 обратиться то да, выдаёт ip моего сервера, но может можно просто порт повыше кинуть, как вариант?
Я спать пойду всё таки, время много. Напишу в android studio apk и гляну как это будет работать сегодня
Так можно просканировать весь диапазон портов.
любое приложение на андроид может определить что в системе включен впн и видит все listen порты разом, доступ к инету без впн можно запретить в настройках для прог, но проблема ваша высосана из пальца и вообще с ней лучше на другой форум
Да. Но к чему это?
Можно, но эта настройка не влияет на описанную проблему.
Посылаю вас с вашей грубостью и невежеством туда же.
Этим и занимается всякие Ростикс и вкусно и точка, ты их не проксируешь, но пока VPN включен они ничего не загрузят.
Он насчёт вопроса - зачем приложению curl’ом что-то отправлять если добавляется в код следуещее:
NetworkCapabilities caps = connectivityManager.getNetworkCapabilities(activeNetwork);
boolean vpnInUse = caps!=null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);
и в boolean будет заветное значение, есть ли включенный VPN или нет.
@shiel Я бы сказал это ничем (для пользователя) не исправавить. Если хотите поглубже заняться вопросом то можете “упаковать” L2/L3 в L4, и на этом принципе и основе сделать своё VPN приложение.
Этот вопром звучит как “А вдруг хуЯндекс браузер будет проводить MITM-атаку через сертификат для прочтения нашего трафика”. Может, но дорого это ему обойдётся.
Так же хочу сказать что Ваш изначальный вопрос вообще не звучит как curl на localhost, а идёт речь про утечку
Помимо возможности обойти обход proxy соединения, приложения могут достичь DoS атаки, потенциально доведя падение до DNS утечки благодаря Google Issue Tracker. Предлагаю сообществу изучить этот вектор атаки со мной.
Я в итоге не понял Вашего вопроса, Вы про dns или curl на localhost?
Человек совершенно не понял суть проблемы. Приложение может тривиально обойти geoip и per-app tunneling правила, которые настраивают китайцы для того, чтобы не “палить” перед mainland адрес VPN сервера. Банальность вроде того, что приложения могут обнаружать друг друга 1000 и 1 способом никак не относится к модели угрозы, которую я описал.
Я про изучение площади атаки sing-box оберток на Android.
Я не понимаю, каким образом добавление небольшого сниппета кода в WeChat, госуслуги обойдется государству коллосальными затратами.
Высокий уровень дискуссии, как говорится.
Вы не поняли, что я имел в виду не финансовые потери)
Способ возможного решения проблемы я описал выше
Я честно не понимаю, отчего сразу у двух пользователей развилась дислексия.
В сотый раз повторяю, что речь идет об установлении соединения с proxy сервисом на localhost телефона, который ведет трафик через V2RayN(G), Nekoray соединения. В этом сценарии достаточно иметь одно зловредное приложение на телефоне.
Вы одновременно не понимаете и модели угрозы, и технического описания способа обойти настройки туннелирования.
Модель угрозы:
In Chinese proxy community, we use geosite and geoip for dns/routing strategy. You should always try your best to avoid querying known blocked domain name to local Dns Server, as it reveals the fact that you are trying to break GFW (or whatever internet enforcement put in your area). It’s called dns leakage.
Приложения могут вшивать обращения к подконтрольному GFW серверу, который находится за пределами Китая (важно подпасть под geoip правила), чтобы таким образом вычислить адрес прокси сервера. Для этого в V2RayNG, Nekoray предусмотрен режим per-app туннелирования, чтобы WeChat гарантированно проходил через mainland соединение.
Проблема в том, что приложение может в обход настроек туннелирования пропустить запрос через прокси.