[Bug] App tracking protection issue preventing GrapheneOS from shipping multicast leak fix

[u-fred]

Describe the bug

I am working on fixing the upstream Android multicast leaks for GrapheneOS. Our solution is working well, except for a compatibility issue that we are encountering with your app specifically.

The issue is that after we add an iptables rule to DROP all multicast traffic going out over virtual network interfaces (tun interfaces), we get very strange behaviour when enabling app tracking protection. The main issue is that we lose connectivity entirely. A secondary, but also very serious issue, is that your app generates a massive amount of spam out over wlan0 to IP addresses close to and within the multicast address range. An example packet capture:
07:54:04.659396 IP 192.168.1.254.40145 > 239.209.34.115.14658: UDP, length 133
07:54:04.659449 IP 192.168.1.254.34718 > 224.14.133.25.36679: UDP, length 39
07:54:04.659519 IP 192.168.1.254.53789 > 229.99.133.98.9412: UDP, length 35
07:54:04.659648 IP 192.168.1.254.45559 > 227.252.32.107.6473: UDP, length 116
07:54:04.659716 IP 192.168.1.254.56686 > 240.200.84.91.44530: UDP, length 55
07:54:04.659834 IP 192.168.1.254.47087 > 231.7.67.92.24432: UDP, length 200
07:54:04.659864 IP 192.168.1.254.52807 > 255.67.86.48.3335: UDP, length 52
07:54:04.659875 IP 192.168.1.254.54221 > 243.245.38.121.46521: UDP, length 68
07:54:04.659894 IP 192.168.1.254.34298 > 255.222.189.62.33198: UDP, length 70
07:54:04.659958 IP 192.168.1.254.55256 > 236.242.208.65.31138: UDP, length 59
07:54:04.660011 IP 192.168.1.254.49704 > 225.248.160.64.8507: UDP, length 97

Some of these packets are strange and suspicious, such as:
1950 22.865055 192.168.1.251 232.83.57.38 WireGuard 134 Handshake Response, sender=0xA1BEF649, receiver=0xC8670719
2508 25.276994 192.168.1.251 224.207.235.86 KPASSWD 100 Unknown command[Malformed Packet]
2758 26.445040 192.168.1.251 228.185.144.71 QUAKEWORLD 151 Client to Server Game

I have had a look at the source of your app, but can't find what is causing the compatibility issue, or the spam. Are you able to provide some insight into what is happening?

Fixing the multicast leaks is still a work in progress, but the changes relevant to the compatibility issue with your app can be found here GrapheneOS/platform_system_netd#6

Here is some more information about the leaks GrapheneOS/os-issue-tracker#3443

Thanks.

How to Reproduce

Build GrapheneOS from source after manually applying the linked PR patches and enable app tracking protection within the app.

Expected behavior

App tracking protection is enabled without any issues and there is no multicast spam.

Environment

- DDG App Version: 5.214.1
- Device: Google Pixel devices
- OS: GrapheneOS

[github-actions]

Thank you for opening an Issue in our Repository.
The issue has been forwarded to the team and we'll follow up as soon as we have time to investigate.
As stated in our Contribution Guidelines, requests for feedback should be addressed via the Feedback section in the Android app.

[aitorvs]

Hey there, thanks for reporting.
It's weird that AppTP causes any issue with multicast, as the multicast range is specifically excluded from going through the tun interface (ie. we're excluding 224.0.0.0 to 239.255.255.255 IP range)

A secondary, but also very serious issue, is that your app generates a massive amount of spam out over wlan0 to IP addresses close to and within the multicast address range.

Similarly, we also exclude private local IP range (ie. 192.168.0.0 -> 192.168.255.255) from going through the tun interface.

[u-fred]

I think you've misunderstood what I'm saying. My understanding of the situation has progressed, so I will give you all the information again.

GrapheneOS is going to ship fixes for multiple different multicast leaks (refer to links above). Your app has a compatibility issue with one of our fixes, and no other apps have this issue. Unless you get involved and assist me in identifying the issue, I will have to recommend to Graphene that we add an off-by-default compatibility toggle that your users will have to activate in order to use app tracking protection on Graphene. This is bad for your users because many of them won't be aware of the toggle and will assume your app is faulty. They will also not get the benefit of multicast leak protection when using your VPN. We would like to avoid both of these issues.

There is a separate but related issue which I am recommending you take very seriously for the sake of your users. In debugging the compatibility issue, I have noticed that your app is doing something very strange and potentially malicious. What is happening is that your app is enumerating the IPv4 address space and spamming huge amounts of UDP packets over wlan0. The packets are being generated by the DuckDuckGo process/UID itself, so the VPN routes are not relevant. The contents of some of these packets is concerning. See above post. Note that in the previous post I mentioned that the spam was limited to multicast traffic, but I was wrong.

The particular change to Android that is causing both the compatibility and spam issue is that we have used iptables to DROP multicast traffic going out over tun interfaces. It's strange that this is the cause, as I can't find any instance of your app intentionally sending multicast over tun. I think it is highly likely that a dependency of your app is doing something without your knowledge and you should look into this. Hopefully it is just a bug, but some of the packets sent make me think it could be something malicious.

The spam is extremely heavy and consistently takes my local network down. It may be that the compatibility issue is really just that the spam overloads the local router which appears as a connectivity issue. So, we just need to figure out where the code that is generating the spam is, and then we can ship our fix without compromising your app.

[aitorvs]

Thanks for the reply. Will try to bring some clarity, please lmk if I miss something

The particular change to Android that is causing both the compatibility and spam issue is that we have used iptables to DROP multicast traffic going out over tun interfaces.

App tracking protection (AppTP) purposely excludes multicast traffic from going out over the tun interface. You can see IP config table in https://github.com/duckduckgo/Android/blob/develop/app-tracking-protection/vpn-impl/src/main/java/com/duckduckgo/mobile/android/vpn/service/VpnRoutes.kt

It is the same (same file) for private local IP range (ie. 192.168.0.0 -> 192.168.255.255), ie. we also instruct Android to not route that traffic through the tun interface.

So in principle, your changes in GrapheneOS should not affect AppTP, as we instruct Android to not route any of that traffic through the tun interface.

spam on private local network going out wlan0 interface
1950 22.865055 192.168.1.251 232.83.57.38 WireGuard 134 Handshake Response, sender=0xA1BEF649, receiver=0xC8670719
2508 25.276994 192.168.1.251 224.207.235.86 KPASSWD 100 Unknown command[Malformed Packet]
2758 26.445040 192.168.1.251 228.185.144.71 QUAKEWORLD 151 Client to Server Game

Can you explain a bit your setup to get those packets? ie. how do you install our app, how do you enable AppTP etc. and how do you log the packets.
The first packet seems to be a wireguard handshake packet, but AppTP is not a VPN and doesn't use wireguard protocol so that packet could not come from our app.
The other two packets are also not coming from our app, eg. we don't talk to quake servers, unless ofc the user plays that game online through our browser

[u-fred]

We've identified the issue with your app and have been able to work around it without compromising privacy.

We added a rule specifically for your VPN:
https://github.com/GrapheneOS/platform_system_netd/pull/7/files#diff-20eaef28e8ab6f5453bed4bf1f7a228ffa241a03d8336a458af799c267322b34R116

Please read the comment above that rule that explains the problem. My guess would be that it is related to your app creating 2 tun interfaces when AppTP is enabled. It appears for some reason you're relying on data being immediately available on the first tun.

so that packet could not come from our app.

I assure you all those packets came from your app.

[aitorvs]

We've identified the issue with your app and have been able to work around it without compromising privacy.

Thanks for that, appreciate it.

It appears for some reason you're relying on data being immediately available on the first tun.

Ah yes, we create a null tunnel (hogs and drops all traffic) while setting up the proper tun interface to avoid apps leaking trackers while we setup the protections.

assure you all those packets came from your app.

If what you mean is that packets are sent from our app in a strict sense then yes, we intercept (by means of tun interface) and forward ALL packets from ALL the protected apps (except packets flagged as trackers that are dropped).
But we do not originate packets like eg. QUAKEWORLD. Our app is open source can be easily verified.

Closing the issue as it seems resolved.
Thanks again

[u-fred]

If what you mean is that packets are sent from our app in a strict sense then yes, we intercept (by means of tun interface) and forward ALL packets from ALL the protected apps (except packets flagged as trackers that are dropped).
But we do not originate packets like eg. QUAKEWORLD. Our app is open source can be easily verified.

The traffic is likely randomly generated, as your app is doing a random enumeration of the IPv4 address space. I am certain that the traffic is generated by your app, and not that it is traffic sent over the tun by another app. If you require proof of this, or need further assistance fixing your poorly-implemented VPN, feel free to reach out and we can discuss my rate.

[aitorvs]

Appreciate it. Thanks again!