DNS traffic can leak outside the VPN tunnel on Android

https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the-vpn-tunnel-on-android

by ementally • 2 years ago

835 342 2 years ago

I don't use Mullvad, but I respect the shit out of them. This is a good, information dense explanation of the problem, their short term workaround and potential workarounds for others, as well as what will need to be fixed in Android. Good stuff.

pqdbr• 2 years ago

Blog posts like this (instead of endless YouTube sponsorships like their competitors do) are what made me choose them as my VPN service.

bloopernova• 2 years ago

I use and recommend Mullvad.

However I'm worried that their goodwill and values will become more valuable to some private equity corp that buys them to asset strip and squeeze their customers.

2OEH8eoCRo0• 2 years ago

I was an extremely happy user until they removed port-forwarding. That forced me to switch unfortunately :(

uneekname• 2 years ago

I was a bit surprised to walk onto a DC Metro car last weekend to find the walls plastered with ads for Mullvad. Just wanted to note that Mullvad is spending money on traditional advertising, as well as blog posts like this.

sli• 2 years ago

They don't do YouTube sponsors but they sure plastered their ads all over Chicago. Literally everywhere.

dkga• 2 years ago

Good points. By the way, how do they compare with the likes of ProtonVPN?

rmdes• 2 years ago

Simply the best VPN around, in terms of values, mindset, loyalty to their core beliefs and the relentless proof to stick to their moto over the last decades.

stoniejohnson3• 2 years ago

only bummer is that due to their strong respect of user anonymity a lot of their IPs are blocked by major platforms like Reddit

spxneo5• 2 years ago

how are platforms like reddit able to get complete list of mullvad IPs and other vpns but not residential proxies?

EA-31672• 2 years ago

I use Mullvad and Reddit has never tried to block me, in fact I've run into no blocks at all. Then again my browsing habits are quite boring.

colordrops• 2 years ago

What VPN do you use, if any?

godelski• 2 years ago

If you don't use a VPN I'll note that they have a DNS service that is free. I think this demonstrates some support, at least in the way that increased traffic/usage can be support (and should help make Mullvad VPN users stand out less WRT DNS requests). The only downside I'll say is that the ping time for me is quite a bit higher than quad9 or cloudflare.

I wrote some info about it in this thread[0], including how you can do ad blocking at the DNS level (and cloudflare info for the same).

[0] https://news.ycombinator.com/item?id=40056162

bjoli• 2 years ago

I AM a user of mullvad, and I am extremely satisfied. I once mailed support with a payment question and added a small iptables question regarding a problem I had.

I got back a swift reply which solved the payment question, and a detailed iptables reply with pros and cons of different solutions.

In short: they are great.

gregoryl• 2 years ago

That's unfortunate, they only recently rolled out prompts to push Android users away from their in-app always-on functionality to the built in version.

tiagod• 2 years ago

I guess the safest setup is to have mobile data off on your phone and carry an OpenWRT hotspot to do the VPN bit upstream from the phone.

nickburns28• 2 years ago

it's true.

even bigger nightmare on iOS where 'always-on VPN' can only be configured on devices 'supervised' by an Apple-approved (documented application and telephone call with current employee required) organization's MDM solution—or you otherwise need a Mac to use the Apple Configurator app to even create a Configuration Profile containing the 'always-on VPN' key.

fullspectrumdev2• 2 years ago

Making a simple OSS tool to generate valid configuration profile files seems like a potentially useful way to spend a weekend sometime.

The format cannot be that complex, right?

brobinson• 2 years ago

I _think_ iMazing can do what you want: https://imazing.com/configurator

Disclaimer: I've never used this feature. I only use it for backups and copying files to my iPhone.

mise_en_place4• 2 years ago

Yeah it's the best solution if you use any public wifi or even mobile telephony. Somebody can just run their own base station and then your phone would connect to that. If it's not your network don't directly connect without a mobile router.

hackermatic• 2 years ago

Edit: Other commenters report that Android will silently re-enable cell data under various conditions, so this isn't a surefire solution, either.

The Grugq created a tool for this a decade ago (sadly unmaintained): https://github.com/grugq/portal as part of a presentation about operational security for hackers. It's a great watch if you're interested in how various (in)famous hackers thought they were secure and got busted anyway. https://www.youtube.com/watch?v=9XaYdCdwiWU

mise_en_place4• 2 years ago

Other commenters report that Android will silently re-enable cell data under various conditions

This is terrifying.

hwbunny• 2 years ago

Just be cautious...

sneak4• 2 years ago

I've done this before for months at a time (the GL.inet E750 with an iPhone with no SIM) but oftentimes US GSM providers throttle the hell out of UDP traffic on weird ports (like to 64-128kbps, a tenth of a megabit), and also notifications are frequently delayed.

ignoramous2• 2 years ago

rethinkdns dev here

these issues should be addressed in the OS in order to protect all Android users regardless of which apps they use.

Android's paranoid networking has always had an exception for System and OEM apps (which include Google apps). Most such bugs fixes are unlikely to fix that core assumption. Some code refs: https://github.com/celzero/rethink-app/issues/224

The leak during tunnel reconnects is harder for us to mitigate in our app. We are still looking for solutions.

Android supports seamless handover between two TUN devices (on reconfiguration). It is tricky to get it right, but implementable.

cma4• 2 years ago

They don't even allow disabling internet permissions on a flashlight app, the OS is run by an internet ad company so it makes sense.

switch0074• 2 years ago

FWIW GrapheneOS does (it asks you before installing any app)

Larrikin• 2 years ago

Can you link to the documentation explaining how developers disable Internet permissions on iOS.

lambdaxyzw3• 2 years ago

Which flashlight app? As far as I know there is no official flashlight app (though recently there is a built in flashlight feature). How is Google responsible for a third party app that refuses to work without an internet access?

talldayo3• 2 years ago

Netguard is an open-source program that helps fix this: https://netguard.me/

fifteen15064• 2 years ago

GrapheneOS does if you're willing to take the plunge.

lxgr• 2 years ago

Is android.permission.INTERNET not a thing anymore? Unlike iOS, Android at least used to have this one.

I sometimes wish I could just configure that per-app as a user. Frustratingly, on iOS it's possible only for mobile data, but not for Wi-Fi – why!?

codedokode4• 2 years ago

That's what you get when you trust your device to commercial companies.

kernal• 2 years ago

That hypothetical Flashlight app, that uses location permission, would have never been approved in the first place.

https://support.google.com/googleplay/android-developer/answ...?

infthi• 2 years ago

This depends on the firmware used. I am writing this comment from an Oneplus device which allows blocking internet access on a per-app basis - on a stock firmware.

adamomada8• 2 years ago

To be fair, it’s the application developer who requests the application’s permissions and it is possible to release an app without internet permission.

I agree that the OS should have a way to override the permission, but it’s not Android itself just giving out internet access by default. It’s more that it’s almost every developer’s default setting when building the app.

The best example of no internet permission in an app off the top of my head is Hacker’s Keyboard – and you can understand why the developer chose to avoid it.

ar-jan• 2 years ago

I think this finding originates with the GrapheneOS community [0]. Edit: I guess that may be the same user reporting both.

0: https://twitter.com/GrapheneOS/status/1782477984156311814

strcat7• 2 years ago

It's worth noting that the built-in VPN support doesn't have these leaks. We don't agree with how Mullvad is presenting this because it is not yet clear if the leaks with their app and other apps are because of bugs in these apps or the OS. Their own post says they've resolved part of these DNS leaks through changing their app to avoid not having a DNS configuration. Android supports many use cases of the VPN service API including not handling DNS and this may be a side effect of that flexibility. It's not necessarily a bug. If it's possible to set up the apps in a way that they don't leak without OS changes, then it was probably an app issue all along.

We're aware of a separate issue unrelated to DNS leaks where multicast packets can leak to the local network with VPN apps. This appears to be an OS bug, but that's not confirmed yet. It will likely only be determined if it's a bug when we find a fix for it. This multicast leak doesn't happen with the built-in VPN support either.

There have been plenty of VPN leaks on other platforms including issues that are still not really fixed without setting up custom netfilter or eBPF rules similar to what Android is trying to do on platforms where that's not done for you by the OS.

On Android, the responsibility for preventing leaks is partially taken on by the OS which promotes a standard leak blocking feature which has gotten much better in the past few years. Each app trying to do this themselves is not a recipe for success. It's not as if Mullvad was aware of these issues for a long time and asking Android to fix it without action.

exabrial• 2 years ago

Any system where you don't have root access in insecure by it's very definition. Android and ios are hilarious.

nickburns28• 2 years ago

a point as salient as it is germane. this is exactly why open-source software and hardware mobile device projects[0] will only continue to proliferate.

[0] https://en.wikipedia.org/wiki/PinePhone_Pro

autoexec6• 2 years ago

As much as I want to support those kinds of devices they're all insanely priced and have earned a reputation for failing at the most basic tasks. Maybe after it's been more than 3-5 years since the last forum post titled "can make/receive calls" I'll give pine phones another look.

fifteen15064• 2 years ago

Most are happy to outsource root to the OS manufacturer. And while I demand having root on Desktop, I don't see it happening on mobile for the majority.

autoexec6• 2 years ago

Most phone users are oblivious to what root even is and yet still hate it when changes are pushed to their devices without notice, with no ability to revert to how things were or prevent unwanted changes in the future. This isn't acceptance but rather learned helplessness.

chuckadams• 2 years ago

Any system that has a concept of root access is insecure by definition. See, I can do silly categorical statements too.

marcosdumay• 2 years ago

Now you can try making true ones.

nickburns28• 2 years ago

categorical ≠ silly

...unless you care to elaborate on why you disagree with this statement in substance and/or on point?

ktm5j• 2 years ago

Honestly I think yours makes more sense than his..

ragnese• 2 years ago

I remember being chastised in some Android subreddits years ago for going against the (probably astroturf) opinion that having root access was "insecure". Sigh...

autoexec6• 2 years ago

It'd be hilarious if phones hadn't largely replaced desktops/laptops for most people. I feel bad for all the kids who grew up/will grow up with nothing but a device primarily designed for media consumption and the collection of their private data for a computer.

whoomp123423• 2 years ago

they will never know the raw power of x86/x64 architecture and are limited to the mere throughput of an arm processor.

switch0074• 2 years ago

The grapheneos devs are really, really against root. What are your thoughts on that?

commoner3• 2 years ago

Anyone who prefers root access on Android with a locked bootloader (on the OSes that support it) can use avbroot:

https://github.com/chenxiaolong/avbroot

Works great with CalyxOS and GrapheneOS.

NotPractical3• 2 years ago

Not OP, but I think that their concerns are legitimate for the most part. One example they've brought up is that, with root, a single bug in the display server could lead to complete and immediate compromise of the entire device (assuming root access is gated by UI prompts as is common on most rooted ROMs). Additionally, with verified boot, persistent changes to the OS made via root would cause the phone to be unable to reboot, which limits what you can do with root (assuming you still want verified boot). GrapheneOS standards are much higher than on desktop Linux, where root can be acquired as easily as injecting a fake `sudo` into ~/.bashrc.

Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing.

Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2].

Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996

[1] https://discuss.grapheneos.org/d/4113/6

[2] https://grapheneos.org/articles/attestation-compatibility-gu...

strcat7• 2 years ago

Making userdebug builds with ro.adb.secure=1 to have root access via ADB with the rest of the security model intact is officially supported by GrapheneOS. Using Magisk massively rolls back the OS security model and is strongly discouraged. Using ADB on a production device isn't recommended with or without root, but it's officially supported if you want to do it. If you only grant ADB access to the computer you use for building and signing the OS, it's not a big deal. You need to be aware that you need to heavily secure that computer and shouldn't use it for anything else though.

whoomp123423• 2 years ago

Any system exposed to the public internet is insecure by its very definition.

AnarchismIsCool• 2 years ago

Root is complicated, I would refactor that to "Any system where you don't have access to the bootloader signing keys is insecure". If you can't run your own code on the device, you can't really trust it.

sneak4• 2 years ago

Then tons of my most important systems are "insecure" by your definition. I'll give you $100k cash no questions asked if you can provide me with copies of my SSH private keys held on such devices.

Your definition is meaningless and not useful for reasoning or communication.

lloydatkinson2• 2 years ago

Depending on your threat model this might mean that you should avoid using Android altogether for anything sensitive

I once worked with someone who worked with someone that had previously been a major Android fanboy, but after doing some work that required a security clearance, they became an iPhone user and insisted their family get iPhones too.

nickburns28• 2 years ago

Apple is no less culpable of the same, they just put it behind the garden walls (which, in fairness, would appear to be just barely more trustworthy than Alphabet).

bongodongobob• 2 years ago

Apple does the exact same shit. I discovered it when I first set up a home DNS server.

lloydatkinson2• 2 years ago

They switched to iPhone not for DNS reasons, but overall security.

jerry1979• 2 years ago

This can also be detected by using the NetGuard firewall which acts as a vpn. Even in full lockdown mode, some kinds of newwork traffic gets through.

strcat7• 2 years ago

NetGuard doesn't support the standard OS leak blocking like Mullvad and doesn't try to filter DNS so it inherently has leaks. There are no known remote leaks on Android 14 when a VPN app supporting is already active or when it's down. The DNS leaks in this post were partially caused by an app bug that's not fixed and also happen when the VPN is in the process of connecting. The issue with leaks when the VPN is in the process of connecting may be an app bug or an OS bug. It's not clear that it's an OS bug at this point. It was reported to us for GrapheneOS earlier and we've been looking into it.

There's also leak issue which was reported where multicast packets leak outside of the VPN tunnel to the local network. This is highly likely to be an OS bug, unlike the DNS leak issue where it's not yet clear if the OS or the app is the problem. The OS can likely prevent those DNS leaks even if apps don't get fixed but it wasn't necessarily supposed to be responsible for it. From the OS perspective, a VPN app is supposed to set a DNS configuration and not setting that configuration results in partially using the OS DNS.

Valery91• 2 years ago

If you don't mind clarifying, currently GOS uses ASYMMETRIC MTE for the low overhead and to close the soft time constraint in ASYNC MODE. I was having a read though https://googleprojectzero.blogspot.com/2023/08/mte-as-implem... Where I had come accross possible MTE bypasses in ASYNC mode and I quote: 'Since SIGSEGV is a catchable signal, any signal handlers that can handle SIGSEGV become a critical attack surface for async MTE bypasses'. Moreover, "The concept is simple - if we can corrupt any state that would result in the signal handler concluding that a SIGSEGV coming from a tag-check failure is handled/safe, then we can effectively disable MTE for the process", hence having MTE as ineffective.

Paradoxically, I don't believe this issue is faced regarding SYNC MODE. As you obviously know, 'in asymmetric mode, read memory accesses are processed as SYNC, while write memory accesses are processed as ASYNC'.

does this mean that the signal handlers in write memory are exploitable?

If this be true, does GOS offer a mitigation for this, or can it be possible to simply allow all users to have the option to pick SYNC MTE to bypass this attack surface?

Furthermore, MTE is not enabled for the kernel, would it be possible to have it enabled by choice as well?

Finally, regarding the OS processes to which GOS recently enabled MTE for as an option for its users, does it also include the cellular firmware, IOMMU/SMMU and the software stack that communicates between the isolated chip and the OS? I address this point because, GAL Beniamini stated that: " That said, up until now we’ve only considered the high-level attack surface exposed to the firmware. In effect, we were thinking of the Wi-Fi SoC and the application processor as two distinct entities which are completely isolated from one another. In reality, we know that nothing can be further from the truth. Not only are the Wi-Fi SoC and the host physically proximate to one another, they also share a physical communication interface". Nonetheless he further states: "For example, by going over the IOMMU bindings in the Linux Kernel, we can see that apparently both Qualcomm and Samsung have their own proprietary implementations of an SMMU (!), with it’s own unique device-tree bindings. However, suspiciously, it seems that the device tree entries for the Broadcom Wi-Fi chip are missing these IOMMU bindings". Despite that the research is from a couple years, it remains viable evidence that IOMMU although provides adequate protection, it remains an insufficient mechanism on its own and requires further hardening on the software stack. Does GOS address this profound attack vector?

I hope to get your perspective on the matter.

Thank you in advance.

bastard_op2• 2 years ago

This has been a long-standing issue with android, that no matter how much you want it to use internal dns servers only, it'll decide to flip to cell and use those as it needs/wants. I've observed adb debugs for times recently to see why/when wireless was disconnecting, and it comes down to liveliness checks that if it can't see or resolve something, it'll simply bring up and try the cell data to do so.

It's especially frustrating when using internal dns records that only live internal will randomly not work on a phone. I can see that the device is on wifi that is feeding internal dns servers with the records, but it's resolving externally still for some android reason. This happens on my SO's phone when using things all the time, but I really don't use my phone in the house except to read books and rarely notice.

No idea how apple is about this, but the fact they try to proxy everything you do via their "privacy" vpn by default including dns as DOH, I can't imagine it is any better trying to use what they'd see as a competing product, and we know how apple feels about those.

edward28• 2 years ago

Have you tried disabling "mobile data always active" in developer options?

gruez• 2 years ago

it'll decide to flip to cell and use those as it needs/wants

Are you sure you don't have wifi assist enabled? That's explicitly designed to switch to cellular when wifi signal is poor.

callalex• 2 years ago

iOS absolutely does not use Private Relay (iCloud branded VPN) by default. Even when it is included in a subscription, you must explicitly opt in.

kccqzy• 2 years ago

The Limit IP Address Tracking feature is turned on by default and Apple makes it more annoying because it is turned on or off for each WiFi network.

And a simple search shows definitely people annoyed by the exact same symptom of redirected DNS queries and inability to use internal-only DNS entries. https://www.reddit.com/r/ios/comments/uurkqr/limit_ip_addres...

adamomada8• 2 years ago

Apple (or iOS) actually has a robust built-in way to filter and block traffic using configuration profiles. I’m uncertain if you can configure it per-app, but you can definitely whitelist/blacklist hostnames. For an example of this in action, check out this system-wide ad blocker https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...

rsync3• 2 years ago

Can it be reliably configured to “fail off” ?

That is, if my configuration profile Becomes invalid or is non-functional, Will it just cease to pass traffic?

threecheese• 2 years ago

That website … scares me. Why are you trusting this product? Is there source available or some audit record?

xvector• 2 years ago

This looks very sketchy. I'd recommend checking out Little Snitch instead.

valianteffort• 2 years ago

I built AOSP from source. It's supposed to be devoid of any google specific requirements. I went out of my way to block as many google servers as I could in the hosts file just to ensure it wasn't phoning home.

As far as I can tell the only issue I ran into was that despite being connected to a working wireless access point, the device reported I had no internet. It still worked, but it seems for the purposes of the status bar icon, and whatever other underlying system code, it was using a google server to verify internet was working.

I would just stay far away from android if you value your privacy, and probably tech all together.

ilrwbwrkhv2• 2 years ago

I will give up on android and move to iPhone. Google cannot build products whatsoever.

talldayo3• 2 years ago

That would be a pretty expensive mistake considering iOS also has VPN leaking issues that have been reported but unfixed for what, years at this point?

bastard_op2• 2 years ago

As said they have the same problems, and a lot less options to do anything about it. It is different kool-aid, but still just kool-aid.

If you really want secure and private, get a dumb phone, and just use it as a phone. Anything else, use linux that you can actually control and audit.

the8472• 2 years ago

Linux has network namespaces, which can be used to isolate programs so they don't see any external networking when no VPN is available. Does android not use this for its VPN feature?

dyingkneepad• 2 years ago

Lol. On the other hand, I use Linux network namespaces to make programs run outside the VPN on a specific machine that has the whole system configured to go through the VPN. So yeah if you get namespaces you can use them to both isolate programs and also bypass the VPN.

ranger_danger• 2 years ago

I have also noticed that when using the FoxyProxy addon under Firefox, even with a SOCKS5 proxy in use, it will leak DNS requests through the direct connection unless you also set a manual proxy in the regular Firefox settings as well.

yjftsjthsd-h2• 2 years ago

I don't suppose you can set a nonexistent manual proxy and then use the addon for everything?

moose442• 2 years ago

Apologies if this is a dumb question—could a service like NextDNS help prevent this?

nickburns28• 2 years ago

nope. no DNS service, not even a self-hosted one, can mitigate what's happening here.

the matter at-hand considers Android (and iOS both) operating system- and kernel-level insecurities by-design. the operating system (together with all root-level or otherwise authorized system activity), under certain conditions—e.g. connectivity change, hard-coded system function, apps with permission to hardcode their own network functions, etc.—will refuse to use any NIC, whether physical or virtualized, except the one containing the cellular carrier's connection/routes. that traffic might then necessarily include DNS queries and any/all other private but now-leaked data.

moose442• 2 years ago

Interesting. Thank you for this.

raggi• 2 years ago

NextDNS _does help_ though by way of being DoH, so while your packets might be traversing a less desirable path they’re not readable.

throwaway2037• 2 years ago

I don't VPNs, nor Mullvad, but I do appreciate the transparency here. We need to support more companies like this.

kop316• 2 years ago

I've sort of suspected this the case for a while. On VPN, MMS and Visual Voicemail still work on Android. Both of these require direct mobile access or they will get rejected (sometimes they are only on the mobile network, or else they requests get rejected if they don't come from within the mobile network). I suspect the same is true of VoLTE. If there is a VPN, that would mess things up.

I found this out since on Mobile Linux, if you enable VPN, the VPN breaks all of those.

I don't think there is a clear way to fix this on Android without breaking a lot of expected functionalty.

nickburns28• 2 years ago

ironically SMS/MMS and VVS are two of maybe a few other operations/functions (system updates maybe? maybe?) that are justifiably 'hard-coded' to the carrier connection.

i've done the dance re: VVS with advanced AT&T support on VPN'ed iOS—so can confirm your point is not limited to Android.

bestham• 2 years ago

No VoLTE uses a dedicated bearer (network interface) in the LTE stack. Not the one used for data. Different bearers can have different priorities/QCI (like QoS). In a congested LTE network VoLTE should provide a better experience than VOIP on a lower priority bearer.

mise_en_place4• 2 years ago

Luckily WireGuard doesn't have this issue on desktop peers. Although I did run into DNS leaking due to my peer config having an exception for my local network address range. The way I resolved that is to setup dnsmasq on the server and set that as my primary DNS.

I will say that I wish there was a DisallowedIPs directive. It's fun having to subtract a /24 from 0.0.0.0/0, although there are calculators you can use.

chgs• 2 years ago

Just have a black hole route for the subnets you don’t want to send to

d-z-m• 2 years ago

Luckily WireGuard doesn't have this issue on desktop peers

for windows split tunnels it still does, I believe.

rkagerer• 2 years ago

We have reported the issues and suggested improvements to Google

Isn't Android open source? Can they not fix it for them and submit a PR?

nickburns28• 2 years ago

Mullvad's not really in the business of developing for Alphabet. but any of us could though, sure.

GrantMoyer• 2 years ago

Android is open source, but the codebase is massive and unapproachable. I managed to make some tweaks to Android, and compiled my own custom version (for one, I removed the stupid blur from lock screen album art), but I'm fairly confident I wouldn't be able to even find all the relevant code for DNS and VPN interactions in any reasonable amount of time.

robertritz• 2 years ago

I noticed this with my Android TV. Sometimes my location would leak and certain streaming sites stopped working (I'm outside the US).

Got an AppleTV and this issue stopped.

resource_waste• 2 years ago

No one is going to say Apple has acceptable levels of Security.

I am a bit shocked when I see politicians with iPhones, most are unaware that Pegasus can take over at any point.

NotYourLawyer• 2 years ago

Yes, iOS is the only software with 0 days.

badrabbit3• 2 years ago

I gave on trusting phones to secure data a long time ago. But my approach is, at least when on wifi, to allow access to the internet only if the device connects to a local vpn gateway. 100% leak proof and prevents almost all wifi/lan/mitm attacks.

nickburns28• 2 years ago

what if a system-level (read: root) process doesn't respect your user-configured routing table? that's the real issue here. only mitigation would be to physically remove the undesirable NIC/s from the system, which is obviously impossible on SoC hardware.

badrabbit3• 2 years ago

It won't make a difference, the other end (gateway) will only accept vpn connections, nothing more or less. Devices that can't establish a connection with your wg/openvpn won't be able to communicate with any other device anywhere in any way period.

Asmod4n• 2 years ago

The Problem with Android in regards to DNS: you just can't set your own IPv6 DNS Server on that platform, it gets changed anytime anything happens to your wifi. There is no app, even for rooted android, which can disable the operating system from changing it.

When you are stuck with a router that always hands out IPv6 Adresses and doesn't let you turn that off you are just screwed.

I don't even know if you could install a firewall appliance behind that router and strip out the IPv6 DNS Servers it advertises.

stainablesteel• 2 years ago

so that's what happens on when the phone is the main interface

does this happen with wifi tethering too? if i have a vpn set up on a laptop that i connect through the phone's wifi will that leak in the same way?

jsheard• 2 years ago

What if you use the system-level support for DNS-over-TLS instead of setting the DNS server IP addresses? That's a global setting so it should apply regardless of which network you're on, or what happens on it. If you care about DNS requests leaking you should be using DoT or DoH anyway.

nickburns28• 2 years ago

doesn't matter. plenty of elaboration elsewhere in the discussion.

aritashion• 2 years ago

Doesn't rethink let you change ipv6 dns?

bobbob19213• 2 years ago

A few years ago, when I was testing various VPN set ups for a project, one thing I would do is have a MikroTik firewall device (hardware) sit between my computer and my main router, it’s only purpose would be to block any traffic, not dst for the IP address of the VPN server that the pc was connecting to.

This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.

Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course). MikroTik routers also have a great little tool called torch that allows you to quickly and easily watch traffic (in addition to of course, supporting packet captures. Mikrotik routers are very reasonably priced and range from as low as $30 up to $3000 - all with no software licenses, and they are very powerful and capable if you know what you’re doing.

nickburns28• 2 years ago

  This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.  

  Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course).

outbound filtering by source and/or destination address and/or port is both a fundamental firewalling concept and standard configuration on all firewall-routing platforms. (policy-based routing[0], i.e. filtering by gateway, is the same.) generally speaking, only the con/prosumer products allow everything out by default.

just curious, what was your "main router" in this setup? ISP-supplied?

[0] https://en.wikipedia.org/wiki/Policy-based_routing

bobbob19213• 2 years ago

It was also a mikrotik - so of course, I could’ve done everything on that one.

however, I had to show / prove to a client that the set up could be easily duplicated at other locations (and moved around) where everything else on the network was unknown (only known / controlled parts were to be a Windows laptop, and the mikrotik router connecting ethernet from that laptop to whatever network also via eth.

For some of the configurations that needed to be very portable, the (very low end) MikroTik was powered via USB from the laptop

Customer also wanted the router to log any dropped/leaked traffic (which we did on the mikrotik to it’s internal memory, or a usb stick with a txt file log)

autoexec6• 2 years ago

As long as you're promoting them, have they got a good/cheap router with a layer 7 firewall?

If only we could insert a firewall between our apps and the modems in our phones.

rsync3• 2 years ago

Raspberry pi with a second network interface… Running FreeBSD.

As to your other point… If you remove the Sim card from your telephone and then connect to a second router device that you carry with you… But we’re getting a little weird here…

rsync3• 2 years ago

This type of device is referred to as a “network slug”[1] … and it is a fantastic idea.

If we’re being formal, a true slug is one that has no IP address defined and is a transparent layer two firewall… But we don’t need to pick nits here…

[1] https://john.kozubik.com/pub/NetworkSlug/tip.html

Zuiii• 2 years ago

Can a standard linux distribution be configured as a network slug? I'm sick of companies forcing themselves onto people's private information without their consent.

bobbob19213• 2 years ago

Very cool, didn’t know about this!

aftbit2• 2 years ago

Also apparently tethering traffic doesn't go via the VPN? That's a silly choice too.

nickburns28• 2 years ago

that's a *deliberate choice.

aftbit2• 2 years ago

Why?

marc_ranieri• 2 years ago

Block connections without VPN is turning out to be as reliable as my self-control at an all-you-can-eat buffet…if I'm not mistaken, these DNS leaks can very much expose where you browse and even your location, which kinda defeats the whole purpose of a VPN (and yes, even with VPNs, Android might still leak your DNS info. If you're really privacy-conscious, you might need to look beyond just using Android or keep your sensitive stuff off your phone)

wolverine876• 2 years ago

Mullvad's security team should have found this problem on their own, and as soon as it appeared:

Inspect security empirically - you might think that your security must work, but that means nothing; you must investigate empirically: All data going to the Internet must pass through the gateway. Collect the packets on the gateway, not on the device, and inspect them for leaks. Finding leaks should be trivial at that point.

The only trick might be cellular connections: We don't know that leaks aren't unique to cellular connections. I know cellular gateways can be setup, but are the packets inspectable at a level that will reveal leaks?

kerhackernews• 2 years ago

Can't you just use a DNS provider that encrypts the traffic?

spxneo5• 2 years ago

toy with me for a bit, couldn't Mullvad be another "Encrochat" in the making?

Encrochat was similarly marketed as absolutely trustable complete with experts covering "we fixed this vulnerability/exploit and you can trust us" vibes (https://www.manchestereveningnews.co.uk/news/uk-news/dads-se...)

Isn't Mullvad the same thing?

Do you really think they would allow terrorists like Hamas use Mullvad to coordinate attacks? Coincidentally, Hamas does not trust any sort of VPN, opting for underground land lines.

generalizations2• 2 years ago

Hamas does not trust any sort of VPN, opting for underground land lines.

I mean, duh. Like everyone always says around here, all bets are off when your threat model includes nation states.

Timing attacks, meta data, and total access to the internet backbones means it’s a reasonable bet that the Big Boys can track anything on the public internet, regardless of encryption or redirection. And if you’re Hamas, you’re probably on their radar.

spxneo5• 2 years ago

So your narrative is that they have complete access but choose not to act on anything they find on VPNs and other "privacy focused" tech?

Makes sense as there has been no cases involving terrorist using Mullvad and such.

So Mullvad is not good enough for terrorists but good enough for the rest? This makes no sense to me.

maxo133• 2 years ago

This is a good point. It doesn't have to be Mullvad but it's almost guaranteed based on what we've seen in the history (see CIA + swiss crypto company) that some of the major VPN providers are managed by intelligence agencies. Either VPN companies were bought via shell companies after reaching certain market share or they were even developed from the scratch.

Remzi1993• 2 years ago

Sometimes you wonder if those "bugs" are intentionally well placed or not. Especially since big tech has been known that they work together with a kinds of intelligence agencies. I just can't believe that so many bugs like this in Android are there "not intentionally" at this point since this is not the first time I have heard about these kinds of bugs in Android.

sneak4• 2 years ago

"Once is happenstance. Twice is coincidence. Three times is enemy action." —Ian Fleming, Goldfinger

Rastonbury3• 2 years ago

What if I have private dns set up on my phone?

seany• 2 years ago

I really _really_ want to love mullvad, but they still don't ignore DMCA requests.

chrisjj• 2 years ago

But why should they ignore DMCA requests?

sneak4• 2 years ago

APNS traffic leaks outside of the VPN on iOS as well (except possibly OS-supported VPNs installed with a provisioning profile).

Apple doesn’t seem to care, as they don’t care about preserving your privacy wrt themselves.

haisin1982• 2 years ago

I like Mullvad. Just wish they used less shitty providers - all of them are super dodgy from xtom (super unhinged owner) to m247. Mullvad presents a great image but their providers would probably sell netflow traffic for $7 a month to any interested party. They really do use the scum of the earth providers instead of investing in their own infra

taxesTaxi• 2 years ago

So, a closed source operating system can do things the user can't control? I don't know what's more impressive, the fact people don't apprehend this reality, or the fact people still rely on VPNs (especially a third party) for privacy or whatever.

beefnugs• 2 years ago

If google wasn't evil: then the default for all permissions would be to mock fake data that the app could never recognize as fake. Then you pick and choose which apps get REAL data.

mik09• 2 years ago

used an exploit to get vpn working on router...

DNS traffic can leak outside the VPN tunnel on Android

Related Stories