Android NAT-T keepalive offload bypasses VPN lockdown (supuk.ch)
180 points by mhitza a day ago
jeroenhd 8 hours ago
> FortiClient VPN and SmartVPN have 4,134,648 cumulative Google Play installs between them, while Google reports more than 3 billion active Android devices.
A very strange way to reason about killing an API instead of fixing the VPN issue (as someone from Google already suggested they're planning on doing). "Only 4 million people use this, we should kill it" is exactly the kind of reasoning Microsoft in the 2000s would use to kill the ability to install Linux on a PC.
ValdikSS 7 hours ago
Android has a way to bind the socket to the interface: Network.bindSocket, this is a setsockopt(SO_BINDTODEVICE) wrapper with access control.
The access to it is controlled by the VPN application. Some applications could be allowed to connect directly when the VPN is active and routing all the traffic by default, some could use VPN if configured not to use it by default.
However starting with Linux kernel 5.7, the unprivileged userspace can now call setsockopt(SO_BINDTODEVICE) directly and use VPN or non-VPN interface even if restricted by the VPN client.
Not fixed in any Android (incl. Graphene, which has fixes for other leaks, but not this) to the day.
PoC is as simple as "curl --interface [ifname, not IP] ifconfig.co" in termux.
brinepot 17 hours ago
'Closed without action' is the tell. A leak that Google knows about and leaves in place isn't a bug anymore, it's a feature they're comfortable with.
grapheneos 13 hours ago
Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.
exceptione 13 hours ago
I am not sure why all your comments are flagged, but here is my response to your other comment:
> We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.
grapheneos 12 hours ago
exceptione 19 hours ago
This paper goes into much more detail: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass
codedokode 9 hours ago
The stupid thing about Android is that it requires you to set a PIN to use Always-on VPN which is necessary for traffic filtering (as Android doesn't provide access to nft).
jeroenhd 8 hours ago
That seems like a good trick to me if you want to prevent people from installing spyware without any obvious signs.
You can almost hide the warnings (there's one small notification in the bottom of the notification tray you can't disable) and on some phones even the VPN icon, but you can't hide the new lock screen code your victim suddenly needs to enter to use their phone.
It used to be that Android showed random popups and notifications about identified security risks, which were awfully annoying if you have a private CA certificate installed. Luckily Google got rid of those.
In my experience, you can also set up biometrics on basically every phone, and Google has a few "don't lock the phone while it's with you in your pocket" like services you can optionally enable as well. Your backup PIN doesn't have to be four numbers, you can put a whole passphrase in there if you want it to be secure.
You could also do facial unlock. Less secure than Apple's implementation but more than good enough if you didn't have any lock screen set before that.
cute_boi an hour ago
The issue with many people like me like to use tailscale, so they should probably think about giving too many warning.
driverdan 8 hours ago
Why wouldn't you set a PIN?
LoganDark 16 minutes ago
I already have a very long password. I object to unnecessary extra layers -- you can rely on secure hardware via the system if you must authenticate me again, but do not pretend to become your own steward.
Most of my apps that decide to ask for their own PIN (e.g. Klarna, Privacy.com, myFICO) have some deterministic garbage that's easy to guess because they provide no real security. I refuse to entertain security theater with real secrets. (real secrets = ones I don't remember)
codedokode 8 hours ago
What's the point of setting a PIN if Cellebrite can hack almost any phone?
unethical_ban 8 hours ago
exceptione 20 hours ago
> A proper fix would require changes in the Android system. The researcher who discovered the leak has reported the issue to the Android Vulnerability Reward Program, but according to the researcher the issue was closed without action. This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.
grapheneos 14 hours ago
Security issues considered outside the scope of what they consider a security vulnerability are closed regardless of what they plan to do about the issue. Google primarily uses internal issues to track issues with Android. Public issues and security issues filed by external parties are only used to communicate externally and an internal issue is created for their actual issue tracking.
A security issue being closed means you aren't getting a bounty and it won't be fixed for existing Android releases. It doesn't mean it won't be fixed in a future Android release. They do track VPN leaks as issues internally and regularly ship fixes in new major releases. They unfortunately don't consider those security issues so they don't get prioritized. If they were considered security issues, then they'd likely consider them Low or Moderate severity which means those wouldn't be backported.
Only a large subset of patches for High and Critical severity issues are backported to older releases of Android. Low and Moderate severity issues stopped having patches backported years ago due to volume. High and Critical severity patch backporting is now being scaled down too due to AI accelerated vulnerability discovery. You need the latest yearly or QPR2 release to get full updates.
GrapheneOS has had to fix a bunch of VPN leak issues and we're in the process of fixing more of the issues. We plan to heavily overhaul the VPN implementation to make most forms of leaks nearly impossible rather than continuing to use the current system prone to it.
jjav 19 hours ago
> we cannot rule out that Google deliberately introduced or wanted to keep the leak in place
I'd say a lot stronger than "cannot rule out". Regardless of how it was introduced, if it is now known and the issue was closed without action, they are actively choosing to keep it.
grapheneos 14 hours ago
Google considers VPN leaks to be valid bugs but unfortunately doesn't consider them security bugs. Internal issues are created for any issue report considered valid. The external one is only used to communicate with people. If it was filed as a security bug, they'll close it if it isn't considered within the scope of the bounty program.
gib444 18 hours ago
The GrapheneOS team did not respond to an email report either [0]. Does that mean we can draw similar conclusions from the GrapheneOS team? I don't think that would be fair or correct, so why assume malice from Google just based on the (lack of) response to the report?
N.B. I don't disagree there is a possibility of foul play on Google's part, but I think more evidence / better argument is required.
[0] https://github.com/GrapheneOS/os-issue-tracker/issues/8617#i...
exceptione 17 hours ago
GOS explicitly stated that they work on a fix, also for other issues and they keep this on their radar.
Google just closed the ticket, without communicating their plan to deal with it. I just stated that we cannot rule out a possibility of foul play, thereby keeping other options open. Keeping that thing in mind which is better known as "the reality" I would be a little bit more wary about Google's stance towards privacy than I would be about GOS though. The difference in how these parties are handling this issue is already a tell.
nvme0n1p1 17 hours ago
There's a big difference between "the issue was closed" and "received no acknowledgment". The former is a deliberate action. The latter could be a case of SMTP-ate-my-email.
grapheneos 13 hours ago
gib444 16 hours ago
nonamesleft 19 hours ago
As a quick kludge use an USB-C wlan network adapter that lacks the functionality for this type of connection (albeit that won't help you with a cellular connection)?
exceptione 19 hours ago
Regarding cellular connection, the proof of concept presented here only works on wifi: https://github.com/GrapheneOS/os-issue-tracker/issues/8617
I have a hunch this leak is bound to wifi hardware only, for details: https://supuk.ch/papers/android-natt-keepalive-vpn-bypass
aucisson_masque a day ago
> This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are working on a fix.
Good guy Google, as usual.
grapheneos 13 hours ago
dingdong2026 5 hours ago
Just another data point proving what we already know:
Google is Evil.
You might as well use Meta or Microsoft products. Or Phillip Morris. Blame yourself for the fallout.
potatoproduct 17 hours ago
Surprised this hasn't blown up more!
TutleCpt 17 hours ago
Mullvad did a really good job writing up this blog post. And yet again GrapheneOS to the rescue.
gib444 18 hours ago
I guess the best advice remains to only use wifi to connect to a router which forces traffic over a VPN and never use mobile data?
Do any similar leaks exists on iOS currently?
gib444 15 hours ago
GrapheneOS is affected too. They've been aware since at least 29th July and are working on a fix, no ETA.
GOS say security issues are high priority.
There is no update the GitHub issue for 2 weeks except for deleting a comment by the reporter yesterday.
GOS developers have been busy working on a Messages rewrite and that got released in alpha yesterday.
innocent_name 9 hours ago
>There is no update the GitHub issue for 2 weeks except for deleting a comment by the reporter yesterday.
Yeah, i was very confused by that, especially after they invited them to post publicly/privately. They love controlling the public communications when it comes to researchers. I remember ryrona, a guy who found VPN leaks, being censored for no reason whatsoever in their public GitHub issue tracker.
tosti 17 hours ago
You're definately not hiding something if all your traffic goes out to a single IP address and a single pair of source and destination ports.
gib444 16 hours ago
A business: hiding everything is expected. To do otherwise is negligence
An individual: you're a pedo if you use a VPN
Give over.
folienumero 5 hours ago
What an useless comment, you have no idea about privacy or security don't you?
tosti 14 hours ago
Most people I know use a VPN do it to bypass geo restrictions and/or get a discount with cheaper currencies. (But hey, our "representatives" seem to disagree.)