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.
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.
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.
Note: this person is the same 15-year old who found the Zendesk Slack takeover exploit a few months ago [1].
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.
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.
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.
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...
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.
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...
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 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.
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...
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?
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.
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
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!
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.
"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".
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
I guess I'm not so "crazy" for funneling all my Android's outbound traffic through a VPN that does two hops.
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.
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?
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?
That's a 15 year old.
I can't even convince what the gouvernements are able to do. You could technically route signal over tor network but then even tor has vulnerabilities with it's C coding.
So the default option of using onion routes to hide your IP and location still works.
I think all these things are absolutely ridiculous.
I use alpine (the email client, not the Linux distro). Before that, I used pine.
Every single thing that gets loaded from anywhere on the Internet has to be the result of an action that I take. Nothing ever gets loaded automatically. I get to choose if I load the thing using the server that I'm connected to, or if I load it directly on my local machine. I know the implications of each.
The fact that programs, particularly ones that are supposed to be for the security minded like Signal, load anything by default, automatically, is just, well, naive.
I can't be the only person who thinks that people who don't think these things through shouldn't be working on apps and email clients. Sure, people would have a cow if their email client didn't load every frigging thing and run remote Javascript and so on, but in Signal? Really?
(end rant)
I see that this can be turned off. I will now tell everyone I know that uses Signal that this should, in fact, be turned off.
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.
I hate how teenagers can't help but post their age when it comes achievements like it makes them special. 'hai im 15 and i hack billion dollar companies in my spare time.' This is cringe AF. I don't care if they're "only a teenager." Presumably, the age was written to signal how le special they are and not liek other teenagers. So if you want special treatment learn how to be modest and don't over-exaggerate your achievements. Any adult who managed to read past this sentence is a bigger person than I am.
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.
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.
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.
de-anonymization attack?
- The information extracted is a rough 250 mile radius around the user
- The attacker already has a way to contact the person (signal username / phone number)
Intersting reading, but also seems like technical clickbait.
Not exactly the same type of attack, but very similar https://cyberinsider.com/timing-attacks-on-whatsapp-signal-t...
"Luckily" my ISP is DTAG which has horrible peering with Cloudflare. So I'm routed through Warsaw (WAW) most of the time, even though there are multiple closer datacenters in Germany.
Imagining the cloudflare datacenters as cachelines and this is just like a side-channel attack like spectre. Not as fine-grained but still cool stuff.
You could use this technique to see what geographic areas view what sites based on the content cache age, you would have to have the list of sites, but it would allow you to bucket a geographic by top sites from the test corpus.
Impressive write-up, especially for your age! Thanks for sharing :)
Anyone send Snowden a push notification? Would be interesting to see if he's still in Russia...
Unfortunate that Cloudflare patched the issue enabling specific datacenters to be targeted. Would have been extremely useful for finding the location of servers behind Cloudflare.
Just by the fact he's expressing distances in miles, I can say he's from USA.
That's my 0-click deanonymisation.
Nice attack otherwise.
I think its good for finding out if someone is still in a certain region. More like region identification not deanonymization.
Cloudflare's business model is fingerprinting as a service. Awesome.
“deanonymization”
Hardly.
Amazing sleuthing but not deanonymization.
This doesn't strike me as a new 'attack' (I have to imagine there's even a name for such attacks), and 250 miles seems a large radius to 'deanonymize' someone, even a high-value target (even if such people didn't take any other measures to avoid being tracked...)
For reference, here's a 250 mile radius around Toronto Canada https://i.imgur.com/ydpR0IZ.png
Would be very interesting to see how other IM behave with this:
For example: Jami - one of the most feature-complete, distributed IM...
If you need to deanonymize a user who moves around a lot, this method makes sense.
this is pretty devastating for signal
Nice work OP, and congrats on HN front-page. Keep publishing or it never happened!
It's a classic timing attack. You can detect which Cloudflare datacenter is "closest" (ie. least network latency) to a targeted Signal or Discord user.
The speed of light is the main culprit here.
Great job, you're going to go far Daniel.
Surprised that was only worth 200 bucks.
why is the picture not simply cached near the sender as opposed to the receiver?
is there any good reason for deciding this way on the part of Signal et al?
very impressive findings
Presumably cloudfare will close the loophole for enumerating cache edges now.
This is an extremely cool avenue of attack, I love the bot/demonstration.
is simplex immune?
Pretty impressive work.
Why does CloudFlare return whether it was a cache hit or miss? This information could be hidden/removed. I understand it's not a complete solution of the issue, because cached responses will return much faster than non-cached ones, but it's a step in the right direction.
why signal even have that side channel???
even matrix encode image and other data in the e2e p2p message flow
impressive
> it's possible for an attacker to run a cache geolocation attack to find out which local datacenter they're near--similar to how law enforcement track mobile devices through cell phone towers.
very much disagree on this, they track mobile devices through your connection strength to multiple cellular towers while this attack proves which singular datacenter the victim is nearest.
Don’t get me wrong the write up is really interesting but it does feel like the author is a bit of a sensationalist.
"Signal instantly dismissed my report"
"Telegram, another privacy-focused application, is completely invulnerable to this attack"
"Discord […] citing this as a Cloudflare issue other consumers are also vulnerable to"
"Cloudflare ended up completing patching the bug"
I wish Signal would react differently. I still remember the bubble color controversy when they changed their mind after the backlash and not before. :-)
[dead]
For being 15 year old, cool work!
But calling this de-anonymization is a stretch, if it can possibly pinpoint you within 250 miles (that's assuming geoip is correct too, which it rarely is).
In their GeoGuesser demonstration video, the higlighted area is densely populated and you still would need to match millions of people vs the online user.
It does provide some hints as to the location of the targeted user, and that is cool!
[dead]
[flagged]
[flagged]
> 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?