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

n3t_admin

Just saw this video from Daniel Boctor about a type of exploit that can be used to determine your phone model, whether the screen is locked, unlocked or the app is active, whether you're on Wi-Fi or cellular and much more just from sending malformed messages and analyzing the silent delivery receipts. All an attacker needs, is your phone number. Couple that with the recent WhatsApp leak (and we don't know if anyone else exploited it aside from the security researchers) and we have a pretty devastating situation with WhatsApp in particular.

The original source can be found here: https://arxiv.org/pdf/2411.11194

As of now, it seems a fix is not available and neither WhatsApp/Meta or Signal/Signal Foundation have shown any interest in fixing it, which I find quite concerning. Just thought I would share this, so you can be aware. The video is also pretty good, so I suggest you watch that, even after reading the paper first.

grayway2

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

Threema, Session, SimpleX or Briar does not require a phone number to operate.

WhatsApp is garbage by definition so I don't expect much from them.

de0u

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

Thanks for posting that!

DeletedUser499

I have never been a fan of Signal, to be honest it is just a gut instinct, I have used Molly-Foss, and have always had doubt about giving them a phone number, for me that is square one for the adversary to begin tracing you/me.
Yes I know... but your using 20/20 hindsight, anyone can do that!
I am a long time user of Threema, and bought tens of accounts with cash. No information given out at all.
This revelation from 2024 if it circulates widely, will damage Signal and by association Molly too, unless Molly are radically different in their approach.

n3t_admin

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

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

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.

newbie24689

DeletedUser499

and bought tens of accounts with cash

Interesting! How do you buy an account with cash? ISTM financial transfers are very traceable!?

23Sha-ger

Generally speaking, disabling read receipts, using the new alias feature instead of actual phone number,
and in general using a VOIP/SMS service not tied to your identity to register on the service, still provides
the best privacy. This is true for other services and apps in general.
As for the WhatsApp "leak", I think it is a method that allows a quick discovery if a specific number is in
fact registered on the platform. Originally WhatsApp used XMPP, and XMPP has a way to discover if an account exists on the server. Or they could abuse some other web discovery methods.
The enumeration itself isn't a problem, because an adversary will know your number and know that you are using
the service simply by adding your number. Furthermore, anyone who can submit a court order to Meta/Signal, will receive at least the last_online timestamp and probably last IP.
How they can fix it without artificial delays and limits? Time will tell.

n3t_admin

23Sha-ger disabling read receipts

That doesn't help. It's about silent delivery receipts which can not be disabled. As long as you are using Signal or WhatsApp, there is no real mitigation here. Not even using VOIP numbers, if the attacker can correlate that to you one way or the other. 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.

23Sha-ger The enumeration itself isn't a problem, because an adversary will know your number and know that you are using
the service simply by adding your number.

Enumeration never was the problem, but everything else that could be extracted at bulk like profile pictures, status messages, sometimes even emails in the bio...
This has to be the worst year for instant messengers for sure.

I advise caution to everyone who might be targeted by intelligence agencies around the world, since they will probably exploit this to no end. They have the resources to make this happen.

23Sha-ger How they can fix it without artificial delays and limits?

In the video it was mentioned that randomized delivery receipt timings would fix this. You would just need to add a few ms of delay and this exploit would fall apart. Why they don't do that? Don't know.

23Sha-ger

n3t_admin
Yes, valid points.
At least in the context of GOS and Signal(Molly) with UnifiedPush, the server gets the read receipts after
the distributor ack the server, so in case of ntfy.sh it will add lots of extra ms to the loop.
As for large-scale "scraping" of numbers and their info, that is a problem we cannot solve, it's up to the
platform to mitigate it server-side. But I don't see how it poses an extra risk to an individual.
For some reason I don't think Meta will care about the first point, they are known to cooperate with law
enforcement and will give away anything they have in almost every jurisdiction.

Ilgar

thx for sharing this signal / molly exploit

n3t_admin targeted by intelligence agencies

they can figure threema user id by backend, does it affect it?

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

23Sha-ger At least in the context of GOS and Signal(Molly) with UnifiedPush, the server gets the read receipts after
the distributor ack the server, so in case of ntfy.sh it will add lots of extra ms to the loop.

Yes, but in this case read receipts are completely irrelevant, as delivery receipts will always be sent and can't be circumvented by anything. They are an inherent part of the Signal protocol.

23Sha-ger As for large-scale "scraping" of numbers and their info, that is a problem we cannot solve, it's up to the
platform to mitigate it server-side. But I don't see how it poses an extra risk to an individual.
For some reason I don't think Meta will care about the first point, they are known to cooperate with law
enforcement and will give away anything they have in almost every jurisdiction.

Well, they seem to have implemented some type of rate limiting now, but still not enough to mitigate further scraping, from what I remember. Meta doesn't care and WhatsApp is regularly exploited in all the different ways - from providing an entry point for 0-days, to leaking all your account details to scrapers. It is just inherently dangerous to use.

Ilgar they can figure threema user id by backend, does it affect it?

This research only covers messengers that rely on the Signal protocol (a.k.a. WhatsApp and Signal). I don't know to which extent Threema would be affected, if at all. Currently Threema might even be a better choice, if your threat model includes highly skilled adversaries.

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

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.

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.

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.

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.

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

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.