0-click deanonymization attack targeting Signal, Discord, other platforms | Hacker News Reader

0-click deanonymization attack targeting Signal, Discord, other platforms

gist.github.com

1,457 pointshackermondev438 comments

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.

"Near a user" is also a big assumption. I'm ~200 miles to ORD and ~500 to IAD, but my ISP's peering & upstream arrangements mean Cloudflare serves my traffic 700 miles from DFW.

But, at the same time: Cloudflare isn't going to serve me a cache from Seattle, Manchester, or Tokyo. Pinning down an unknown Signal user to even a rough geographic location is an important bit of metadata that could combine to unmask an individual. Neat attack!

It's also quite insidious as you don't need to control anything on any server to get this information; as long as you can get your target to load a unique URL never before loaded by anyone else, you can simply later poll it with an unauthenticated HTTP GET from different locations, and find which one reports a Cloudflare HIT (or, even if they hid that information, finding the one that returns with lower latency).

If you're allowing user uploaded content, and you use Cloudflare as a CDN, you could mitigate and provide your users with plausible deniability by prefetching each uploaded URL from random data centers. But, of course, that's going to make your Cloudflare bill that much more expensive.

Cloudflare could allow security-sensitive clients to hide the cache-hit header and add randomized latency upon a cache hit, but the latter protection would also be expensive in how many connections must be kept alive longer than they otherwise would. Don't do anything on a personal device or account if you want your datacenter to be hidden!

Pre-fetching also becomes an issue for apps that are meant to be e2e encrypted, since it requires the server to download (read) every attachment. But if the app is already caching the attachment then they’re effectively reading it anyway.

(EDIT: Apparently signal e2e encrypts images prior to upload, so pre-fetching the encrypted blob from one or multiple servers would in fact be a mitigation of this attack.)

I do wonder if Telegram is as invulnerable as the author assumes. They might not be using Cloudflare for caching, or even HTTP, but the basic elements of this attack might still work. You’d just need to modify the “teleport” aspect of it.

Going forward uploaded content should never go through cloudflaire and it never really needed to.

Add unique urls.

Maybe just avoid it altogether.

Note that CF will also route relative to the sites' plan. Enterprise sites are almost always routed to the closest DC, while if that DC is overloaded then lower tier websites, typically just Free sites, will get routed elsewhere (I suppose this is achieved via different anycast ranges where a specific DC is excluded). Although Discord, Signal, etc are almost certainly Enterprise sites.

I have this old site to test this (the list of sites is a bit old): https://cloudflare-test.judge.sh/

WTF? the trace endpoint allows CORS from any origin?!? Why?!

I doubt how useful it would be as an attack. As a single point of info it tells you next to nothing. As part of a composition of other indicators it would be the weak link in the chain probably just causing noise for the not un-likly scenario where the person you're targeting is using a VPN.

If it was any less specific we'd be talking about a deanonymization attack that outs whether or not a target is still on Earth.

Oh, this attack would be a useful tool for e.g., identifying whistleblowers that travel a lot (e.g., in academia, military). If you know their Signal ID, you could send them images from time to time and then compare their coarse locations with travel information for a number of suspects.

> not un-likly scenario where the person you're targeting is using a VPN

Do you think a large proportion of Signal users also use VPNs? I'd expect it would be a higher proportion than the general population but still only a small minority.

for "normal people", that's a pain, but with enough resources,...

Although. it has edge usecases even for "normal people":

Eg. you suspect your coworker to be catfishing you on eg. discord, you know that he's in your city now, verify, then wait for him to leave for a vacation to somewhere abroad, check again.

This is actually pretty smart, and shows that this exploit could be chained with other information to identify a specific individual. This could also be used to e.g. check which world-travelling reporter is communicating with you.

It's not an edge case. Using multiple sources of information to paint a more complete picture is the norm. That's how marketing profiles work, for example.

Cloudflare does serve me from France. When I'm in Australia. (My ISP bought some IP addresses that were original regional France, back in the early 90s.)

So though this does have implications, the assumptions they utilise, like always, are not universal.

> My ISP bought some IP addresses that were original regional France

CLoudflare uses anycast, and IP geo location is not how anycast works.

Wow doesn't that make things really slow due to the RTT of the acknowledgements?

It gets more interesting when you think about the impact on groups. Sending an image to a group is enough for all devices associated with that group to be identifiable from CloudFlare's side, who additionally see a giant chunk of unencrypted traffic from the same client addresses going to other web sites. Given Cloudflare's less-than-straight approach to sales, it is astonishing the words "secure" and "Signal" ever appear in the same sentence.

CloudFlare get to see a fuckton of metadata from private and group chats, enough to trace who originally sends a piece of media (identifiable from its file size), who reads it, when it is is read, who forwards it and to whom. It really doesn't matter that they can't see an image or video, knowing its size upfront or later (for example in response to a law enforcement request) is enough

> Given Cloudflare's less-than-straight approach to sales, it is astonishing the words "secure" and "Signal" ever appear in the same sentence.

This is an overly binary take. Security is all about threat models, and for most of us the threat model that Signal is solving is "mainstream for-profit apps snoop on the contents of my messages and use them to build an advertising profile". Most of us using it are not using Signal to skirt law enforcement, so our threat model does not include court orders and warrants.

Signal can and should append some noise to the images when encrypted (or better yet, pad them to a set file size as suggested by paulryanrogers in a sibling comment) to mitigate the risks of this attack for those who do have threat models that require it, but for the vast majority of us Signal is just as fit for purpose as we thought it was.

Hello, I'm an organizer for a system to coordinate multiple mutual aid networks, many of which are only organizing by Signal & Protonmail exclusively because they think they're secure and private.

People who are doing work to help people in ways the state tries to prevent (like giving people food) rely on this tech. These are the same groups who were able to mobilize so quickly to respond to the LA fires, but the Red Cross & police worked to shut down.

This impacts the people who are there for you when the state refuses to show up. This impacts the future version of you who needs it.

Most people aren't disabled, yet. Doesn't mean they don't need us building infrastructure for if/when they become disabled.

Maybe not individual warrants (at least not warrants to do non-scalable collections like hardware bugs in one's phone - I.e. warrants that, most users, with high probability, are not subject to). But mass surveillance, e.g. NSA, even with 'mass warrants' (e.g. Verizon-FISA warrant), that everyone is subject to, is probably in most people's attacker model. I don't have a study handy, but it seems reasonable that most users use signal to protect against mass surveillance and signal advertises itself as being good for this.

Also Marlinspike and Whittaker are quite outspoken about mass surveillance.

If cloudflare can compile a big part of the "who chats with whom" graph, that is a system design defect.

> Signal can and should append some noise to the images when encrypted (or better yet, pad them to a set file size as suggested by paulryanrogers in a sibling comment) to mitigate the risks of this attack for those who do have threat models that require it

Adding padding to the image wouldn't do anything to stop this "attack". This is just watching which CF datacenters cache the attachment after it gets sent.

I think the threat model of enough signal users to matter is nation-state actors, and signal should be secure against those actors by default so that they may hide among the entire signal user population

>It gets more interesting when you think about the impact on groups. Sending an image to a group is enough for all devices associated with that group to be identifiable from CloudFlare's side,

Doesn't this open up the possibility to identify groups that have been infiltrated by spies or similar posers? If you use this method to kinda-sorta locate or identify all the users in your group and one or more of those users ends up being located in a region where you should have no active group members then you may have identified a mole in your network.

Just thinking out loud here since there's no one else home.

>If you use this method to kinda-sorta locate or identify all the users in your group and one or more of those users ends up being located in a region where you should have no active group members then you may have identified a mole in your network.

...unless they happen to be using a VPN for geo-unblocking reasons or whatever.

I wonder if we'll see assets being padded to some common byte sizes to combat this.

Hi there, Signal dev here. We do, in fact, pad attachments to a limited set of bucket sizes.

Nothing stops Cloudflare from inspecting the file contents, or using a hash to distinguish between identically-sized files.

The only reason we assume they don't do this is because it's a waste of resources for no good reason. But what if somebody gave them a good reason?

> , it is astonishing the words "secure" and "Signal" ever appear in the same sentence.

You misspelled "I do not understand what end to end encryption means"

It could be useful for correlation.

Say for example that you're an investigating agent in regular contact with someone.

A single data-point wouldn't mean anything. However, a sequence of daily image retrievals might tell you that they spend 90% of their time in WA and 10% of their time elsewhere.

That information alone still might not mean anything, but if you also have a specific suspect in mind, it may help confirm it. Or if you have access to the suspected person directly, if you're able to also befriend their "clean" profile, you might be able to pull the same trick and correlate the two location profiles.

De-anonymisation isn't about single pieces of information, but all information helps feed into a profile to narrow suspects or confirm suspicions.

( By "agent" I just mean a person, not an AI agent nor Law enforcement, who could presumably just get the information more directly from cloudflare. )

There's probably at least a few instances where you send someone you think is American a picture but it gets cached in Moscow, or vice versa. Or you post a meme to a Californian left-wing group and it gets cached in DC. Not hard to imagine situations where getting an unexpected rough location could be a valuable signal.

you don't have to "befriend" them. you send a friend request because that defaults to a push notification for users with the discord app on their phone. Now, with signal, i don't use it so i don't know how initial chats start, or whatever. The discord one is 0-click because the PFP in the friend request is the payload delivered via PUSH.

And to someone else's point - they had to block the request on their end with a MITM to do the 1-click version on signal. No such MITM is needed with the friend request.

As an aside, one time i got doxxed hard in an IRC channel with several hundred active users. I had a suspicion of who it was, and i knew they lived in chicago. So i "accidentally" sent a link to "screenshot proof" that was hosted on one of my domains. there was 1 immediate click. instant. Chicago. "accidentally" because it looked like i pasted an email body.

Packed the real screenshot and a complaint to the ircadmin. they said "and so you dox them back?"

can't win for trying.

You can also ping the same person multiple times, like once a day at different time of the day. That provides a more complete range.

It's not stretching it. The expectation is that Signal does not reveal any observable aspect of your IP address or location when receiving messages on it.

Whether this specific level/type of deanonymization is a problem for your particular use case is an entirely different question. Personally, I wouldn't even care if mutual contacts were to see my IP address outright (and they do for calls), but I'm not every user.

I don't care if users see "my" ipv4 because cgnat. I think i don't care if they can see my ipv6 because each machine gets a /64 to itself, that's the logic, right?

But my PBX and my matrix server both use coturn. Our 10 user "private" PBX we have to VPN into a fortigate in a DC to use, but to my understanding, there's literally no way to eavesdrop on those calls without already compromising the server it's running on, and if that's the case, no extra VPN steps or whatever will help.

anyhow even with a real, publicly routable IP, stock windows 11, stock macos (used to be true), and most linuxes won't get compromised by stuff like backorifice or whatever else l0pht put out as "remote administration tools". that is, there usually isn't any listening ports on a public IP these days. Shield's Up!

Exactly. Especially when considering that Signal was often advertised as that *one* privacy friendly open-source messaging solution in a world dominated by data-collecting demons like WhatsApp, etc. I don't think even WhatsApp let's such status details leak; notwithstanding whatever they might be doing with the user data on the backend.

"Deanonymization" doesn't have to refer to a full exact address. There are people who wish to conceal which country or region they live in, which this cripples.

There was a real example of that amount of information being relevant in the Silk Road investigation. Ulbricht accidentally revealed his timezone early on, which was useful to US authorities since it narrowed him down to being in the US, whereas without that information he could have been from anywhere in the world.

Not really.

Anyone who wants to conceal what continent they're on will also be using a VPN 24/7, or will have the proxy setup in Signal (AKA running 24/7), which defeats this.

When I was ~15 and this was ~2004, some friends and I ran a forum with a lot of users and did some bad things where we would track down repeat banned users and screw with them. (In our defense, they were screwing with us.)

We used everything, from browser fingerprinting (and EFF only made the world aware of it 6 years later), looking them up in databases, tracing every digital evidence they left, etc.

Every little thing counted. What I learned is that people leave a lot of traces and you can collect these traces to dox them. The way you write is even sometimes fairly identifiable.

If I know someone on Signal I can now check if they’ve left the country.

Or send this to a bunch of signal users whom you suspect one of them being a particular person, and if you know that the person you are looking for is going to travel you can send it once before and once after. Then see which of these users were in the home city and subsequently in the destination city.

A VPN obfuscates this. Assuming a target is even remotely aware, you might think they are in Australia, while they're actually in Nova Scotia

The real attack is that a law enforcement agency can trivially subpoena CloudFlare with the attachment URL they will hand over the IP address of the recipient of the image along with whatever other requests they made through the CDN which can pretty precisely and rapidly de-anonymize you.

Indeed, "incredibly precise estimate of the user's location" feels like an exaggeration. But still, very interesting!

I'd say it'd be useful for very specific use cases. Such as finding out what country Jia Tan, the XZ Utils backdoor attacker, is in.

I wonder if it'd be a good idea for Signal to implement a "simple" mode that would deactivate most features in order to reduce the attack surface for people who really think they are being targeted. Would that be a good idea ?

Caching attachments at a single nice, big, juicy honeypot like CloudFlare is one of the reasons Signal's privacy guarantees don't feel totally solid to me. I get that it's pragmatic, but feel there must be a better way.

Does the caching occur even if both users are online when the attachment is sent?

Even time zone leaks are privacy issues, and the leak we're discussing is more fine grained than time zone.

It only takes 33 bits to identify someone. This reveals a couple of bits.

Not really. It's only true if the bits are uncorrelated, and you can acquire additional bits of information. I don't see how you can go from "this guy on the internet lives near Albuquerque, New Mexico" to "this guy is Walter Hartwell White, and lives at 308 Negra Arroyo Lane, Albuquerque, New Mexico, 87104" without massive opsec failures.

Combined with other information, it may identify someone reliably, just like you can with zip code, age and gender. For example, if you know this person is part of a group with members in several locations, or if you can corroborate someone's movements, etc.

For example, imagine someone suspected of sharing sensitive information with a journalist. They might have a short list of suspects, and use this technique to confirm which one it is. They might identify which journalist it is - maybe only a limited number cover this beat.

Or you want to find a specific journalist, and you find out that they just arrived to a certain city, and there are only three hotels in that city...

It's leaking so many bits idk what else you would call it, deanonymization isn't a one shot thing and it's a spectrum not a binary outcome

CloudFlare has the actual IP address that viewed the image. Which means some powerful (or rich enough) actors can get it.

This is very very bad.

This was... always, the case though? For any CDN service? How do you serve traffic to people without knowing where to send it?

> cached in a data center near that user

Not necessarily. Cloudflare is very upfront that they do not cache everything, and the time things are cached can vary greatly.

The kid keeps talking about "deanonymization" and he has no idea what the term actually means.

> attacker can use the cache geolocation method to pinpoint the recipient’s location

Agree, good writeup, but also a stretch to say they are "pinpointing" anyone's location.

Send picture to multiple accounts, perhaps on different services, the links that are cached at the same data center can be more confidently believed to be related.

This is not unique to signal. URL strings can contain identifying information regardless of where they are shared or posted. For example, if you send a link that ends with string of characters, these may correspond to a geographic location or browser settings. Blogger urls used to be geolocated, such as .ca for Canadian viewers. it is always safe to strip out unnecessary chacters if you're paranoid.

WhatsApp has an option to disable link previews.

Surprised signal doesn't have this option.

I only message people I know on Signal anyway.

Edit: it seems signal does have the option

I had this same thought before reading the article - this isn't about link previews, it's about attachment caching

Why would cloudflare ever operate a data center that only one user at a time is ever near?

Looks like it's possible to hit 2 datacenters due to load-balancing, which would narrow it down a bit more. Suppose you do this repeatedly as the target is moving around, hitting even more datacenters.

You underestimate the value of this piece of information taken at different times. It can be enough to know in which country a person was yesterday or is today.

Why does it need to be cached though?

The only case where it might be downloaded more than once is if the user has multiple clients. Not that common and still very little traffic.

For that reason that's why federated setup such as matrix are better. It is much harder to deanonymiza a set of users on different servers in group chat.

Did you see the GIF? It's able to triangulate.

Mmmm "qualified deanonymization" perhaps?

Imagine sending a friend request to bin Laden's videographer and getting a reply from Pakistan while your entire military is looking for him in Afghanistan?

There's definitely cases where this is going to be immediately used. Shit, just using it to scrape Cloudflare for additional metadata on everyone from other user table leaks is probably valuable data. Even triangulation over time as they move around is going to get a more precise result. Maybe you find a vulnerability that takes that cloudflare node offline and run it again, repeat until you've got a fairly small radius they could be in.

Headline feels like a click bait :)

timing and location can usually prune things down to enough data about a person.

> (no other users near the data center).

Yeah and in that case there won't be a data center because who puts one in places without clients nearby? :)

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.

> "deanonymization" is stretching the definition of the word, along with "grab the user's location", as it isn't anything near precise.

You'd think so, but you would be surprised how quickly this adds up to other details people share, like "oh I just drove 15 minutes to get Starbucks" or something to that effect, small things that eventually add up to a precise location over time.

> you would be surprised how quickly this adds up

Yes, but if social engineering is involved and tracing back through user conversations across a platform, it's hardly a vulnerability, let alone one deserving of a bounty. The way this is currently functioning is intended functionality, and can be further locked down depending on the user's threat model.

This can essentially be classified as opsec failure for the Signal user. If they're trying to hide from a hit in a 300 mile radius, they've got bigger problems to worry about, and should already be using a VPN setup.

Every time you click on a link your external IP addresses is exposed, is this a vulnerability? Being online without a VPN / proxy is inherent consent to have your external IP & other required items to be shared with services / middlemen.

When it comes to Discord, if you have this strict of a threat model and you're still using it, idk what to tell you.

You can disable the auto-download. Settings > Data and storage > Media auto-download, you can choose what to auto download for mobile data/wifi/roaming.

Thank you! That's what I get for quick scrolling through the settings. I for sure thought it would have been under Privacy (for this concern), but that makes sense too.

hmm. I find the auto-download setting in the mobile app but not on desktop (mac). anyone know?

it looks like it can’t be disabled for view-once media (or at least, that’s what the settings screen says)

Random unrelated point: in a 100km radius circle between Atlanta and Augusta there are ~2,000,000 people (calculated using https://www.tomforth.co.uk/circlepopulations/ )

Haha thank you for doing the math! I was lazy and just added the populations and a plus at the end.

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.

The counter point is that anyone who cares about being anonymous is using methods to disguise their identity that cannot be compromised by this attack, e.g: a VPN. Plus, there are much more effective versions of this attack, like sending a link to an endpoint that you control -- getting someone to click a link isn't hard if you're considered trustworthy enough to send them notifications. And less technical versions, like correlating when the user is online vs. offline with timezones around the world.

The method that both Apple and Cloudflare use in their own privacy software (iCloud Private Relay for apple, WARP for Cloudflare) is specifically based on the idea that your region is not information that reveals your identity. If you enable Apple Private Relay, your origin IP will be obscured but the IP your traffic is routed through will be in the same country -- same principle.

https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...

This attack is academically interesting and novel but it's not "deanonymization".

> The counter point is that anyone who cares about being anonymous is using methods to disguise their identity that cannot be compromised by this attack, e.g: a VPN.

Yes unless Apple is doing Apple things and ignores VPNs for things like push notifications…

https://x.com/mysk_co/status/1579997801047822336

> The counter point is that anyone who cares about being anonymous is using methods to disguise their identity

https://news.ycombinator.com/item?id=42784398

Not everyone who indirectly cares about anonymity is an activist who feels they need to go to great lengths to disguise their identity. Sometimes anonymisation is part of a process, and the ability to collect potentially deanonymizing data this way is still a privacy breach.

E.g. imagine sending otherwise anonymised participants in a clinical trial a questionnaire, containing an image. The owner of the image could then partially deanonymize the trial participants. Or voters. Or demonstrators in a rally.

Not everyone who cares about privacy is Edward Snowden material.

I am not sure I understand what you mean by "trustworthy enough to send them notifications". Do you need anything other than one's phone number to send them a signal message?

On iCloud public relay, go to settings and select “use country and time zone” instead of “use general location.”

Now you’re no longer “within 250 miles,” hell my phone geo IPs everywhere from Louisiana to New Jersey , which are not even “in my time zone,” but there you go.

This setting was pissing meta/Facebook off big time because they also couldn’t narrow me down to a precise geographical area, resulting in much nagging and whining about “was this you signing in from [shreveport]?” and frequent account lockouts , password resets, and endless requests to approve my logins from a device that’s already logged in before I finally said to hell with it and deleted FB a few days ago.

I figure if a privacy setting makes meta mad , then it’s .. probably … a good setting. Must really irk them trying to sell location relevant ads when my state changes every other time I unlock my screen.

It’s a combined behavior of using private browsing and refusing to install their app, thereby giving them a permanent supercookie no matter what my IP is, so if you don’t like the sound of this it [might not] affect you if you use their apps. “X” does it too, just look up “inferred identity+ twitter” on google.

I’m editing out a tall claim in the last paragraph of this for some other time when I’m less tired and have sources next time we’re on the subject.

Satoshi's possible home IP address actually did leak shortly after Bitcoin's release, though it wasn't realized until years later.

(It definitely may not be him and might instead be a random early user. But I think there's a moderate chance it's him.)

Details: https://news.ycombinator.com/item?id=29728339

(I don't advocate attempting to find and publish his name and address, since it'd make his life difficult, but it's still very interesting in the abstract as a curious unsolved mystery for all these years despite the number of eyes on it.)

How many people live in a 250 mile circle around New York?

I think the more important question is how many people in the world don't live within a 250 mile circle around New York? An investigator could potentially cut their geographical search down by 95%+.

Also the attack can be performed multiple times and if a person travels it could narrow down the possibilities quite a lot.

How many people live in a 250 mile circle around their Cloudflare POP?

Which Cloudflare POP I hit depends on which RSP I use. In the country I live in, our biggest RSP peers with Cloudflare in a neighboring country (as it is much cheaper for Cloudfare to send traffic via that RSP's peering exchange there). So something like 40% of traffic will seem to be from a entirely different country than reality.

My RSP is a small RSP which until fairly recently only had two POPs in the entire country. So regardless of where you lived, customers of my RSP would have traffic exiting onto the internet via only one of two exit points. Rural users would seem to be coming from one of the two largest cities in my country even if they are easily >250miles way from their particular POP. They do peer with Cloudflare but obviously only at the locations where they and Cloudflare are in the same city (and I'm not sure this is the case -- it is possible all national traffic to Cloudflare traffic actually goes via the one POP in our biggest city).

The only reason this attack identifies the city I happen to be in is because I live in the same city as my little's RSP's biggest POP and Cloudflare happens to peer with that RSP at that POP. Where I am is a large city so doesn't narrow things down very much -- but even worse is that whoever is looking for me would actually need to look anywhere in my country.

I don't think I am an unique case as internet routing is rarely the most direct path for various technical, financial, political, etc reasons.

De-anonymization is definitely stretching the reality of what this 'attack' is capable of IMHO.

You can already do the same with advertisement ID in (almost) every single one of these applications.

Still quite anon. He almost certainly used a VPN, and if he didn't he likely lived in a major city which included thousands if not hundreds of thousands of capable engineers. If it said he was in SF during some messages that would tell us literally nothing.

... very anonymous because he was most likely using a VPN lmao

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.

I would guess some are just jealous of his age, but some do find the claim of de anonymizing to simply be overblown given it doesn't tell you nearly enough to find anyone except in very niche cases. This "attack" is easily defeated with a VPN or living in any major city.

You don't need to live in a major city. Cloudflare is never going to set up a caching proxy for a hamlet in the desert; you'll always be part of a huge group that a given caching proxy serves. The attacker can be happy if they can narrow the recipient's location down as much as to a single country

Interesting you touched on his age. I got extremely curious, why did the OP did such a flex?(assumming they are telling the truth). The first sentence is such a weird brag that it felt suspicious. The report is highly technical and extremely well written. We're either dealing with a pure genious or a fraud. But why would a genious flex? Doesn't make sense.

Someone on GitHub called him out for making a Twitter account in 2017, since he'd have to be 8 years old at the time... I don't see what's so unbelievable about an 8yo making a Twitter account.

It's common in our community to be jealous of youth, especially youth with genius, but I believe the github user in TFA is lying. Something about it is off. It also happens in posts here on HN, though.

I think after being exposed to so much internet, you realize how many are simply living a fantasy. In me it provokes a sense of disgust, I see it as part of a broader groomer problem on the internet, but this is a distantly minority take.

I believe most people (me included) dismiss the OP's claimed severity, as if it is being oversold. I see a balance of opinions saying "great find, but not as critical as claimed" so they don't seem dismissive. It is important to correctly classify the severity of issues. Proof of whereabouts is not deanonymization, especially when the abouts are so loose

Even knowing their country from this would be a big first step.

They dismiss it for the same reason people dismiss disruptive new technology - they are uncomfortable with it. It's a signal (ha) that the threat is very real.

First dismiss it and see if the problem is still there in the morning. Hope that before then, someone finds a reason it's not a problem. Anyone?

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.

Signal's default setup is more usability focused while supporting E2E, and less about tinfoil hat threat models about being present on a continent you're a citizen of.

The items you mentioned can essentially be configured, for those that want the insane level of privacy / security. Messages can be auto-deleted 30 seconds after being seen, a proxy can be configured to route all your traffic through it, and tons of other things can be done to customize it more to the user's liking.

I'd imagine they're caching it because of egress costs. File attachments, voice mail, video, etc. can all add up.

> Signal's default setup is more usability focused while supporting E2E

If images/attachments were e2ee, this problem probably wouldn't exist, right? or are the images on cloudflare encrypted?

Edit: I should clarify. I didn't mean the encryption itself fixes the problem, but rather that: If this were handled like the text messages we send (not via cloudflare CDNs) then this wouldn't exist. I get that attachments are quite some bytes bigger than text but shouldn't the security guarantees be the same?

Group chats and multi-device users maybe

Note: this person is the same 15-year old who found the Zendesk Slack takeover exploit a few months ago [1].

[1]: https://news.ycombinator.com/item?id=41818459

Given the twitter account was made in 2017, they would have been eight: https://x.com/hackermondev

And that bug report to Adobe was made when they would have been five years old: https://hackerone.com/daniel?type=user

I think that's just a quirk of HackerOne's username system. The username daniel was previously owned by another account (now known as daniel-hamid) which submitted a bug to Adobe. If you go through @hackermondev's tweets (starting in 2018) they are without question a kid (making games in Roblox and Minecraft) and then started to show an interest in hacking in 2020 (which lines up with when they created their HackerOne account). The claim of being 15 years old is plausible (presumably with parents / guardians who are accomplished in technology).

He'd be 8 when he made the Twitter account, not when he discovered that exploit. Pretty sure there are tons of 8yos with Twitter accounts.

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.

depending on the circumstance, the rough area might already be useful to adversaries of the person trying to hide. I wouldn't expect things like criminals etc. to suffer from this, 300 miles is a big radius for example... but if you want to know if 'the guy is still in country' or something like that (for instance law enforcement) it's useful for them. such parties could then collaborate with local resources to do further investigations. knowing which local resources in what area to enable might save a lot of 'costs'.

as you said, impressive and insightful. :D kinda feel like the docs on it were a bit chatGPT aided, they are super clear and full of 'certain sentences'. (this is totally an excellent use-case for that, so not bashing on it at all!).

nice read.

You would know if they are over a cellular network or checking on mobile.

If someone sends you a youtube link and you hit play, YT knows who you are, both from a network perspective and potentially the logged in user.

If you are using signal in a high risk environment, you should be using it from a system that contains no extra information about you. This is the same posture one should take when using Tor.

Basic opsec.

I don't think these kinds of things are in signals threat model. It is meant? as a message platform for people with nothing to hide?

i don't think you can call opsec basic, since it requires tons of knowledge about technology and techniques adversaries might deploy against you. targets of attacks don't neccesarily have this kind of knowledge.

opsec is _incredibly_ hard for a person not deeply into technology and this type of information. you might argue that you need to stick with certain tools and techniques that are known good, but new vulnerabilities and techniques implemented against you can completely shatter previous knowledge on whats good and bad opsec and still break it despite doing it 'very well'. (like certain darknet markets being closed down due to new vulnerabilities being found in the platforms they use...)

most people who rely on opsec/tradecraft for a living, also rely on teams of people to help them maintain it and validate it constantly... (or eventually fail and get bitten).

you are right though that its unlikely a company or app producer would have a threat model tuned to people who want to hide stuff. those things generally tend to be closed down sooner or later. (encrochat and such services...)

Law enforcement could probably just ask cloudflare for the exact IP address that retrieved the attachment.

Only if they're from a friendly country. If the reason a user needs anonymity is geopolitical, that isn't a guarantee.

Anyone can do this are per the TFM, which is an excellent read.

do you think law enforcement in Iran will get an answer from cloudflare?

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...

> Unless I'm missing something, this seems like an incredibly long winded way to check the users IP location?

It's less accurate than that. IP Geocoding can be down to the city level in many cases. This is _maybe_ nearest cloudflare data center

>just not convinced on the real world applications here...

As a piece of data alone, the results are probably not of significant use.

The real-world application (and potential danger) is when this data is combined with other data. De-anonymization techniques using sparse datasets has been an active area of research for at least 15 years and it is often surprising to people how much can be gleaned from a few pieces of seemingly unconnected data.

> The real-world application (and potential danger) is when this data is combined with other data.

That's exactly the point. In this case it's only really possible to de-anonymize people who take long distance trips. But based on two data points it might be possible to know which flight or train a person travelled with.

With three different data points it might be quite unique. For example you might find out somebody travelled from Italy to Norway on Monday evening and then to France on Wednesday morning. There are probably not so many people who did a trip like that, it might come down to only one (or a handful) people who fits this itinerary. With other data sources it might be possible to uniquely identify this person.

>The real-world application (and potential danger) is when this data is combined with other data. De-anonymization techniques using sparse datasets has been an active area of research for at least 15 years and it is often surprising to people how much can be gleaned from a few pieces of seemingly unconnected data.

Seems pretty handwavy. Can you describe concretely how this would work?

Do you not buy that a user's IP location needs to be protected?

There is a reason applications go to so much effort to proxy requests to resources such as images. It's not free to do this.

Having your IP address not revealed to people that can message you on Signal seems like a pretty reasonable privacy expectation.

Your IP isn't revealed though, only your vague geographic area.

Did you even read it? There's no IP leak. And if you're a high target, then using some kind of proxy is literally the first step you take. The attack is nothing but an exaggeration and has no merit in real world

I guess it can be useful for tracking fugitive political dissidents, terrorists, etc. If you can narrow their location down to 250 miles, it's already very useful information. And without raising any suspicions.

It's not really narrowing it down to 250 miles; its narrowing it down to a circle whose radius is at least 250 miles or ~196,000mi^2.

My closest Cloudflare CDN is just listed as "DFW". The DFW metro area is about 8,700mi^2, and I imagine I could be even further than the "metro area" and still get the "DFW" Cloudflare datacenter.

In their little video animation, the area inside the overlap of those two circles encompasses several states. The edges of the two circles go from Washington to Florida and almost include Chicago. The target could have been in Denver or St Louis or Las Vegas or Phoenix or San Diego or San Francisco or Amarillo or El Paso.

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...

It isn't caching, it's CDNing. It is just an artefact of CDNs that they act as caches for the original content, and for improved distribution response time they cache to the nearest server from the response. ('Nearest' being an approximate heuristic, it is property of the anycast route tables in the BGP routers the request passes through, it is actually a 'best route'.)

That caching is something you can turn off, at least for every CDN that I have worked with.

The Cache-Control http header has a `private` directive specifically to inform CDNs and similar not to cache the response.

> it seems like CloudFront could very easily fix this by not returning the cf-ray header

Then you just look at the response time. If the resource needs to be fetched from another continent, this is probably reliably measurable

Same for websites trying to hide which users exist: do a login request for an existing username and it'll do the password hashing (usually adds at least 50 ms to the response time), whereas for an invalid username it early exits. The fix is to always run the same code, so always do the hashing, which very few sites do. (Or not care about revealing this and telling people straight out that their username is unknown, if that fits with your threat model.) So to get back to Cloudflare's case: it won't help unless they delay responses, which is the opposite of what they're supposed to do

I dont' believe the Signal app/network is choosing to cacheimages in a CDN?

But any user can send anyone other user a message that includes a link to a CDN-cached resource. Isn't that the "attack" here? Or am I misunderstanding?

Signal does cache them in a CDN. If the vulnerability was sending any link, you could just set up your own web server and get the person’s IP

Ah, and the attack is knowing what CDN that is that signal itself is using, and examining it directly? I had missed that somehow.

Yes, Cloudflare should allow customers to disable that header, and Signal shouldn't cache images sent to a single person, or even groups of less than a few hundred people.

> the total number of requests for that resource should be very small

"For that server" is the other number-of-requests..

So that law enforcement can ask Cloudflare for the IP logs... Signal is a joke.

https://simplex.chat/

Signal claims to be a private, not anynomous, chat application.

Theirt defaults are set so they can get mass market addoption, whilst beeing a big step up in privacy compared to the usual players in the space (like whatsapp and telegram). You simply won't be able to get the average user on apps that make use more complicated and apps like simplex doe exactly that.

If you want Signal to be more secure, you can circumvent this attack vector by disableing auto downloads for media.

I'm not saying Signal is perfect, there has been a bunch to critisize over the years.

But why argue about use cases they never claimed to solve?

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.

I am currently banned from the Signal subreddit for pointing out that we only have Signal's word that they don't collect metadata. So, yeah, people do consider Signal anonymous...

People do use Signal and Telegram* in settings where anonymity matters. Sure they aren't meant for that, but there's no other widely-understood solution, and most of the time it's good enough for them.

* Funny enough, not vulnerable this time because they use an in-house protocol, which is maybe even worse.

People keep forgetting anonymous and private are two different things

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.

[1]: https://www.cloudflare.com/network/

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.

People for whom it's a threat don't necessarily understand anonymizing proxies - very few do. Signal is supposed to provide security for those who do not.

Where does Signal claim that, or who decides what they're "supposed" to provide?

If wishes had wings, sheep would fly. People who want their computer to do a certain thing can also be expected to do a quick web search for how to make it do said thing. E.g.: hiding location? Use onion routing. Signal doesn't claim to hide your country (heck, they require your phone number!) so it seems wishful thinking to say they should have included e.g. a Tor client and enabled it by default

No, it isn't. This is Cloudflare passing exposing metadata when it really shouldn't. Having a configuration option or a origin response header akin to CloudflareCache: private or something is trivial for them to implement.

The same information would then be available in the timing, but given the distributed nature here, that would be a lot harder to pull off.

There's a real difference between Discord itself knowing your location and any Discord user in the world knowing it. Just like there's a difference between the VPN provider knowing your ipaddr and every website you visit knowing it.

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.

Step 2: If you use Discord, don't allow invites from _anyone_.

Its quite bizarre why social media apps allow anonymous people to interact with you. 99% of the conversation I have is with people that I roughly know.

Discord is for gamers and quite a lot of people will be playing a game and tell someone "add me on discord my tag is xyz". Not allowing invites would seriously cut into the usability.

You could have it so both people have to add each other before there's any indication that either person added the other.

No extra work for person A, and the work for person B is just what person A had to do anyway.

Just don't use it. Expecting privacy and security from a literal keylogger. Who in their right mind uses a plain-text messaging app in 2025?

How is Discord a key logger?

Most people, actually.

If you're worried about anonymity and you're using discord, you're failing. It's not made for that.

> Its quite bizarre why social media apps allow anonymous people to interact with you

Bit strange to attribute this to 'social media apps', isn't it? I'm interacting with an anonymous person right now. Most platforms allow it, including the older ones (i.e., IRC)

>Its quite bizarre why social media apps allow anonymous people to interact with you.

I mean, it's one of Discord's major use-cases. Joining a server of a common interest and meeting/talking with other people that share that interest.

So, how would you start interacting with your friends if you just created account?

>anonymous people

Wtf, how is this even relevant?

You can add them by creating a unique, temporary UUIDs/links that they can use?

You know them from somewhere else, lets say I play a game and we decided to get into a voice chat. We could create a temporary, dynamically created voice chat that we can all join (much like Google Meet) where all of us are anons.

Then, if we really want to know each other, we can then share the UUIDs.

I understand why ANYONE can send an email to me (I can decide when/will to check them)

I don't understand why ANYONE can whisper to my ears (I cant decide since they are pushed to the top of the app)

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.

> didn’t get why Signal would just download an attachment from an unknown number/contact

Usability, most likely. Ultra-secure and paranoid doesn't result in good UX most of the time.

Push notification thumbnails. It's mentioned in the article ...

> 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 guess you went through the post too quickly, because it goes over how that's exactly how it works. Unless you have push notifications enabled and on default settings to include the content in the push notification.

>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.

Where are you getting the impression that signal auto-downloads attachments from an unknown number/contact? The OP says there's auto-download, but not that it happens from unknown contacts.

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.

As you say, it depends on the person but I think for most people an acceptable definition is "deanonymization reveals PII". What qualifies as PII depends on the context/jurisdiction but typically an IP address would be considered PII whereas country (or a similar broad region) would not.

https://en.wikipedia.org/wiki/Personal_data

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

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 ?

Yes, that is correct. VPN near location would be disclosed, not yours.

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

Signal is definitely also aiming to provide metadata privacy, which they understand to be part of secure communication.

Otherwise, they wouldn't pad attachment and message sizes, offer a "sealed sender" feature, allow relaying all calls to avoid callers/callees from learning users' IP addresses etc.

Typical mobile user with a VPN is still vulnerable as far as I can tell, because they may be disconnected while displaying a push notification, but feel free to prove me wrong: https://news.ycombinator.com/item?id=42786466

Signal is intended not for HN readers, but for ordinary people who don't understand VPNs and Tor.

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?

https://cdn.geekzone.co.nz/images/forums/danasoftcache.jpg

I was fascinated by this once I learned how it worked. At the time I was learning php and wrote a script that would draw graphics based on the requesting ip address and return as gif, then used that as my avatar on a few phpbbs. Learned a lot.

That was a troll feature. It usually showed any user his own information.

MAYBE some forum doxxed users by posting their informatio? but I didn't see any.

Had a friend who made his own nice one, would then visit the thread, and figure out "who is viewing it" and show your username. ;)

Just like the days of DoSing an IP from a COD Lobby

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.

It's not because you have a Hungarian number that you're not travelling somewhere else. I don't really understand the point.

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 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.

Not sure about mobile apps, but in Discord desktop there is an option under "settings -> notifications". Your browser may also have notification settings that would help.

This changes the attack from a 0-click attack to a 1-click attack.

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).

Since creating separate URLs would largely defeat the purpose of caching, a simpler solution would be to just disable caching, as Cloudflare suggested in their response.

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.

Not sure it's so rare. A large number of group chats will have people in the same area. For me it's the vast majority: family chat, groups of old classmates or flatmates are mostly in the same country, work chats too... I can think of one exception where a group member will consistently be hitting a different Cloudflare node from everyone else, but for everyone else, every time I send a picture into a group chat the caching will save traffic

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?

> Can't one find out someone's IP just as easily by making them make a request to a URL controlled by an attacker?

Unless you can find another flaw in Signal, that'd likely be a 1-click attack, which is less valuable than the 0-click attack demonstrated by the author.

Might even argue that the title is good because it made us click

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.

The attacker uses a patched version of Signal to be able to intercept requests and to block a get request to the attachment they have just created. At least it is my understanding.

I'm not sure how much if it makes any sense.

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?

There is another method to query the caches. This is mentioned in the article.

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.

That's why this is interesting, it doesn't even require someone to open a link

Guess what: you don’t need cloudflare

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?

> 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?

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”

You’d be surprised at how adept the younger generation can be, especially those who’ve grown up with technology. As tech evolves, so do they. There are kids who genuinely apply themselves, and because they’ve been immersed in this environment, it’s practically second nature to them. I remember the late 1990s: I was young, but more than anything, I was curious about how things worked, I had the luxury of time, and access to technology to explore it. I started coding in C++ when I was around 13, and honestly, I still feel like I started too late.

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.

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.

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.

You can't instruct a random Signal client to fetch a random URL. Here's how this attack works:

1. Attacker sends novel image to Signal

2. Signal hosts the image on their core servers

3. Signal instructs victim to fetch preview of the image

4. Victim asks the CDN for the image

5. CDN gets the image from Signal core servers and caches it

6. Victim gets the image from the CDN and displays the preview normally

7. Attacker hits every one of the CDN cache servers

8. The CDN cache server that say "yep, saw that already" is the one closest to the victim

Well, unlike with tracking pixels, you are not in the direct request path and cannot block it. You also have no way monitor/log if it is happening (like you can in theory with a packet capture).

It's obvious in hindsight, but I bet no one would have mentioned this possibility as why you should disable notification previews or that simply receiving a notification would possibly reveal this information.

If your target is savvy enough not to click random links sent by strangers, it's hard to get them to load it. Many apps have caught onto the tracking pixel technique. It used to work for iMessage long ago.

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 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?

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...

"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".

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.

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.

That’s exactly what the author does towards the end.

Not exactly the same type of attack, but very similar https://cyberinsider.com/timing-attacks-on-whatsapp-signal-t...

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.

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.

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?

"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.

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.

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.

> This would provide an incredibly precise estimate of the user's location.

Within ~250 miles of their location is not "incredibly precise"

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.

I'm sure this is nice to find what city/country someone is but not what I consider "incredibly precise"

I think its good for finding out if someone is still in a certain region. More like region identification not deanonymization.

I remember iOS not always respecting VPN's do these notification attachments get loaded through a VPN?

Would be very interesting to see how other IM behave with this:

For example: Jami - one of the most feature-complete, distributed IM...

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.

>Just by the fact he's expressing distances in miles, I can say he's from USA.

And you could be falling into his trap of getting you to believe so by expressing distance in miles, as well.

Anyone send Snowden a push notification? Would be interesting to see if he's still in Russia...

So the default option of using onion routes to hide your IP and location still works.

If you need to deanonymize a user who moves around a lot, this method makes sense.

Nice work OP, and congrats on HN front-page. Keep publishing or it never happened!

This is an extremely cool avenue of attack, I love the bot/demonstration.

Cloudflare's business model is fingerprinting as a service. Awesome.

Impressive write-up, especially for your age! Thanks for sharing :)

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.

this highlights that the design of the protocols which are two decades old all need to be rethought

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.

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.

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?

The attacker can't be forced to make a request. In this PoC the attacker disabled their own outgoing image requests.

But that wouldn't help anyway, even if the image could be cached near the sender first, or the signal server prewarmed some other cache. After the victim opened the image, the attacker would see two locations that have the image cached, and could easily deduce which one is the victim's location (e.g. if Signal pre-warmed a random cache, repeating the attack a couple of times would be enough to eliminate the randomness).

It's cached near the receiver for performance purposes, I assume, the same reason Cloudflare uses geographically local caches.

Great job, you're going to go far Daniel.

Surprised that was only worth 200 bucks.

why signal even have that side channel???

even matrix encode image and other data in the e2e p2p message flow

“deanonymization”

Hardly.

Amazing sleuthing but not deanonymization.

Pretty impressive work.

Presumably cloudfare will close the loophole for enumerating cache edges now.

this is pretty devastating for signal

very impressive findings

is simplex immune?

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.

While the detection area of the cloudflare attack is bigger I think the main problem here is that its much easier to get access to it than to cellphone towers.

> through cell phone towers

Extremely sensationalist. A cell tower might have a range of a few miles, max. This is giving ranges of 250+mi.

> Don’t get me wrong the write up is really interesting but it does feel like the author is a bit of a sensationalist.

They claim to be 15 years old. Cut them some slack.

"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. :-)

I just sent a feature request[1] to Signal with the following text:

    I understand that Signal does not consider this
    https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117 to be
    a valid security bug, but it would be helpful to at least be able to
    mitigate it.

    Please add an option in settings to disable automatically downloading
    attachments.

    That should be enough to change the attack from 0-click (just opening the
    conversation) to 1-click (click the attachment). Most people won’t care
    about this, but for some every little bit of privacy is important.

[1]: https://support.signal.org/hc/en-us/requests/new

> "Cloudflare ended up completing patching the bug"

This short quote fragment is a little misleading: Cloudflare patched the bug in their systems that allow you to send HTTP requests to any CF data center, regardless of where the originator of the request lives. This is likely something they want fixed for a large variety of reasons, some probably much more important than the specific attack OP wrote about.

> I wish Signal would react differently.

The severity of a potential security issue, or the determination of who is responsible for fixing or mitigating it, is a matter of opinion. Just because you think this is important for Signal to fix, it doesn't mean it's some absolute truth that it does. At the risk of appealing to authority, I would expect that people who run a security/privacy-focused messaging project to have a better handle on classifying these sorts of things than random people on HN like you or me.

But of course, sometimes they'll get it wrong too. I'm not familiar with the bubble color thing you mention, but sure, nobody's perfect; we're all human and we make mistakes. I'm personally not convinced Signal needs to do anything here. A 250 mile radius is quite a large area, and users can already choose to not auto-download attachments. To be fair, though, I think a simple way for Signal to fix this would be to disable caching on the attachments HTTP endpoints, though that might increase their bandwidth bills and increase load on their servers, depending on what their access patterns look like.

Signal is likely funded by the CIA and other intelligence actors:

https://yasha.substack.com/p/signal-is-a-government-op-85e

https://www.kitklarenberg.com/p/signal-facing-collapse-after...

https://www.city-journal.org/article/signals-katherine-maher...

https://drewdevault.com/2018/08/08/Signal.html

https://bigleaguepolitics.com/court-docs-show-fbi-can-interc...

Is there really any difference between dismissing the report or "citing this as a Cloudflare issue"?

>"Signal instantly dismissed my report"

>I wish Signal would react differently. I still remember the bubble color controversy when they changed their mind after the backlash and not before. :-)

Can you blame them though? They're a non-profit with limited manpower and resources. There's quite a lot of cranks in the security field, and as many people have echoed in this thread, the bug report is rather sensationalist. At some point you just have to pattern match and ignore any reports that seems a bit too cranky. Is this ideal? No. But I don't see how it's any different than summarily dismissing a vaccine skeptic's claim that vaccines are bad, even if there's a kernel of truth buried in there (eg. that benefits for young people are questionable).

I guess I'm not so "crazy" for funneling all my Android's outbound traffic through a VPN that does two hops.

Whether that's crazy depends on your threat model. If there's no reason, it could still be crazy in the sense of protecting from an irrational fear. If you communicate with people or organisations who shouldn't know your location, it makes sense. It depends

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!

De-anonymization would take monitoring over a period of time, but it could definitely work. Take this scenario for example: a person of interest is in the area of New York on Jan 1. On Jan 4 they travel to the UK. On Jan 7 they travel to Germany. On Jan 21 they travel back to the US.

The list of suspects would be fairly small when US officials cross-check individuals that travelled US-UK on Jan 4 and Germany-US on Jan 21.

It is already more than enough to know which country to contact the authorities and to pinpoint a rough area where to look.

If the scammer is in Nigeria, tough luck. If he is in the EU or US then exists a feasible chance to go after the person.

> assuming geoip is correct too

It's not using geoip, it's using anycast.

Reply on news.ycombinator.com