Suspicious traffic on Android app

[gitd8b]

Okay, I created a github account and it seemed to have flagged it as spammy. Hopefully not because I'm putting IP addresses in this issue. Please disregard the other issue if there's a "duplicate"... GitHub seemed to just not like my other account (changed VPN connection)

Issue report

Operating system: Android

App version: 2022.1

Issue description

The other day, I noticed odd network calls coming from my phone. This started a little over a week ago, and I grew suspicious that something found its way maliciously to the phone. However, after a lot of investigating, I narrowed it down to the Mullvad VPN application. When "activating" the VPN, There are many network calls being made immediately, all over UDP with random ports and IP addresses. Looking up many of these destinations, it appears that most of them are telecommunication companies. Can Mullvad please provide details on what's going on here? I updated to the latest version of the app and it's still doing it. I then decided "What if it's the VPN part of my phone?". I installed Wireguard and used a custom config file there - it didn't happen. It's ONLY the Mullvad app that appears to be doing this.

Here's a copy/paste of 10 addresses and port numbers that are called (Again, there are MANY more):

1770 142.189.97.178
2829 197.140.140.163
3165 60.4.42.248
5214 112.107.18.244
6130 119.21.56.104
6275 161.112.251.216
6715 157.115.221.148
8387 139.88.210.209
10745 197.45.167.75
11863 222.192.186.147

[pinkisemils]

Could you elaborate on the methodology used to narrow this traffic down to our app? Does this happen if you enable Always-on and Block connections without VPN in Android's system settings? Could you try and replicate after forcefully stopping all browser applications? It is weird that the vanilla app doesn't exhibit this behavior, and I'm not sure what would be the root cause.

The listed IPs do not belong to any of our current relays, so I doubt that our application is sending this traffic.
When connecting on Android, we don't get to use a firewall, so we rely on the routing table routing all traffic through our network interface. There might be other applications that use a network callback which might get executed before our routes are finalized. I'll investigate this and see what I can find.

[albin-mullvad]

Would you mind sharing which device and Android version are you using? If possible, it would also help if you can submit a report from the app so that we can investigate the anonymized logs.

[gitd8b]

@pinkisemils My firewall/router send live logs to my database which is parsed in Grafana. From my device, I do have Mullvad set to 'always on' and 'block connections without vpn'. Immediately after clicking 'secure my connection' to initialize a connection, Grafana shows a ton of these random connections being made from my device. I've gone as far as blocking Internet access to all the apps on the phone except for mullvad - it still came back showing these UDP packets being sent.

@albin-mullvad This is a Oneplus 5T on Android 11. I'll send in some logs now - you should be able to determine which ones are mine w/ the logs OS log + the timing of this github message being in the same minute.

Extra notes:
I've been looking at this a lot yesterday and this morning, and am starting to wonder if something on my phone is "injected" with something that's just continously trying to connect to these endpoints. When my phone's in between states (going from wi-fi which is blocked -> mullvad VPN), if whatever's causing these calls to happen is sending out the UDP packets at that very brief time window. That being said, that would imply that something is removing the rule for the "block connections without VPN" and then applying whatever firewall rules routes traffic through the VPN. At least that's my theory.

I tried to monitor what may be going on with logcat, but didn't see anything useful. The key things that stood out to me were:

@3 netlink: 4 bytes leftover after parsing attributes in process `libpcapd.so'.
...
QCNEJ/NativeHalConnector: Failed to parse input for notifyDefaultNetworkChanged: java.lang.IllegalArgumentException: Unknown RatType:17
...
GnssNetworkConnectivityHandler: updateNetworkState, state=CLOSED, connected=true, network=150, capabilities=[ Transports: WIFI|VPN Capabilities: NOT_METERED&INTERNET&NOT_RESTRICTED&TRUSTED&VALIDATED&NOT_ROAMING&FOREGROUND&NOT_CONGESTED&NOT_SUSPENDED LinkUpBandwidth>=774494Kbps LinkDnBandwidth>=54601Kbps Uids: <{0-99999}> AdministratorUids: [] RequestorUid: -1 RequestorPackageName: null], apn: null, availableNetworkCount: 3

Is there any way to try and capture (perhaps through termux) which files exactly are making these UDP Requests? I've also noticed that there are no DNS requests being made right before all these calls happen, so that implies something must already have these statically defined... Or there was a DNS request a long time ago that just got cached and it's using that once that connection change happens.

Lastly, just want to re-mention that the first time this happened was late last month. I've been using the Mullvad VPN app for a long time now, and don't recall ever seeing this before. I also tried on my other phone which was not exhibiting the same behavior... It's kind of making me think more and more that something's injected in a binary somewhere that's waiting for that connection change to happen to send up these UDP packets. I did capture these packets and throw them into wireshark, but the data appeared to be either hashed or encrypted so I didn't get far w/ that.

If there's any advice on what I can use to trace which apps, processes, binaries, etc. are using the network callback you mentioned above, that might help me with narrowing my search down to what this was. I initially assumed it was the Mullvad app itself once I was able to notice it being timed with exactly when I click 'secure connection', but based on what I'm seeing + looking around in the repo, I'm starting to think that's not the case and that my request here may be misplaced... But nonetheless, not sure where else I'd go for this outside of wiping my phone and seeing if it was something malicious (but then I'd never know what caused it!)

[gitd8b]

I think I've finally found something. Without having my phone rooted, I don't think I would have found this.

There's a software called AFWall+ which allows you to block out connections on the phone (uses iptables to do so). I used this to block everything on the phone from the Internet except for mullvad vpn. The connections continued to happen. I decided to do the exact opposite and start allowing things to go through instead of blocking. There's one option in particular called (root). This basically attempts to block the root user from accessing the Internet. I recently had removed Internet access from this user on my phone over a week or two ago, thinking "Oh hey root should never hit the Internet". What it looks like is that when the root user has no means of going anywhere because of the iptables blocking it, it somehow "bypasses" it and goes straight to the first available connection. During the transition from wi-fi to VPN, there is a very brief point of time where I'm not on the VPN.

Apparently, when enabling VPN (regardless of whether it's wireguard or Mullvad, or likely even other VPNs), all this traffic is sent out to the networks around the world or something. For what purposes, I'm not sure... I can't read the data and am not really smart enough to know how to decode it (and not comfortable sharing the data here in case it has personal info). With that being said, I found this out because I added iptables -I OUTPUT -j LOG to my iptables rules. When I had (root) blocked, I was able to see 20-30 logs go through wlan0 and then about another 100 or so go through tun0, when the VPN kicked in. Apparently the Wireguard app must be doing something to keep this brief moment of time leak from happening because when I did the same thing with the Wireguard app, 100% of the attempts were dune through tun0. When I re-allowed the (root) user to VPN only, it properly waited for the VPN to connect and then sent out all these mysterious packets... So in other words, if your phone is rooted and you use AFWall+, you can prevent leaks by allowing (root) over VPN-only.

Note: I had a spare older phone just to try this out for fun and sure enough, it does the same thing (Did 100% clean factory reset, rooted, and installed ONLY AFWall+ and Mullvad). This appears to be something in the Android hardware level if I had to guess, and I just never noticed it before because I did have the vpn access given to (root) beforehand. This leaves the big ol' question of: Why is Android sending out odd UDP packets to hundreds of networks around the world when you connect to a VPN? Does this happen only when your phone is rooted, or does this happen to non-rooted phones and no one has noticed because they didn't sniff out the packets? I'd be curious to know this, and may look into this later on...

With all that being said, feel free to close this if you just want to invalidate it all (or if I'm wrong about my findings here, please coorect me!). Maybe if someone else later on comes through and sees this, they can investigate and analyze this further than I can. In the meantime, I am happy to know it wasn't from malware or the Mullvad app doing something funky ;) Thanks for the quick support responses all!

[laundmo]

i disagree that this should be closed, instead i would like mullvad to endeavour to, similar to wireguard, block those requests.

[gitd8b]

Just to clarify, Wireguard still allows the requests to go through from what I can tell, it's just that it doesn't get reported at my firewall (AKA there's no leak of my personal IP address) - I can only see the packets going through, not the details (since it's encrypted by the VPN connection). And the Mullvad App only leaks that when the (root) setting is disabled in AFWall+.

That being said, I agree it would be nice for that leak to be avoided for anyone else who may have a rooted phone and having (root) "disabled" at all network levels in AFWall+ or whatever network firewall software they use that may allow that... And just because I didn't see a leak when that was re-enabled for VPN doesn't technically mean it won't happen again. Could just be a simple timing issue in this case, but I have no idea.

[laundmo]

Could you maybe capture the packets before they enter the VPN, by means of tcpdump or similar? then you could store that as a pcap and analyse it in Wireshark, which should give you some info as to wehther its a known protocol at least.

[gitd8b]

Yep that's exactly what I did. Ran tcpdump from Termux, collected that into a cap file, and threw that into Wireshark on my laptop. Unfortunately the data isn't just easy plaintext. I'll test it against some hashes later and also see if I can identify any kind of "simple" encryption that can be decrypted if it's not just hashes, but I'm no expert in that field. If tcpdump has a way to snatch the key used that encrypted these values, that might be what I can use. I just don't want to paste the data of the packets here in case it contains personal information :) I'll say that they (interestingly) all contain different sizes of packets (the data length, that is), it's not like one size for all endpoints... And they all show unverified on checksums, if that means anything.

[albin-mullvad]

Thanks for the follow-up info! We're looking into this to understand what's happening.

[albin-mullvad]

I've tried to replicate your setup as closely as possible without seeing the same behavior as you do when looking at captured traffic from the device or network/router. Just to make sure I'm not missing anything, can you help compile a detailed list of steps to reproduce? Also, can you share some more details of the OS you are running? I assume you are not running official OxygenOS as I believe it wasn't released for the OnePlus 5T.

My setup:
Phone: OnePlus 6T
OS: LineageOS 18.1 (Android 11)
Recovery: Lineage Recovery 18.1
Root method: Magisk (24.3)
Apps: Mullvad VPN (2022.1), AFWall+ (3.5.2.1)

One thing I noticed was that the phone seemed to be struggling with DNS (and perhaps other connectivity) when blocking the root user in AFWall+.

[ali-farhad]

like @albin-mullvad suggested, could OP please make a detailed list of all the actions needed to replicate this issue? I'm on OnePlus 8 pro and would like to see if it's something exclusively related to OnePlus or any specific version of Android OS?

[gitd8b]

Apologies for the late response. Apparently I didn't get notifications on this issue for whatever reason.

Phone number 1:
Phone: OnePlus 5T
OS: LineageOS 18.1 (Android 11)
Root method: Magisk (23.0)

Phone number 2:
Phone: Oneplus 9
OS: LineageOS 18.1 (Android 11)
Root method: Magisk (24.1)

I just tested this out with the Oneplus 9 and can still see it happening at this time (albiet I haven't done any OS/Mullvad app updates since the post was made):
My router's setup to forward all traffic to a logging server I have on the network to monitor traffic, which is how I was able to notice this traffic (may have already mentioned this).
AFWall+ settings:

1. Set to 'allow'. In other words, only checked items are allowed.
2. Only check VPN+Wifi for Mullvad VPN, nothing else

Open Mullvad app and click 'secure my connection' to initiate a connection. This should then show all the traffic (before it's connected to the VPN) on the network. Optionally, install PCAPdroid on the phone to see some of the traffic locally on the phone too (unfortunately shows as an 'unknown' app).

Interestingly, I tried this again with just mullvad and (root) set to vpn+wifi and saw the traffic still coming in. Playing some more w/ this, I was able to stop the traffic from showing on the router when setting "ALL" to "VPN only"... Repeating these steps around to try and figure out which app doesn't show traffic on my network, I narrowed it to (kernel) this time... Really confused on how that happen. I did notice that once I allowed it to connect once, I had to disconnect from my wifi and reconnect again to reproduce it. Is it possible some information is sent out to relays about the local network? Total random thought on that part, don't let that derail what's going on lol.

Hopefully my mistake in saying (root) instead of (kernel) will make this easier to reproduce. Let me know if you need more details on this and I'll try to respond quickly to it. In summary/TLDR: as long as "(kernel)" is given no network access in AFWall+, the odd traffic should show up on the local network or PCAPdroid.

[firepacket]

I have a very similar setup with Mullvd/root/OnePlus/AFwall+. I have come to believe OnePlus phones are lliterally covert spy devices for the Chinese. I have been dealing with these issues on 2 different OnePlus phones (7 Pro and 6T) and their backdoors are deep. Unauthorized outgoing connections can appear to originate from any random application as well as system/root. VPN rules are completely ignored.

AFWall+ is the most popular root iptables firewall but it is not as effective as another I have found, plainly called "Android Firewall". It stops more of these suspicious connections, but not all of them. I have even witnessed system/root attempt outgoing connections over my LAN ip while explicitly connected to Mullvad and disallowing LAN networking.

The Android system, on OnePlus (and other) devices, does NOT honor VPN settings.

Even more astounding and appauling is witnessing the Anroid system/root attemping to bind and use FOREIGN IPs that are not at all associated with my ISP or any company in my country.

I am glad others are noticing this traitorous functionality becaue I have been yelling at a brick wall for years.

I encourage everyone to do a thorough forensic audit of their mobile devices' network activity and witness it for themselves.

If Mullvad could, or would, attempt to investigate this type of dishonest misbehavior occuring on Android devices, and offer some way to combat/block these malicious rouge connections through the utilization of root access, it would instantly become a shining becon of light and hope for all mobile phone enthusiasts.

[pinkisemils]

If Mullvad could, or would, attempt to investigate this type of dishonest misbehavior occuring on Android devices, and offer some way to combat/block these malicious rouge connections through the utilization of root access, it would instantly become a shining becon of light and hope for all mobile phone enthusiasts.

We currently have no plans for supporting extra functionality using root access. Having said that, if this traffic seemingly circumvents existing iptables rules, there is nothing we could do any better than what existing firewalls already do.
In general, we can only do as much as the system allows us to do. If you're threat model implies you can't trust your OS, our client won't help with that.

I have even witnessed system/root attempt outgoing connections over my LAN ip while explicitly connected to Mullvad and disallowing LAN networking.

Does this happen even if you've enabled Block connections without VPN in the system settings?

[firepacket]

Refusing to acknowledge bommon threat model is what every company does. i just hoped you werwe different

[albin-mullvad]

Sorry for the delay @gitd8b and thanks for providing additional information. Have you tried to compare the behavior of different VPN apps, i.e. by using Wireguard for Android with a configuration generated via our website? It would be really useful to understand whether this is Mullvad app issue or if it's a more general issue.

@firepacket it seems like you are saying that this is a general issue with all VPN apps on some OnePlus devices, is that correct? Can you see that same behavior on both rooted and non-rooted devices? Have this been reported to OnePlus and/or Google?

[gitd8b]

Sorry for the delay @gitd8b and thanks for providing additional information. Have you tried to compare the behavior of different VPN apps, i.e. by using Wireguard for Android with a configuration generated via our website? It would be really useful to understand whether this is Mullvad app issue or if it's a more general issue.

@firepacket it seems like you are saying that this is a general issue with all VPN apps on some OnePlus devices, is that correct? Can you see that same behavior on both rooted and non-rooted devices? Have this been reported to OnePlus and/or Google?

When using Wireguard for Android, the traffic gets routed through the VPN right away, yes. But that's only when I permit 'kernel' to have access to the internet through VPN using AFWall+. If I block all network traffic from the kernel, then it's ignored and gets sent out over my home wifi connection (which is luckily on a VPN already). When using the Mullvad app instead, some of the traffic "leaks" through before the VPN connection catches the packets.

Likely there is a difference in how the Mullvad Android app and the Wireguard for Android apps are configuring their VPN rules, which result in the leak skipping the Mullvad app on those initial steps.

As for the mention above from firepacket regarding OnePlus - I'm also curious if anyone out there has tried to find a way to bypass the OnePlus kernel or whatever that's making this happen. I'm not technical enough to know how to go down to the hardware level on phones to pin point what's going on and how to bypass that stuff, lol. Hopefully someone smart enough will come by this GitHub issue and take the dive if it's indeed just OnePlus devices that do this.

I have an old nexus phone lying around somewhere collecting dust. Not sure if it's about the same age as the OnePlus 5T or not - but if it is, maybe I can root that and see if I can reproduce the same behavior on that device. If it does the exact same thing, then we can rule out OnePlus being where it occurs. If it doesn't happen on it, then it might point to being OnePlus but can't be guaranteed due to the device's age.

[gitd8b]

EDIT: Here's a list of IP addresses I've collected by just toggling on and off the "local network" button. https://github.com/gitd8b/ips_lists/blob/main/op9_ips.txt --- Not sure if any of those IP addresses stand out to anyone as a red flag or if anyone knows of an automated way to scan them through for an idea of what they belong to.

Alright, so pulled out my old rooted Nexus 5X and installed Mullvad on it. I have good news and bad news.

Good news:

• The weird IP address traffic didn't happen. I blocked everything on AFWall+ to match what my OnePlus 5T did.

Bad news:

• 5X is no longer supported by LineageOS. This means I can't get the latest version of LIneageOS on it (runs 15.1). It also means I can't install Gapps or MicroG on it to match my OnePlus phones to see if it's related to google services in any way.
• It still means that either OnePlus is doing something suspicious or Google Apps / MicroG.

In general, at least we can say that it's very unlikely all android devices do this... In the meantime - does anyone have suggestions on how to search hardware firmware or something in the rooted phone to determine where these weird IP addresses are coming from? Otherwise I'm at a loss outside of seeing if I can buy another root-able non-oneplus phone to try this one and see if I can reproduce it that way lol. In the meantime, I'm going to just have my phone do its connection thing like 100 times and make a huge consolidation of these IP addresses it's trying to phone out to and then investigate them from there to see if I can find anything online about it...

Oct 10 2022 Edit:
Just because I hate the idea of doing a "triple post" in my own issue, editing the previous one.
Saw the blog post you all posted: https://mullvad.net/en/blog/2022/10/10/android-leaks-connectivity-check-traffic/
This sounds almost identical to what I'm seeing/reporting on this issue (or is that where this research stemmed from? :) - if this is related, you all have my support even more for going so far above and beyond on this! lol). So it sounds like this may be a bigger issue than just what OnePlus has.
That being said, I think the wireguard app itself helps mitigate this quite a bit from my tests above. Can you all confirm this to be true? Just curious if they have found some way to bypass these leaks or not although maybe I didn't do enough testing to thoroughly confirm this 🤔

[foundingfather76]

Possibly the endpoints of the IP addresses are not important. What looks like IP octets, could actually be a code that transmits identity information, and/or decryption keys. Possibly they are IP addresses of totally harmless, uninterested businesses, whose traffic is deliberately routed. Routed through a central monitoring point, that intercepts, strips, and collates certain specially formed packets. Piggy-backing bits of covert data, in a prosaic data stream. Our vast numbers (around eight billion) concern all entities who control money, power, and influence. They collude, and apply whatever talent, and resources they feel are needed. I came to this page because of concerning traffic I see in my firewall logs, since installing a VPN. Thank you for investigating with skills I do not have. If I find anything incontrovertible, I will post it.