Обновить

Критическая уязвимость VLESS клиентов? Подержите мое пиво…

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели19K
Всего голосов 79: ↑78 и ↓1+94
Комментарии77

Комментарии 77

а что если в виртуалку спрятать не скам / яндекс / госуслуги, а наоборот все нужные приложения? это не поможет?

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

P.S. впрочем он сам написал что бухой, так что простительно :-)

походу создателям андроида и шелтера и в страшном сне не снилось, что кому-то нужно будет целенаправленно на своем устройстве запускать спайваре работать с ней и пытаться от нее-же защитится.

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

М.б. внешние поведенческие, через счетчики аналитик завязанных на идентификации, вроде Я.Метрика?

Вот да. Тоже кажется начнут на страницах стучать на заграничные сервера и сверять ip.

Там уже не кажется, там либо уже начали либо вот вот начнут, проблем то минимум, добавить java скипт который будет делать запрос к любому узлу из этих:
https://api.ipify.org?format=json

https://ipinfo.io/json

https://api.ipapi.co/json

либо свой собственный аналог на зарубежном vps поднимут и сохранять данные на сервере что-то типа (по токенам грока):

В firefox на этот случай есть (в остальных браузерах понятия не имею есть ли аналоги):

Нужные странички в "личное", спайваре в "покупки" или куда пожелаете и пускай стучатся

Яндекс фингерпринты при случае делает, собирая данные вплоть до названий Wi-Fi сетей (BSSID) и гео. Прокси не спасут, если отпечаток уплыл через Яндекс.Браузер или скрипты Яндекс приложений. Идентификация идет через склейку сессий с Яндекс айди (Canvas, WebGL, шрифты и+100500 условных параметров).

тем кто пользуется яндекс браузером по моему скромному мнению внп вообще противопоказан. Кстати подозреваю что им как раз хорошо зайдет и мессенджер "телега"

Я.Бразуер это часто один рабочий метод выхода для пожилых людей на стареньких устройствах, посмотреть тот же ютуб. Даже выкиним Я.Браузер, есть Я.Гоу, например и еще кучу сервисов от Яндекса, которые тупо висят в телефоне.

я извиняюсь, но то что я писал выше не про телефон, а про компьютер, на телефоне все сложнее там чтобы использовать прокси (не впн) нужно даже не firefox ставить, а его версию firefox nightly (хорошо хоть от самих же разработчиков firefox).

Можно прокси запускать только для контейнера

CORS не даст. Запрос-то они сделают, а вот ответ им прочитать браузер не даст.

Делаешь сервер за бугром с правильными политиками CORS и принимаешь соединения от сайтов...

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

Но зачем нам ещё один vpn-клиент? Могли бы вы сделать форк, например, Nekobox без socks? А в идеале чтобы он ещё мог использовать плагин Naiive без открытого +одного порта socks?

А там может вы бы влили эту функциональность в основную ветку.

Мог бы)

Тогда могли бы вы, пожалуйста, однажды сделать, это хорошее дело для тысяч признательных пользователей?

открывай сбор, накидает тебе донатов)

Для Nekobox уже предложили трюк для блокировки запросов по socks5, надо добавить кастомное правило в Маршруты:

{
  "inbound": ["mixed-in", "socks-in"],
  "outbound": "block"
}

Да, это рабочий вариант, но там есть ещё конфигурация, закрывающая tun0.

Только, как оказалось, плагин Naiive (если используется) добавляет дополнительный открытый socks5, он уже не прикрывается.

Тут интересный вопрос родился. Какие DNS будут использоваться для резолвинга приложениями, которые ходят через VPN?

Зависит от настроек tun в клиенте и конфигурации xray/sing-box.

Непонятно причём тут конфигурация sing-box. Вроде автор его не включал никак

Богатый выбор как udp, так doh/dot, так и можно указать свой. Так же, есть возможность использовать dns запросы напрямую/через впн

я вообще мало понимаю в подобном и потому решил спросить тут. вот я пользовался обновленным и (на телефоне) Happ и каринг и этой прогой с этой статьи, но... хз на счет других прог но вот чтобы я не делал приложение личный кабинет мегафон всегда просит отключить ВПН. получает оно видит что ВПН включен и значит ТЕМА не работает так?

Основной посыл в том, что vpn имеет кучу косвенных признаков на android. Главная проблема - утечка вашего внешнего ip. Вы можете добавить приложение в исключения впн клиента, но оно все равно может задетектить внешний ip - клиент в статье борется именно с этим.

сам андроид устроен так что при включении любого стороннего сетевого интерфейса появляется значек - VPN. Насколько я в курсе это не поборимо без доступа к ядру (т.е. рута).
Альтернатива - использовать прокси т.е. 127.0.0.1:XXXX это в системе не светится, но приложения и веб странички с помощью JS могут определить его наличие и соответственно куда он ведет.

Если кому интересно насчет настроек браузера firefox, мультиконтейнера с раздельным прокси и перекрытия доступа js со страничек открытых в напрямую (без контейнера с настроенным прокси) к сканированию прокси сервисов, пишите расскажу.

очень интересно, если оно на андроиде работает

А можете сделать в приложении чтобы выбирать: либо кто через vpn, либо кто напрямую. А то сейчас долго выбирать кто напрямую;)

Да, уже поступил такой запрос - в ближайших планах)

как думаете, какие еще неочевидные маркеры наличия VPN могут начать массово использовать для детекта в ближайшем будущем?

Так ведь давно уже же используют обратный пинг для этого. Приложение пингует определенный хост и засекает время ответа. Хост пингует выходной IP квн приложения и сообщает ему время ответа. На разнице этих времен весь кордебалет и палится

я как не великий специалист в этой области ничего не понял, можно подробнее?

На 2ip.ru зайдите при включенном квн и проверьте наличие туннеля. Вкратце, приложение, скажем озон, пингует хост где-то за рубежом. Пинг идет через ваш квн сервер, и это долго. Потом тот хост пингует адрес, который его пинговал (ваш квн за рубежом), и это быстро (внезапно!). Вот и все, сижу на амнезии премиум и у них на выходной ноде не отключен ICMP. Такая беда...

один через впн, второй мимо:

ну и с наличием разницы во времени даже не знаю что делать

У меня так
У меня так

Допустим, все друг друга попинговали. Как склеить эти события? На основании какого ключа?

А как побороли возможность любому приложению отправить запрос через tun? Например,

curl https://chatgpt.com/cdn‑cgi/trace ‑interface tun0

что выдает?

лол! Нафига? Есть специальные сервисы для этого, а если надо его несложно сделать самому подняв впс в нидерланда с nginx или caddy который будет возвращать json с данными о твоем конечном адресе, браузере, операционной системе и твое локальное время.
Ну типа стандартного - https://ipinfo.io/json

Смысл в том, чтобы приложение не могло отправить запрос в туннель, а отправляла бы его через обычный интернет

а, ну для этого мы используем раздельное маршрутизирование для приложений, это решает проблему с тоннелем, но остается открытой проблема с socks5 прокси на локалхосте, которую как раз пытается решить автор этой статьи.


P.S. Мое лол-нафига относилось к этой части вашего комментария -
curl https://chatgpt.com/cdn‑cgi/trace ‑interface tun0
для определения обхода блокировок проще использовать так -
curl https://ipinfo.io/json ‑interface tun0

  1. В этом-то и проблема, что маршрутизация для приложений в большинстве клиентов для vless не работает. Точнее не работает фильтрация "разрешенных приложений".

  2. Сайты типа ipinfo - уж больно явно являются сервисами проверки. Кажется, что такие известные домены можно заблокировать в приложении. Но вот пример с chatgpt на самом деле иллюстрирует гораздо бОльшую проблему: все домены работающие через cloudflare имеют у себя эндпоинт /cdn-cgi/trace а их не заблокировать без блокировки домена. Да и утопия это - писать правила для блокировки всех доменов работающих через cloudflare

https://chatgpt.com/cdn‑cgi/trace

Нафига? Есть специальные сервисы для этого

О, нет, это наоборот прекрасно. Я оценил трюк. Клиент может использовать политику:

1. «По этому короткому списку в туннель».

2. «Все остальное напрямую».

В тоже время сервер может иметь политику:

1. «По этому короткому списку выпустить в интернет».

2. «Все остальное заблокировать».

И тогда твой сервис который ты любовно поместил в свой список начинает на тебя стучать. Даже при такой жесткой политике

хм... а в этом что-то есть )))

Android без рут прав у приложения не дает биндить сокет в туннель, если приложение находится в списке исключений. Binding socket to network 207 failed: EPERM (Operation not permitted).

Ну вот на обычных клиентах, типа v2rayNG, из termux (если он даже не в списке проксируемых) получается, что вполне себе запрос отправляется легко.

Или имеется в виду, что надо делать типа "черный список" - то есть исключать приложения из прокси? Ну тогда получается весь служебный трафик будет через vps идти. Зачем? Имхо проще же заворачивать через прокси отдельные приложения, а по умолчанию все пускать напрямую, нет?

Как раз добавил "обратный" список

Протестировал - к сожалению, такая же штука, как и у большинства клиентов: выбор приложения для прохода через прокси не запрещает другим слать через tun0 запросы

Ip и регион - внешняя нода прокси.
Ip и регион - внешняя нода прокси.

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

Вообще, работающую блокировку по приложению я только у flclash нашел. Но там конфиги все переписывать надо

к обратному списку стоит поменять красный перечеркнутый кружок на значке приложения на что-то другое. (v 1.0.5)

Сожалею, это сообщение и ветка ниже

а если я "настоящий" виндовз накачу на смартфон, это поможет ? видел, были такие "хакнутые" устройства или выйду через второй смартфон и с него буду раздавать трафик ?

А можно добавить параметр, чтобы по умолчанию всё шло мимо впн, а то что надо пустить в впн, самому отметить?) А то сиди выбирай кучку программ которым не надо впн, вдруг чтото пропустим

А, всё, нашел галочку, извините. А не, не работает, вот что выдает:

Start failed: addAllowedApplicationalready called

Спасибо за оперативность в устранении багов)

Я не силен в мобильной разработке. Но скормил Ваш клиент чатужпт, чтобы провести аудит. Вот его ответ:

  • Конфиги с секретами сохраняются в plaintext в SharedPreferences. В сериализацию попадают uuid, password, publicKey, shortId и даже rawUri, то есть фактически полный импортированный URI. Подписки тоже сохраняют URL целиком. См. /tmp/ teapod‑stream/lib/core/models/vpn_config.dart:99, /tmp/teapod‑stream/lib/core/models/vpn_config.dart:120, /tmp/teapod‑ stream/lib/core/models/vpn_config.dart:122, /tmp/teapod‑stream/lib/core/services/config_storage_service.dart:64, /tmp/ teapod‑stream/lib/core/services/config_storage_service.dart:117, /tmp/teapod‑stream/lib/core/services/ config_storage_service.dart:121.

  • Поверх этого в AndroidManifest не отключён backup/export rules. Там нет ни android:allowBackup=«false», ни явных dataExtractionRules. Для обычного пользователя это не мгновенная межприложная утечка, но для high‑risk сценария это плохая гигиена хранения секретов. См. /tmp/teapod‑stream/android/app/src/main/AndroidManifest.xml:11.

  • Клиент действительно генерирует случайные SOCKS‑логин/пароль и порт, это хороший ход. Но затем сервис логирует полный запуск tun2socks, включая строку вида socks5://user:password@127.0.0.1:port, в logcat. То есть секреты, которые только что защитили localhost‑прокси, тут же утекли в системный лог. См. /tmp/teapod‑stream/lib/providers/vpn_provider.dart: 96, /tmp/teapod‑stream/lib/providers/vpn_provider.dart:103, /tmp/teapod‑stream/lib/protocols/xray/xray_config_builder.dart:20, /tmp/teapod‑stream/android/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:234, /tmp/te apod‑stream/android/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:249, /tmp/teapod‑stream/andro id/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:430.

  • README обещает больше, чем реально реализовано. Заявлены Trojan, Shadowsocks, H2, QUIC, но builder по факту собирает полноценные outbound‑настройки только для VLESS и VMess; для остальных протоколов возвращается пустой settings‑блок, а supportsConfig() всё равно отвечает true. Это не прямая уязвимость, но плохой сигнал по зрелости и может дать ложное ощущение «всё поддерживается». См. /tmp/teapod‑stream/README.md:7, /tmp/teapod‑stream/README.md:8, /tmp/teapod‑stream/ lib/protocols/xray/xray_config_builder.dart:124, /tmp/teapod‑stream/lib/protocols/xray/xray_config_builder.dart:150, / tmp/teapod‑stream/lib/protocols/xray/xray_engine.dart:230.

Допускаю, что ИИ мог нафантазировать. И свою безграмотность в этом вопросе тоже беру в расчет. Но если я правильно понял - Вы сами несколько раз в открытом виде кладете секреты

android:allowBackup - Чего плохого в возможности бэкапа пользователем? "Но затем сервис логирует полный запуск tun2socks" - кто имеет доступ к логам? Пользователь?

Не совсем понимаю претензии к автору. Он честно признался, что за пару дней подпивасно накодил прогу в качестве proof of concept. Он не позиционировал её как самое защищённое решение на свете, а просто показал, что исправление так сильно всех напугавшей уязвимости, в целом, несложное.

Давайте и за меня ответит ИИ.

Вот краткое резюме по каждому пункту:

  1. Открытые конфиги (SharedPreferences): Не страшно. Защищено встроенной изоляцией Android. Без root-прав (взлома системы) другие приложения до этих файлов не доберутся.

  2. Резервное копирование (Backup rules): Не критично. Конфиги просто сохраняются в ваш бэкап на Google Drive или доступны через USB-кабель. Если телефон запаролен и аккаунт защищен — угрозы нет.

  3. Пароли в логах (Logcat): Не опасно. Утекли пароли от локального узла (внутри самого телефона). Из интернета к нему не подключиться, а Android запрещает обычным приложениям читать системный лог.

  4. Заглушки вместо протоколов: Это не уязвимость. Разработчик просто не дописал код для Trojan и Shadowsocks, хотя пообещал их в описании.

Общий вывод: Для личного использования это безопасно. Это проблемы "чистоты" кода, а не реальные дыры, через которые ваш телефон могут взломать извне.

Вот оно будущее разработки - одна llm беседует с другой llm через людей! :-)

Расскажите, а зачем вы это сделали? Вы считаете что автор не смог этого сделать сам?

Отдельный айфон для адекватной жизни в неадекватной стране уже готов. Наивысшая сейчас мера - изоляция "плохих" и "хороших" приложений друг от друга на уровне физического устройства.

С iPhone по очевидным причинам проверить не могу. А есть ли возможность ограничивать некоторые приложения доступом только к некоторому сегменту сети (все ру идут в ру или идут нафиг)?

AmneziaWG лишена этой уязвимости?

curl --interface tun0 whatismyip.akamai.com

показывает выходной IP прокси даже если приложение из проксируемых исключено. Увы, но ваш клиент тоже уязвим на Android с ядром 5.7+. В Exclave уже починили и можно tun защитить правилами, а socks вообще отключить.

Есть версии андроида, в которой это уже починили? И сразу вопрос вдогонку - на Linux можно определить PID процесса, открывшего сокет, но с рутовыми привилегиями. На андроиде без рута это тоже не решается?

У меня детекти все-равно) Tun виден

А без сборки как нибудь выложить можно? В виде apk для чайников.

Уже вторая неделя статей про всякие утечки, методички, RKNHardering, кто-то там что-то тестирует. А хоть кто-нибудь делал хоть малейший аудит RKNHardering? Автору на гитхабе без году неделя отроду и все тупо ставят это приложение. Откуда вообще такое доверие? Почему вы решили, что это приложение просто не собирает определённую информацию? Кстати тоже самое относится и к TeapodStream. ))

Доверяй, но проверяй) TeapodStream - исходники открытые, я скачал и прогнал через Клод для скорости + вручную посмотрел методы. Идея то до безобразия простая и потому рабочая)

как думаете, какие еще неочевидные маркеры наличия VPN могут начать массово использовать для детекта в ближайшем будущем?

Например, пользователь цитирует "запрещенные" источники, недоступные без VPN. И вообще какой-то слишком умный.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации