alt Hacker News0-click deanonymization attack targeting Signal, Discord, other platforms
Comments
Cool writeup with some interesting techniques and approaches!
I'll echo the other comments and say "deanonymization" is stretching the definition of the word, along with "grab the user's location", as it isn't anything near precise. 150 miles is approx. a 2-hour drive on the highway from Atlanta, GA to Augusta, GA. In that radius, there's probably 700,000+ people.
I do think the auto-retrieve attachment feature of Signal is slightly concerning, as for a private messenger I'd expect there to be an option to turn it off (like turning off JS in Tor). I don't know if I'm not looking deep enough, but there doesn't seem to be a feature for that.
Signal appears to take a useful-by-default approach that balances privacy and ease-of-use in order to encourage adoption by the masses, I'd assume most people that are really concerned are hardening Signal, similar to what is in this guide: https://www.privacyguides.org/articles/2022/07/07/signal-con... . They've always recommended a VPN / proxy + a modification of settings for more high-security scenarios.
Caching isn't going anywhere, and neither is CloudFlare. The DoSing days of old in P2P multiplayer lobbies with exposed IPs seemed to carry more of a threat than this, CloudFlare's response seems to be the best out of the 3. Caching sensitive information is never recommended and the onus is on the application doing the communicating to tell their CDN / middle-service to not cache specific items.
Cool! Contrary to some of the other posters I think this definitely counts as deanonymization, or at least is close enough. How anonymous would satoshi be today if we had his location to within 250 miles?
Repeated applications of this attack (maybe disguised somehow?) could let you track someone’s travel over time, and it is usually only takes 4-5 zip code sized locations to uniquely identify someone.
Not sure why so many top comments dismiss the severity of this. This is just exactly the type of attack that give law enforcement or a malicious actor a way to establish proof of whereabouts.
Note: this person is the same 15-year old who found the Zendesk Slack takeover exploit a few months ago [1].
Why has Signal even enabled caching for those URLs? The most common case is going to be that the attachment is downloaded once, and that's it.
I would even expect that Signal wouldn't allow you to download it more than once, and would immediately delete it after the first successful download. Well, ok, maybe the client fails mid-way through, so allow some grace period for a re-download. But I can't imagine that would be the common case either, and so disabling caching on their CDN would fix this issue, and hopefully not increase their costs much.
At any rate, "deanonymization" is a bit clickbaity here. Narrowing someone's location to within 250 miles or so isn't great, but it doesn't deanonymize them.
Edit: I didn't think about the case where an attachment is sent to a group chat, where multiple people will be downloading it. But in that case wouldn't the attachment be encrypted individually for each person in the group? I'm not sure how this works, of course.
This is certainly an "attack" but not one you'd normally associate with zero click. There is no code execution, but some tricks to see which Cloudflare datacenter cached the image -- giving a very rough area the user is in. Impressive and insightful nonetheless.
Unless I'm missing something, this seems like an incredibly long winded way to check the users IP location?
For example, connecting to a VPN and checking https://cloudflare.com/cdn-cgi/trace gives me `colo:CPH` (Copenhagen) which is far from my nearest CF datacenter (geographically), closer to the IP location from my VPN provider (Oslo) but still not particularly close?
If I don't use a VPN, I don't even get the capital city of my country (which I'm in right now), I get a colo approx 250 miles north. So I also dispute that Cloudflare always returns the "nearest available datacenter".
Don't get me wrong, the write up is cool and certainly interesting - just not convinced on the real world applications here...
I'm a bit at a loss there. Has _anyone_ ever considered Signal to be anonymous? Or Discord? If so, I have bad news: they are not anonymous. At all. Not even slightly anonymous. Nor did they ever claim to be, they only claim to not be able to read your messages (Signal claims that, I don't know about Discord, I doubt it). And that claim has flaws (sure the crypto is sound but have you thoroughly reviewed and compiled the version you are using right now?)
At the very best, they are weakly pseudonymous, but that's about it. And yes, loading media by default has always been a staple of applications who prioritize their users' convenience at the expense of some security, a fine choice for the usual threat model of their users. And embedding media in messages has always been a staple of deanonymization attacks.
So ok, the tracking pixel has been shown to still be a relevant technique today, that's nice but not surprising.
If you want to remain anonymous though, don't use Discord or even Signal, and I'd advise against posting on HN either. Maybe, if you automate the pasting of messages (no js!) that has been reworded by a local llm from throwaway accounts through whonix, at random times that can't be correlated to your timezone, you _might_ have your chances. Don't bet on it.
Anonymity does not exist any longer.
What is the benefit of caching images in a cdn for Signal?
Assuming local client-side caching, the total number of requests for that resource should be very small, probably one in the vast majority of cases.
On an unrelated note, it seems like CloudFront could very easily fix this by not returning the cf-ray header, or at least having an option for the customer to remove it. Although, it might still be possible to get that information based on timing information...
Looking at the locations where Cloudflare has their servers [1] in the middle of Europe. With Geneva, Zurich and Munich there is definitely the possibility that this attack on Signal will leak whether someone is at home or not.
I don't understand how Signal could dismiss this so easily. I'm starting get a bad feeling about their responses to these "low" stakes attacks. They already missed the ball on the database encryption mishap on desktop.
This is just the fundamental way the internet works, and is the reason that anonymizing proxies like Tor exist.
If you don’t want people to be able to detect your rough geographic location, you should be using a proxy to hide it. For everybody else, knowing the edge server you are closest to is really not a threat.
Congrats on finding this. Very impressive for a 15-year-old!
The section "How to Protect Yourself" is lacking.
Step 1. Don't receive this information in the push message. Only send the fact that there is something waiting for you in the app. Chances are there are other vulnerabilities that compromise the end-to-end encryption guarantees provided by the app (and only by the app).
In Signal on iOS: Click on your icon in the top left corner. Click on settings. Click notifications. Click on display below "message contents". Make your choice.
Another situation where convenience clashes with security, unfortunately.
This is quite a detailed write up. I went through the post quickly, but didn’t get why Signal would just download an attachment from an unknown number/contact without first prompting the user to accept or deny the conversation request. I’ve seen conversation requests always waiting for me to accept or not. If I don’t accept, I don’t see any messages on that chat and the other person doesn’t get any indication of message delivery. What have I missed?
If the message is from a known or trusted contact, I think there can be larger problems than just a rough location reveal.
So, it's like the [Spectre] attack against CPUs: trigger an access from a privileged context, check if the access has filled in some cache, infer privileged information from that.
It seems that time and again, security-enforcing procedures assume that many functions they invoke are pure, but in reality these functions have side effects, and these effects are observable much easier than the security requires.
The actual problem here that the secured area is only the stuff that came through the encrypted channel. Any access beyond it, like following a link, is obviously insecure. If the link was sent via the secure channel, it becomes even less secure because it allows to observe a correlation between the secure channel (otherwise impenetrable) and the insecure outside context, and allows to blow (some of) the cover. Opening links via Tor would mitigate it a bit.
The hard truth here is that almost everything may have observable side effects, so opsec needs to permeate all aspects of life, the more cover you need, the fuller. This is mostly incompatible with a convenient UX, but, to be popular, a secure messenger has to be reasonably convenient. This necessarily limits the level of security attainable by its casual use.
[Spectre]: https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
So many comments get caught on the wording 'deanonymization'. Is there a standardized definition of 'deanonymization' accross industry experts, privacy-conscious people and hackers?
For many commenters, it looks like deanonymization means unveiling highly sensitive info like name, address, email, etc.
For privacy-conscious individuals and hackers, it looks like it means 'revealing a data point that shouldn't be revealed'.
As a signal or Discord user, I would expect my country location not to be revealed to a person I don't know. So the latter definition makes sense to me.
A fun attack, but I don't think this is a significant improvement over the existing state of the art using delivery receipt timings ("Hope of Delivery"). https://arxiv.org/pdf/2210.10523
Am I correct in surmising that someone who uses aVPN on their phone, while sending Signal messages/ content, would be cloaked, provided the VPN server they pick isn't near them ?
Usually, being identified as being part of such a huge group that there is no chance of being found is an example of anonymization, rather than deanonymization. The author might not like that there is any potential to narrow things down at all, but the information provided by this could be easily wrong if a VPN were used to have the traffic egress through a different geographic region.
Clever finding but the title does no justice to the actual attack. Even a bare minimum threat model requires a user to use VPN or Tor which completely eliminates your "0day". Signal rightfully declined your report because it's only job is to provide secure communication
Hmm "within 250 miles" is not deanonymization in my book. Unless you live in the middle of the desert. In which case there won't be a cloudflare DC near you anyway.
It's nice but at most will give you an indication of city. Perhaps together with some additional OSINT you could find the user but you'll need a lot more clues.
Well found though!
> This would provide an incredibly precise estimate of the user's location.
Within ~250 miles of their location is not "incredibly precise"
I guess I'm not so "crazy" for funneling all my Android's outbound traffic through a VPN that does two hops.
What's old is new. Does anyone remember the forum signatures that would display the viewers IP address and location on a little wooden signpost held up by a troll-looking creature?
The accuracy of this geolocalization depends very much on peering agreements.
I don't know about the UD bit this will not be very accurate within the EU.
As an example: In Hungary, there's pretty much only one peering hub (bix) and there's only one Cloudflare datacenter. You've already geolocated me better than this hack just by knowing my language or phone prefix.
Is there any reason other than debugging purposes that the cf-cache-status and cf-ray headers are included in every response? Why don't they remove those unless a debugging setting is enabled in the CloudFlare dashboard?
If I use Signal or Discord to send someone a link to anything hosted on a server controlled by me, provided that the user opens the link, I will get an exact IP address of the user. IP address is much more useful in de-anonymizing the user than the nearest CloudFlare datacenter location.
This is pretty interesting, and well documented. Great work! I wonder if there is a way to turn off notifications or if the approach is to simply not run such apps.
It seems to me that a key requirement for this attack is that both the attacker and the victim load the same link, that is, that the attacker knows the URL the victim is going to load. If Signal/Discord created a different link to be given to the victim, and never shared it with the attacker, this attack wouldn't work.
That could be as simple as adding some extra pseudo-random parameters to the URL which will be ignored by the origin (but honored by the caches), or as complex as creating a completely separate URL for the receiver of the message, and somehow giving it to the receiver without giving it to the sender (easy on Discord, harder on Signal due to its end-to-end nature).
I guess one possible fix would be for cloudflare to implement an option to disable the x-cache header for unauthorised users. This way Signal devs could still check their setup by sending authentication headers.
But it would solve the issue completely because you could always check the response time. Probably Signal should disable caching. I guess it's rare for someone to repeatedly download an attachment. Once it's there it's there. For grouped conversations it could be an issue though.
Cool writeup by a 15yo, except for the way it completely oversells in the title.
Basically this allowed an attacker to find out which cloudflare data center a victim connected to when being tricked into loading something from cloudflare. This is often within a 250 mile radius of where they're living but not necessarily.
Can't one find out someone's IP just as easily by making them make a request to a URL controlled by an attacker? Is the problem that cloudflare is whitelisted for 0-click?
> When a user sends an attachment (e.g., an image) on Signal, it is uploaded to cdn2.signal.org.
Why is that even the case? I had understood that (binary) attachments are embedded into the encrypted message and hence transferred directly from sender to receiver.
Obviously, retrieving media from an external location saves bandwidth at multiple positions. I am not a security expert, but it seems almost trivial to see how storing message data on an external server conceptually facilitates attacks like this one. Isn't that the same reason a link preview is generated at the sender first and then embedded into the message as an image?
There was mention that the Teleport tool no longer works after the bugfix of the underlying issue (calling other cf locations via Workers and an internal subnet). It seemed like the ability to query which caches HIT on the dye-test image relied on being able to call out to each other DC.
Without this control over the route (driving the probing of which caches were hit), the attack would no longer work, right?
Wouldn't other user that sees the other person's profile picture also drum up the cache? This wouldn't work for someone in a large server.
While not 0-click, this might work even better using DNS and a more dense network of anycast DNS servers delegating a subdomain. Send a link to the target, and the DNS resolve should end up at your anycast DNS server. Respond with a CNAME entry, triggering a second DNS request and you can determine at which DNS server the request was served.
Would also work without anycast (and thus probably able to use a very dense botnet) and long list of NS entries for your domain.
I believe in reality it's a bit more complicated
CDNs do not choose datacenters for users based on a geographic distance. The number one metric is latency but latency != physical distance. Second metric is optimizations of price of data transfer between peers and IXPs which results in very dynamic routing rules. Then consider also network/software hickups/maintanance and distribution of datacenters' load...
I think this is a valid observation and the affected apps should either add auth to resources they control - shared or not - or use an UUID to store it so names can't be guessed.
This only works because the attacker knows the URL.
Guess what: you don’t need cloudflare
Is he just 15? The level of technical details, and this part is not that simple: “quickly patched the Signal desktop app to remove SSL pinning and configured Burp to intercept and view HTTP requests/responses sent through the app”
How is it different than sending someone an image hosted on your server which is a tracking pixel and just get their IP+location?
This will be more accurate than the cloudflare approach.
"deanonymization" in this case is just plain wrong, you can't even tell which country the user would be in for sure. Also any proxy/vpn will completely protect against this.
It's "a very rough estimation of a user's location when they are not using a vpn".
I guess signal preview-loading or remote-image-loading features are always going to be usable to identify broadly what region a user is in, using this attack.
Can one disable those features in Signal? Would be annoying becuase they are nice, but yeah.
If you don't want that attack to be able to locate you somewhat (or at least locate your internet endpoint, if you are using a VPN or something), you will need to turn off signal previews and network image displays. Right?
Can probably achieve the same level of deanonymization by just monitoring what times the user communicates most often. Or send them enough links that they'll click on.
I'm sure this is nice to find what city/country someone is but not what I consider "incredibly precise"
2 questions - why do airports get cached with Cloudflare requests, and, if I use a VPN, am I getting content from my usual Cloudflare centre or the one from the country on the VPN I’m using?
Looks like Cloudflare are still sending out the airport locations and hit status on the response headers. Maybe I'm missing something but it seems like if you had a large VPN network you could run a distributed query to figure out which edge nodes have cached the url.
Not exactly the same type of attack, but very similar https://cyberinsider.com/timing-attacks-on-whatsapp-signal-t...
I remember iOS not always respecting VPN's do these notification attachments get loaded through a VPN?
So if you send a picture to a Signal user, it's retrieved via cloudflare, and cached in a data center near that user; now you can look up the cache status and find the data center used. I'd say "deanonymization" is stretching it, unless the user is in the middle of nowhere (no other users near the data center). But interesting writeup anyway.