Hi Meta, WhatsApp with Integrity?
TL;DR: Meta’s WhatsApp suffers from an integrity issue that allows attackers to create an inconsistent world view on victims’ multi-device setup. Simply put, users expect their chats’ history to be the same across all devices. However, we show that a rogue client can send different messages to the same user’s different devices and it has some obvious (and some less obvious) security implications.
As part of our ongoing research on the topic of the security implications of the Signal protocol supporting both End-to-End Encryption (E2EE) and Multi-device support, we highlight today another security issue that enable attackers to create an inconsistent world view on apps that support this protocol, including the world’s most popular Instant Messaging (IM) app (2.4 billion active users), Meta’s WhatsApp.
Background: E2EE + Multi-Device in WhatsApp
In 2016, WhatsApp had announced the rollout of End-to-End Encryption (E2EE) protocol to its userbase. To support E2EE, the user app must generate a unique crypto key such that potential senders are able to encrypt messages sent to the receiving user in a way that only the receiving user can decrypt.
In 2021, WhatsApp switched to a Multi-Device architecture allowing users to add “companion” devices (desktop and web apps) to their “primary” mobile device. To support E2EE, these companion devices must have keys too. Theoretically, these keys can be either the primary device’s key and in this case they must be securely distributed to the companion devices, or freshly generated by the companion devices. WhatsApp chose the latter (actually it was Signal that chose that option with the Sesame algorithm and WhatsApp adopted the Signal protocol later on) option, so currently companion devices generate their own keys.
As described in the updated WhatsApp Encryption Overview Technical white paper, each of the user devices, whether it is the user’s mobile “Primary” device that registered the account or a “Companion” device linked to it (e.g. WhatsApp web) has an “Identity Key”. The Identity key is created at the time of installation and remains valid until the app is uninstalled from the device. When a sender wants to send a message to a multi-device recipient, it creates a session key for each of the recipient devices, which is derived from that device’s Identity Key. Then, the sender
“uses client-fanout for all the exchanged messages, which means each message is encrypted for each device with the corresponding pairwise session.”
This design choice has some privacy consequences that we highlighted on a previous blogpost
In this blogpost we zoom-in on the Integrity implications of this choice. Since the sender is responsible to distribute the message to all of the receiver’s devices, a rogue sender can send different versions of the message to each of the receiver’s devices.
Proof of Concept: Different devices, different chat history
To prove that indeed a rogue client is capable of creating such an inconsistent world view across multiple devices of the same users we created a rogue client, based on an open-source implementation of the WhatsApp client.
We changed the original implementation so it would send a different animal name in response for a certain incoming message
In the video above two of my WhatsApp official app clients (2 devices) installed on my laptop are shown: WhatsApp Web and WhatsApp Desktop.
- I send a question “favorite animal?” from one of these devices to Hadar Be’ery (my son’s account that has the rogue client installed 😈)
- I get 2 different answers: “parrot” on WhatsApp Desktop and “dog” on WhatsApp Web
Security implications
Highly technical attackers (“APT”s) may abuse this issues to:
- Pinpoint their attacks and send tailored exploits to the primary mobile devices and not to the browser and PC based companion devices (and vice versa).
- Potentially, send different messages types to different devices and “fingerprint” them (i.e. find their device type) based on their responses.
Some less technically sophisticated, social engineering attackers may abuse this inconsistent world view on victims’ multi-device setup to commit to one option on one device and to the alternative on another (might be combined with deletion) so they can later repudiate it.
Just imagine that instead of asking on the favorite animal, the question would have been “will you marry me?” or “ will you buy my car for $100K?” and on some device it shows “yes” while on the other it says “no”. Even the mere possibility of such attacks can cause user to distrust the integrity of their and their peers’ chat history.
Responsible disclosure
We have reported this issue to Meta on May 7th 2024 and got a (polite) rejection response on May 20th 2024
We believe that Meta’s answer is wrong:
- An issue is an issue, regardless of the existence of a solution to it.
- The fact that YOU (Meta in this case) cannot think of a good solution, but only suggest irrelevant ones, does not mean that such a solution does not exist. In fact, we suggest a sketch for such solution in the next section.
We sent the report to Signal security on May 14th 2024, but did not get any response (yet?).
A possible solution: The Ambassador’s protocol
A few months ago, we had published a sketch of a possible solution to the Multi-device privacy issue introduced by Signal’s Sesame protocol, by sharing and distributing the key material and crypto state between the users’ devices.
Such a solution can solve not only the privacy issues but also the integrity issues, as in this new protocol the sender is familiar with just one “distributed” device (no centralization) and sends just one message, that the server later distributes to all of the receiver’s actual devices.
We got some feedback from E2EE experts pointing out that some parts of our suggested solution are a bit naive and require some more work so they can actually be deployed in a real-world scenario. We believe we can make it work and in fact we are actually working on making a robust version out of this sketch. We would love to work with IM E2EE vendors and experts to make sure the outcome will be indeed relevant.
Acknowledgements
I would like to thank my son Hadar Be’ery for letting me use his device, account and jeopardize his IM social reputation and apologize for my implementation bugs
Conclusions
E2EE is a critical feature for Instant Messaging (IM) security. Being able to access the IM app on every user device is a critical feature for IM users productivity. Currently, this features’ co-existence create some negative privacy and integrity implications. We need to, and we can, make these critical features work together in harmony.
