Careless Whisper: WhatsApp and Signal can leak data from silent receipts

n3t_admin

grayway2 why the phone number is still mandatory for creating a Signal account

Well, it is a limiting factor for bots and malicious actors for sure, since they're limited from creating unlimited numbers of accounts. But it is a stupid requirement, I agree.

DeletedUser495 I believe these types of attacks are not at all commonplace, and if they do happen, are highly tailored, take place over longer periods of time, consume significant bandwith and you should be able to pick up suspect traffic during quiet periods (like at night). To me, no reason for panic.

This side channel attack is completely untraceable, unless you sniff your traffic at the router level. It could be happening to all of us right now and we wouldn't notice. The only other indicator might be high data usage, but it would be really hard to know where it's coming from.

KCne

n3t_admin Currently Threema might even be a better choice, if your threat model includes highly skilled adversaries.

Personally, I wouldn’t feel super comfortable using Threema to defend against skilled adversaries, because of issues like these. SimpleX may currently be the most promising option, but they don’t attempt to hide IP addresses despite them marketing themselves as leaking minimal metadata.

n3t_admin The only real way would be to disable and enable the messaging apps every time you start and stop using them... and that only works on GrapheneOS.

Couldn’t other Android based OSs somewhat solve this issue with Private Space or User Profiles? Also, what about disabling and enabling the Network permission on GrapheneOS?

n3t_admin

KCne Couldn’t other Android based OSs somewhat solve this issue with Private Space or User Profiles? Also, what about disabling and enabling the Network permission on GrapheneOS?

That would also help, but all of these solutions are pretty much the same workflow with the same restrictions: that you don't have an "instant" messenger anymore.

KCne

tpain8300 Please fill me in if there’s a better way thank you

From another thread:

KCne SimpleX may currently be the most promising option, but they don’t attempt to hide IP addresses despite them marketing themselves as leaking minimal metadata.

de0u

n3t_admin https://arxiv.org/pdf/2411.11194

Thanks for posting that!

de0u

DeletedUser499 I have never been a fan of Signal, to be honest it is just a gut instinct, I have used Molly-Foss

n3t_admin This affects Signal backend and is client agnostic. You can't escape this exploit via Molly.

I'm not sure I understand. The paper discusses mitigations such as artificially delaying and/or rate-limiting delivery receipts, which would be client-side mitigations. Let's see if @Nuttso has input.

indigomadelin

de0u page 11

employing restrictive messaging rate limits on the server side could mitigate these attacks

n3t_admin

de0u The paper discusses mitigations such as artificially delaying and/or rate-limiting delivery receipts, which would be client-side mitigations.

Maybe I misunderstood something and I wasn't able to find detailed information about this topic, but from what I gathered:

Alice sends message -> message goes to server -> Bob receives message -> client(s) sends delivery receipt to server -> server sends delivery receipt to Alice's client(s).

While this is of course dependent on the client to some extent, the server still handles the sending of the delivery receipts, so I would assume that this is the pain point here. And afaik, Molly doesn't have these mitigations in place. Maybe @Nuttso can shed some light here, would be much appreciated.

de0u

grayway2 I don't understand why the phone number is still mandatory for creating a Signal account.

I have inquired, and been told ("personal communication", i.e., treat this claim as unsubstantiated rumor if you wish) that it's a crude anti-spammer "proof of work" method, and that the developers are quite aware that some people would prefer alternative approaches.

de0u

indigomadelin employing restrictive messaging rate limits on the server side could mitigate these attacks

The very next sentence is: "Moreover, receiving an excessive amount of messages could also be automatically detected by the receiver and then trigger a UI notification and (temporarily) block the corresponding phone number."

It would be great if Signal's servers would rate-limit and/or filter bogus traffic sent to clients, but that does not mean no client mitigations are possible.

fid03

Vomitorius [Signal] is a honeypot.

Do you have any evidence for this claim?

indigomadelin

n3t_admin Alice sends message -> message goes to server -> Bob receives message -> client(s) sends delivery receipt to server -> server sends delivery receipt to Alice's client(s).

Delivery receipts work not only for sending messages, but also for reactions, edits, and deletions, which may not trigger push notifications (depending on the OS and app) - this makes the attack stealthy.

de0u

n3t_admin Maybe I misunderstood something and I wasn't able to find detailed information about this topic, but from what I gathered:

Alice sends message -> message goes to server -> Bob receives message -> client(s) sends delivery receipt to server -> server sends delivery receipt to Alice's client(s).

While this is of course dependent on the client to some extent, the server still handles the sending of the delivery receipts, so I would assume that this is the pain point here.

The paper talks about detecting whether or not the device's screen is on, also potentially where the device is geographically, based on how quickly responses come from the client. Randomizing response delays should help, and the authors explicitly mention that ("Coarser Receipt Timings").

Nuttso

n3t_admin If anything, it only makes sense to do this on the server. Of course, the client can also have such a function.

But you are all forgetting that Molly has a function that the others do not have, namely block unknown. This attack is not possible there from strangers.

newbie24689

n3t_admin

Currently Threema might even be a better choice, if your threat model includes highly skilled adversaries.

Any thoughts re: Briar?

https://briarproject.org/how-it-works/

n3t_admin

newbie24689 from what I gathered, it seems to be pretty robust. But also pretty limited and Android only for the time being. This isn't a viable option for most, since you can also expect quite a few of your contacts being on iPhones.

DeletedUser499

newbie24689
Its my favourite.
However I don't use it as it is unable to back up anything.
say you have twenty contacts and you have to factory re set your phone, for whatever reason, and re install Briar,
you cannot use your briar ID and then get all your contacts back again. You have to go to the trouble of installing them one at a time, and if these were face to face QR code installs for security, then that's where it fails.
But then that is a Briar strength, you delete Briar and everything is gone in a flash, no worries about a Briar database in the cloud to be discovered and revealed, no worries about an adversary installing Briar into your phone and expecting it to find other Briar users in your contacts, Briar users are kept in Briar and as I said you delete Briar and everything deletes.
Its too niche for the general population to use, no bells whistles etc, just extreme security. it is most definitely Function over Form, and thats' what I like.

indigomadelin

de0u In general client-side protection is not recommended because: a) the client might be a fork whose developer accidentally removed the protection, b) an incorrect system clock could lead to improper calculation of messages per minute, c) human factors, such as users ignoring the app's security alerts, d) the client might be outdated.

de0u

indigomadelin I don't believe for a moment that nobody recommends any client-side mitigation of any attacks. E2EE itself is an approach based on client-side mitigation of exploitation of server message stores. The double-ratchet protocol is full of client-side mitigations of various potential exploits.

If the proposal is that only the Signal servers should filter/rate-limit bogus traffic to clients, does that mean Signal users should be ok with a hypothetical situation in which the Signal Foundation is compromised and their servers send bogus delivery-status messages to specific clients at the request of governments? If not, I'm afraid that some client-side mitigation is not only expedient but inherently necessary.

GrouchyGrape

indigomadelin in general, it's best practice to treat servers as "zero trust". I want to know that the client on my phone that I "control" can mitigate threats created by a compromised served.

indigomadelin

de0u hypothetical situation in which the Signal Foundation is compromised

Good point. I agree.

Ilgar

GrouchyGrape treat servers as "zero trust". I want to know that the client on my phone that I "control" can mitigate threats created by a compromised serve

exactly! this is the only reason I use signal, despite it being located in u.s. aws, gcp, azure datacenters. now, it seems, it's not zero trust.

DeletedUser499

Ilgar
as has been stated many times across the internet, the phone number to allow a signal/molly account it its Achilles heel.
the slightest information known about a target is square one in the adversaries pursuit.
Why give your adversary the heads up.
Use an e2ee messenger that does not require such information.
It just seems so straightforward to me...

« Previous Page Next Page »