Месссенджер МАХ и VPN

Определяют только утечками в маршрутизации. Статус “VPN” в системе – даёт 0 информации. Никакое приложение не жалуется на это из тех что жаловались до этого (были утечки).

VPN интерфейс может подняться после первого запроса со стороны приложения. То есть запрос может пойти предыдущим туннелем, особенно если приложение уже было разогрето в фоне.

Простой пример: ChatGPT у меня при запуске сразу же жаловолось на РФ IP ещё до того как туннель успел подняться.

Уязвимость к утечке.

Поэтому я и говорю, костылями это не решить.

Определяют только утечками в маршрутизации.

Да кто ж знает этих дегенератов, может они сделают так что будет достаточно самого факта туннеля или даже просто наличия Happ, v2raytun, Clashmeta или аналогиных приложений.

Поэтому я и говорю, костылями это не решить.

Это понятно, что это костыли и утечки возможны, просто во-первых многие вообще не в курсе про такой функционал в иос, во-вторых данный метод с автоматизацией это скорее про скрытие самого статуса системного флага VPN от посторонних приложений. В фоне приложения спят, а когда они активны статус VPN будет всегда OFF.

В ios они не не могут видеть списки установленных приложений. Но сам факт статуса VPN может быть использован да, особенно в совокупности другими метриками (напр. датацентровый ip клиента, даже если российский ДЦ)

Да, ты прав, шорткаты отрабатывают с задержкой - чатгпт успевает понять, что он в россии, до поднятия туннеля. Это неприятно, но важнее скорее тушить тоннель при закрытии приложения. То есть ты сворачиваешь чатгпт, тоннель тушится с задержкой около 0.5 сек, скорее всего к моменту когда ты физически успеешь нажать на что-то еще он уже будет потушен, и другие приложения не увидят статус VPN.

Вроде бы разобрался. Хотел написать в соседнюю тему про уязвимости, но её неожиданно закрыли.

Для NekoBox for android сделал такие конфиги и вставил их в конкретные профили а не в общие настройки:

карандаш на профиле => три точки => Пользовательская конфигурация JSON:

  1. Вариант без tun0 (без VPN, proxy only)
{
"inbounds": [
{
"type": "mixed",
"tag": "mixed-in",
"listen": "127.0.0.1",
"listen_port": 8010,
"sniff": true,
"sniff_override_destination": false,
"domain_strategy": "",
"users": [
{
"username": "ВАШ ЛОГИН",
"password": "ВАШ ПАРОЛЬ"
}
]
}
]
}


  1. Вариант tun(vpn) + proxy:
{
"inbounds": [
{
"domain_strategy": "",
"endpoint_independent_nat": true,
"inet4_address": [
"172.19.0.1/28"
],
"inet6_address": [
"fdfe:dcba:9876::1/126"
],
"mtu": 9000,
"sniff": true,
"sniff_override_destination": false,
"stack": "gvisor",
"tag": "tun-in",
"type": "tun"
},
{
"type": "mixed",
"tag": "mixed-in",
"listen": "127.0.0.1",
"listen_port": 8010,
"sniff": true,
"sniff_override_destination": false,
"domain_strategy": "",
"users": [
{
"username": "ВАШ ЛОГИН",
"password": "ВАШ ПАРОЛЬ"
}
]
}
]
}

В фаерфоксе есть настройки SOCKS5 proxy и в других хороших приложениях. Но в некоторых приложениях этого нет к сожалению.

Кто знает, этот вариант имеет какие-то уязвимости?

P.S. Все эти настройки используются исключительно для противодействия вредоносным приложениям используемым злоумышленниками. Ни в коем случае не призываю к обходу блокировок к законно заблокированных ресурсам.

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

Аутентификация в SOCKS делается в незашифрованном виде, пользователь и пароль видны при перехвате.

И запрос на подключение к SOKS5 как я понял может перехватить шпионское ПО? Прямо внутри устройства?

Короче если резюмировать - то нужно рутировать устройства и всё жёстко блокировать. + Песочницы (виртуалки) или проще другое устройство использовать.? Как то так я понял.

А если наоборот - прокси вообще вырубить? :

{
“inbounds”: [
{
“domain_strategy”: “”,
“endpoint_independent_nat”: true,
“inet4_address”: [
“172.19.0.1/28”
],
“inet6_address”: [
“fdfe:dcba:9876::1/126”
],
“mtu”: 9000,
“sniff”: true,
“sniff_override_destination”: false,
“stack”: “gvisor”,
“tag”: “tun-in”,
“type”: “tun”
}
]
}

(Этот конфиг уже стоит в глобальные настройки добавить , если прокси точно не нужен)

Но тогда уж точно рутировать придётся.

Надеюсь, конечно, что пока такие закладки по перехвату SOKS5 упыри не внедрили.

Читаю, что после скандала на этой неделе HAPP обещает добавить логин-пароль для прокси.

Добрый день, Limping. Поправил конфиг для отключения proxy. А по поводу SOCKS

вот же был ответ:

Вот что ответил BB:

Да, локально перехватить авторизацию SOCKS5 можно, так как данные (логин и пароль) в этом протоколе передаются в открытом виде (plain text) внутри TCP-пакетов. Тот факт, что и клиент, и сервер находятся на одном устройстве (localhost), не является препятствием для перехвата, но требует использования специфических инструментов для прослушивания внутреннего интерфейса (loopback)

Процентов на 95 Одичалые пока не ввели такой механизм перехвата. Но возможно введут когда-то. В любом случае наличие пароля лучше его отсутствия.

Буду думать об установлении ограничений доступа к интерфейсу Loopback

Понятно, что он plaintext. Но чтобы его перехватить, вам нужно дампать трафик между клиентом и сервером. В случае сервера на loopback, без привилегий root это как-то невозможно сделать.

Специфические инструменты - это socket bind? Его и так можно делать, но отобрать используемый порт не получится.

Если только намеренно ловить момент, когда он будет свободен, занимать его, дожидаться старта сессии клиента, перехватывать пароль, освобождать сокет и так далее. Выглядит слишком уж сложно и ненадёжно, чтобы такое делать.