Leak between private space and per-app split tunneling

[ski0x0]

Leak between private space and per-app split tunneling

The government has ordered Russian tech companies to spy on users and detect VPNs. Yandex discovered and is actively exploiting this vulnerability. This vulnerability puts all private servers of users at risk, potentially ending up on a blacklist.

More information here https://github.com/runetfreedom/per-app-split-bypass-poc

Almost all mobile clients based on xray/sing-box run a local socks5 proxy without authentication.

At the same time, per-app split tunneling is implemented using VpnService, which redirects traffic to tun2socks (or something similar). But if there is spyware on the user's device (for example, as part of a government application), nothing prevents it from connecting directly to this socks5 proxy, bypassing VpnService, and discovering the user's external IP address.

[neur0ner25]

+1

[Fa1ry7a1l]

[itsTPM]

I see two solutions that may work:

1. Disable the local SOCKS proxy entirely - sing-box does not require a proxy for the tun inbound.
2. Require authorization for the proxy - either with auth data generated by the app or set by the user.

With either option, we may enforce this behavior entirely or give a toggle to the user. I think we should prefer the behavior that prevents leaking by default but give a toggle to the user if they know what they are doing.

[nyan-ame]

+1

[maxi08pa]

+!!!

[priZrak7495]

+1

[sou1jacker]

At present, this issue is resolved by a simple routing rule, which blocks all traffic destined for the SOCKS proxy.

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

[priZrak7495]

At present, this issue is resolved by a simple routing rule, which blocks all traffic destined for the SOCKS proxy.

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

Where should this be written?

[sou1jacker]

At present, this issue is resolved by a simple routing rule, which blocks all traffic destined for the SOCKS proxy.
{
"inbound": ["mixed-in", "socks-in"],
"outbound": "block"
}

Where should this be written?

Routes - Create new - Custom configuration
RU: Маршруты - Создать новый - Пользовательская конфигурация

[YegorKehl]

At present, this issue is resolved by a simple routing rule, which blocks all traffic destined for the SOCKS proxy.

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

Thanks, this prevents leakage of outbound IP, but doesn't prevent observing of VPN app presence on device. For example Yandex.Market app still see and warning about this.

[sou1jacker]

It’s impossible to hide the fact that you’re using a VPN without root access. And in my opinion, there’s no need to anyway.
The main thing is that the IP address of the exit node isn’t leaked (when using per-app split tunnelling)

Incidentally, there are a few issues with this on xray kernels. I had to create a fork to patch this vulnerability.

[YegorKehl]

It’s impossible to hide the fact that you’re using a VPN without root access.

Is there no other way to implement per-app split tunneling on non-rooted devices other than through the tap2socks?

And in my opinion, there’s no need to anyway.

We'll see in a month or two when Russian apps stop allowing users to access their services with the socks5 port detected on the device.

[sou1jacker]

It’s impossible to hide the fact that you’re using a VPN without root access.

Is there no other way to implement per-app split tunneling on non-rooted devices other than through the tap2socks?

And in my opinion, there’s no need to anyway.

We'll see in a month or two when Russian apps stop allowing users to access their services with the socks5 port detected on the device.

The problem isn’t even the proxy, which can be disabled, but the interface detection (tun0, wg0, etc.), which cannot be hidden without root access.
As a temporary solution, you could use a "system clone" (essentially creating another system with its own apps) on BBK smartphones (Oppo, 1+, Realme, Vivo).

It’s also worth remembering that many companies use legitimate VPNs to access their remote resources. So the scenario you’ve described seems unfeasible.
Even if Im wrong and such apps do appear, they can always be patched.

[Samamy]

I think find another "fix".

• NekoBox > Settings > Service Mode > VPN
• NekoBox > Settings > Apps VPN mode - Disable
• The order of the rules is very important; the higher up a rule is, the sooner it applies!!!
• NekoBox > Route > Create Route > Name "proxy", Chose application, Outbound - "proxy"
• NekoBox > Route > Create Route > Name "direct", Chose application, Outbound - "bypass"
• Android, in system menu > Setting > Network and Internet(for me) > VPN > NekoBox > Configure > enable "Always-on VPN", enable "Block connection without VPN"
• Now all connection, access via NekoBox, add application to Route "direct" if need direct access
• Add application to Route "proxy" if need use proxy profile

Думаю нашел еще одно решение.

• NekoBox > Настройки > Сервисный режим > VPN
• NekoBox > Настройки > Режим VPN для приложений - Выключить
• Последовательность правил очень важна, чем выше, тем раньше оно применяется !!!
• NekoBox > Маршруты > Создать Маршруты > Имя "proxy", Выбрать приложения, Outbound - "Прокси"
• NekoBox > Маршруты > Создать Маршруты > Имя "direct", Выбрать приложения, Оutbound - "Обход"
• Android системе > Настройки > Мобильная сеть(у меня) > VPN > NekoBox > Настройки > Включить "Постоянная VPN сеть", включить "Блокировать соединения без VPN"
• Теперь все соединения в сеть управляются через NekoBox, добавляя в правило "direct" приложения ходят напрямую.
• Добавляя приложение в правило "proxy" будет ходить через vpn/proxy
  Еще раз повторю последовательность правил важна, чем оно выше тем раньше применяется !