Live data from Hacker News

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

gist.github.com

161–170 of 474 posts

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

#161

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.

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.

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

#162

Earlier quoted context omitted.

> "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 Sign…

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

I mean, you just never know... I've seen a lot of wild things, I've seen what drives people to doing crazy things. Just look up the "Deadly Runescape E Dater" who flew from the US to the UK to stab the girl he e-dated.

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

#163
post #68

Earlier quoted context omitted.

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…

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 won…

Telegram doesn't use local CDNs for caching. All users are associated with one of about five telegram DCs, and upload files to their local DC. If a file was uploaded by a user on another DC, users connect to it temporarily to download the file.

The DC that a user is associated with is exposed by the API - you don't need to get them to upload a file to discover it - but it's so broad that it's not much of a deanonymizing signal. (Knowing that your target is in DC1, for example, just means that they're probably somewhere in North or South America. Or that they registered using a phone number that said they were.)

https://core.telegram.org/cdn

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

#164

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.

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

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

#165
post #146

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.

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

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

#166
post #121

Earlier quoted context omitted.

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.

Repeat the attack daily for a few weeks and you might get a pattern of movement. Of course if the target hasn’t left their general area then this won’t help. But if you’re a nation state watching a target move between multiple international locations, you could match this up with passport travel data to significantly reduce the anonymity set.

Seems contrived. What type of a person cares about deanonymization attacks and nation-states trying to find him, but doesn't have an always-on VPN? Even without this attack, not using a VPN means you're 1 wrong click/tap away (if you accidentally clicked on a link) from leaking your IP.

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

#167
post #71

Earlier quoted context omitted.

TLS doesn’t matter for End-to-end encrypted stuff though, you could exchange the data over Telnet and it would still be secure. The content itself is already encrypted before being transmitted and can only be decrypted by the receiver.

AFAIK the attack described by OP only works if the attacker knows the (randomly generated) URL of the image, which probably means they have a Signal client that can decrypt the image already. So the secrecy of the content is not at issue. The question is whether some specific person has received the same image, and from where.

Part of his attack requires disabling the cache on his (sender) side so that he doesn’t pollute the cache. That implies that both sides of the conversation share the same URL, which means Cloudflare could assume two IP addresses requesting the same URL on the Signal attachment domain are participating in a shared conversation.

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

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

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

#169
post #8

Earlier quoted context omitted.

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 a…

> 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 S…

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.

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

#170
post #166

Earlier quoted context omitted.

Repeat the attack daily for a few weeks and you might get a pattern of movement. Of course if the target hasn’t left their general area then this won’t help. But if you’re a nation state watching a target move between multiple international locations, you could match this up with passport travel data to significantly reduce the anonymity set.

Seems contrived. What type of a person cares about deanonymization attacks and nation-states trying to find him, but doesn't have an always-on VPN? Even without this attack, not using a VPN means you're 1 wrong click/tap away (if you accidentally clicked on a link) from leaking your IP.

Right, agreed that VPN is the primary mitigation against this from a user perspective. But opsec is hard, especially when the attack can be triggered by a notification when the victim might not be expecting it and might not have VPN enabled (e.g. maybe they only enable VPN when using Discord).

(But notifications are already a bad idea for opsec anyway.)

Post reply on HN