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

Спасибо, что сообщили. Мы обновим этот пост, если появятся новости по этому вопросу.

Разработчик GrapheneOS (ОС, который использовал реддитор выше) почти разделяет моё итоговое мнение

image595×372 34.1 KB

Итог

Можно ли как-то избежать этого?

Да, но с достаточным ущербом.
Схема следующая: В 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 соединение.

Проблема в том, что приложение может в обход настроек туннелирования пропустить запрос через прокси.

Понимаю, но что Вы предлагаете сделать в данном случае тогда?

Так Вы определитесь можно ли geoip правила обойти или нет.

Я Вас понял, только не пойму что Вы хотите в итоге? Способ решение или диалог что такая проблема существует? Проблема в реализации api на стороне android. С ПК я с того же nekobox Вам выслал скрин что такая схема не прокатывает на ПК, приходит HTTP/400 и всё.

Решение через конвертирование L2/L3 в L4 возможно поможет. Или гарантированно устанавливать VPN на роутер и там ставить правила, но это костыли, а не решение проблемы

Можно обойти и geoip правило, и per-app туннелирование. Подумали бы хоть немного, прежде чем писать.

this.

На ПК существование этой проблемы зависит от изоляции приложений, настроек фаерволла. На скрине, который вы вчера отправили, не было совершено запроса curl’ом через прокси, а HTTP 400 нельзя однозначно трактовать, потому что непонятно, какой тип прокси использует Nekoray.

V2RayNG, Nekoray нужно по умолчанию отключить прокси сервис, добавить возможность установить методы аутентификации. Я не встречал приложений, которые бы отказывались работать из-за наличия tun интерфейса. Насколько я понимаю, по правилам GPlay такое приложение нельзя выпускать в стор. Но даже для такого эджкейса можно договориться об IPC соединениях с разработчиками, или, что проще, попросить их внедрить методы аутентификации.

Думаю, от этого можно защититься, используя double vpn. Когда входной IP не равен выходному. У некоторых коммерческих сервисов такое реализовано. Таким образом, вражий сервер узнает только выходной IP впна и не узнает входной (к которому соединяется пользователь на стороне ISP), соответственно не сможет заблокировать.

К примеру, может заблокировать выходной (у местных китайских сайтов для входящих). Это приведёт к тому, что через VPN местные сайты не откроются. Хотя, на местные сайты через VPN обычно не ходят в Китае.

Те, кто настраивает впски, знают ли об этом? Надёжнее защититься разнеся IP.

Не поможет, если добавить уникальности пользователям. Скажем, возьми с такого-то зарубежного сервера файл по уникальному пути. Но это действительно усложнит техническую реализацию.

Двойной впн у Китайцев повсеместен.

Я думаю можно такое реализовать через warp от CF или через worker (BNB панель (точного названия не помню)) от того же CF. И получается напрмимер User ↔ VPS w/ VLESS ↔ WARP.

Представим такую картину. Есть полезный местный сервис (в виде сайта в браузере на десктопе или мобильное приложение на смартфоне), но со злым намерением среди прочего вычислить vpn.
Предположим, сервис делает два запроса (javascript логикой).

1. на местный whatsmyip сервис. на девайсе nekoray или nekobox по geoip отправляют запрос напрямую. сервис узнаёт местный ip и может идентифицировать пользователя.
2. на зарубежный, но подконтрольный whatsmyip сервис. на девайсе nekoray или nekobox по geoip проксируют трафик через прокси. Если это double proxy (или double vpn), сервис (напомню, местное приложение или вкладка в браузере) может узнать выходной IP прокси (хотя, пользы от этого немного, разве что детектится факт обмана gfw). Какой входной IP прокси сервис вроде бы узнать не может, ведь соединениями заведует система. В браузере думаю на этом всё и ограничится. А если отдельное приложение и ему не помешает системный файервол, оно может проверить хопы по ICMP (traceroute). И в некоторых случаях посмотреть сетевые настройки. А затем сложить А и Б. Хотя, ICMP ведь через прокси не пройдёт, а через полноценный VPN пройдёт.

Таким образом, geoip разделение не очень надёжно. Надо или per app или всё пускать через VPN/прокси. Но тогда на местные сайты не ходить (ничего критичного, вы будете как иностранец, но незачем). А если ходить, то не авторизовываться (утечка). Можно для местных завести отдельный браузер или девайс.

Но это всё имеет значение, если цензор настолько мощный, что может сверять запросы со всех ISP в стране, сравнивать с логами проверочных серверов. Я думаю, непростая задача.

Допустим, но помним, но ipv4 не бесконечны, а их всего 4 млрд., людей в 2 раза больше, а устройств ещё в 5 раз больше (у большинства есть телефоны, планшеты (оба с симкой), роутеры, общественные роутеры и так далее). За NAT около нереально вычислить кто сидит, даже в офф. документе РКН про новый закон просят до NAT ставить ТСПУ.

изображение723×376 8.84 KB

sudo iptables -A INPUT -p icmp -j DROP

И выглядить Ваш VPS будет вот так:

Чем сетевые настройки помогут в обнаружение IP VPS? Понять что есть адаптер? Есть ещё 100500 способов понять что у юзера VPN стоит.

В большинстве случаев такой вариант будет означать покупку ещё одного девайса, IMEI, Fingerprint у браузера и другие опознавательные методы никуда не деваются.

UPD: насчёт curl на ПК с nekobox:

замазал не нужную информацию2383×911 265 KB

V2RayNG не использует sing-box вообще. Название ветки (Площадь атаки sing-box костылей на Android) вводит в заблуждение.

Есть Аndroid приложения, использующие ядро sing-box, но не создающие по умолчанию прокси на локалхосте - тот же SFA.

И правда, V2RayNG не использует sing-box. Я изначально использовал неправильный, но, поверьте, и костыли этим страдают.

вводит в заблуждение.

Я постараюсь найти время задокументировать свои тесты.

Не прокатит из-за возможности корреляции трафика. Провайдеры передают цензору передают пользовательские идентификаторы, злое приложение в нашем сцценарии тоже присваивает каждому пользователю уникальный идентификатор. Тогда цензору необязательно сверять трафик множества людей. Атака всё ещё экономична. А, блин, вы и так с этим согласны…

Не совсем понимаю, к чему это, если на устройстве с доступом за стену не будет зловредных приложений в принципе.

Чуточку лучше, Но настройка из коробки, вероятно, следует какому-то встроенному geoip правилу, так что к ней применима наша дискуссия. Но я не готов хулить разработчика за это, потому что у десктопа в принципе по умолчанию отсутствует модель безопасности. К моменту, когда зловредное приложение окажетс на компьютере, у среднестатистического пользователя Linux/Windows будут проблемы куда хуже.

На самом деле, у современных версий Android нет сетевой взаимосвязи между главным пользователем и остальными. Можно содержать государственные приложения в приватной области/профиле, тем самым отбивая нужду во втором телефоне.

На моём скрине видно что localhost всё таки поднят и используеться. Нет, вы не угадали, все geoip правила стоят на стороне сервера (по причинам более страшего поколения, которому 1 большую кнопку для вкл или выкл нажать - уже надо диплом получать по сис. администрированию, не суть), только private идёт напрямую, и то, я проверил и удаление всех geoip правил оставляет ситуацию прежней.
Тут всё проще, приложение просто не в тунеле. То есть если приложение не в тунели, будет отдан мой настоящий ip, а если в тунели то…? IP vps, но приложение и так через VPS идёт.

Единственное сценарий как можно спалить реальный ip VPS это если только некоторые домены проксируется через CF, а другой домен - нет. На ПК это проблемма неактуальна. Приложение видит прокси на localhost, но ip он выдаёт реальный, а не VPS.

Ну а реальный IP vps будет скрыт в итоге. Если за каждым будут приходить космонавты с волшебными палочками, то это нанесёт общего ущерба в сотни раз больше, чем просто этого не делать. Да и не забываем про WS, gRPC и другое

Не могу проверить, на моём пикселе при попытки открытия Termux в private space, появляется ошибка “Unable to install bootstrap. Termux can only be run as the primary user.”