Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gist.github.com

Post reply on HN
Print view View original

271–280 of 474 posts

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

#271

Post by sitkack »

sim7c00 wrote: post #75
sitkack wrote: post #34

Earlier quoted context omitted.

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

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

You are absolutely right, I think it should be basic opsec, but is probably advanced opsec seeing how many folks get tripped up by this stuff.

This means, never using a browser context you have ever logged into any service that is personally identifying. That also means the order in which you load pages. If your ritual is open pintrest followed by slashdot, that is now your finger print.

It isn't just what you do, but how you do it and the ordering between those events. You also don't want to accidentally deanon yourself or your peers, even when everyone is trusted because it also leaks group membership information.

The mental framework for opsec can be modeled as vector calculus and differential geometry. You have to think of the flow of information across a surface and in the integral of that flow. Assume an adversary with perfect total information.

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

#272

Post by soerxpso »

internet_points wrote: post #2

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.

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

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

#273

Post by radicality »

vel0city wrote: post #226
gabeio wrote: post #215

Earlier quoted context omitted.

> Going forward uploaded content should never go through cloudflaire and it never really needed to. The problem in this case isn't cloudflare. The problem is that these images load without the user's interaction and the person sending it gets to choose if it's cloudflare or not. So your statement within this context doesn't really work.

The person receiving it chooses to download images or whatever automatically though. I dunno, I'd still say the problem is at least 50% cloudflare. Why should they make which datacenters have a resource cached be obvious public knowledge? I do agree though, one could still end up inferring this information noisily by sending an attachment, waiting a while, and then somehow querying a lot of DCs and trying to infer ti…

Isn’t that because the URL parameters are so long that by design they effectively _are_ the password protection for the resource ? They shouldn’t be able to ‘leak’ to unintended recipients.

Personally, like you I’m also not a huge fan of this, but URLs like that basically should be treated as the passwords. Don’t post them publicly / don’t give them out to people you don’t trust.

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

#274

Post by adamrezich »

gtsop wrote: post #231
byearthithatius wrote: post #223

Earlier quoted context omitted.

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.

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.

I don't know what you think is genius about any of this, but you're right, the flex is odd. It's something I've been seeing more and more of lately, and I find it off-putting, because, Back In My Day, I never had such a phase, where I felt like I should be given more credit for my 1337 h4xx0r skillz, because I was in high school or whatever—and I don't remember anyone else doing it, either.

I can only assume this is a consequence of modern social media having shifted the Internet from being a bunch of pseudonymous people making and sharing stuff, to everything being myopically focused on one's identity first, and what they do second (as is literally the case here).

And it looks like it works to achieve its desired effect, too—a significant portion of the comments here are congratulating the guy for doing such a thorough technical write-up, given his age. Maybe this is just me being a grumpy “old” man now, but I would've found that condescending when I was his age, and would've rather concealed my age than be condescended to as such. But, to each his own, I suppose.

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

#275

Post by alp1n3_eth »

soerxpso wrote: post #272
internet_points wrote: post #2

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.

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

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.

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

#276

Post by int_19h »

modeless wrote: post #233
sureIy wrote: post #221

Earlier quoted context omitted.

Let's say they travel between NY and LA, how many sources of data will you need to know who was in NY on a specific date and LA on a second date? Feels like only the government can reasonably locate that.

The government is a plausible adversary for Signal

FWIW if it's the government, wouldn't they be able to just get direct access to Cloudflare logs - in real-time even - and thus observe and track the specific incoming connection to fetch the cached image?

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

#279

Post by alp1n3_eth »

mmooss wrote: post #258
alp1n3_eth wrote: post #93

Earlier quoted context omitted.

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

This is all the classic dismissals of security issues, including blaming the user. > opsec failure for the Signal user Signal's mission is to provide security for users who don't know the word 'opsec'.

Blaming the user is sometimes what it boils down to. Security includes a balancing act that involves usability, and Signal is firstly targeting the masses, but includes settings that can be configured for high-risk scenarios.

This "vulnerability" requires the user to have none of the normal things a person with a more extreme threat model would have already configured. EZPZ guides online on locking down Signal.

It's just like an iPhone. They don't ship with Lockdown Mode enabled by default, as it hurts the average consumer's usability. Signal at minimum will ensure no one is snooping on your messages, and it's up to the user whether they want to take that further.

If your definition of not providing security is allowing someone to know they exist on a continent, then that user's ISP has performed terribly as well since they aren't bouncing their signal around the world by default.

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

#280

Post by vel0city »

radicality wrote: post #273
vel0city wrote: post #226

Earlier quoted context omitted.

The person receiving it chooses to download images or whatever automatically though. I dunno, I'd still say the problem is at least 50% cloudflare. Why should they make which datacenters have a resource cached be obvious public knowledge? I do agree though, one could still end up inferring this information noisily by sending an attachment, waiting a while, and then somehow querying a lot of DCs and trying to infer ti…

Isn’t that because the URL parameters are so long that by design they effectively _are_ the password protection for the resource ? They shouldn’t be able to ‘leak’ to unintended recipients. Personally, like you I’m also not a huge fan of this, but URLs like that basically should be treated as the passwords. Don’t post them publicly / don’t give them out to people you don’t trust.

There's a part of me that's fine with it for a short-lived URL which contains a temporary access key but for a forever URL with a forever access key I'm not entirely happy with it.

I use it to share memes and shitpost but definitely not something to share sensitive content IMO.

Post reply on HN