Direkt zum Hauptbereich

Insecurities of WhatsApp's, Signal's, and Threema's Group Chats

Recently, the theoretical and practical analysis of secure instant messenger protocols received much attention, but the focus of prior evaluations mostly lay in one-to-one communication. In this blog post we want to presents the results of our work that focuses on group chat protocols of three major instant messenger applications; namely Signal, WhatsApp, and Threema.

In this blog post, we aim to focus on the practical impact and the found weaknesses identified by our analysis. The interested reader may also look into our paper for more details.

Our Aim and What We Were Looking For

End-to-end encryption protects the confidentiality of communication that is forwarded via central servers to the designated receivers. As a consequence, neither parties on the network route of the messages, nor the provider of the central server (e.g. the WhatsApp server) should be able to read any information out of the observation of the communication. In particular, no other user of the application should have access to the communication. Further it might be desirable to require that also the messages' integrity is end-to-end protected and that a sender is informed about the delivery state of sent messages.
Delivery state information in Signal (upper screenshot) and WhatsApp (lower screenshot)

In a two party scenario, this analysis is rather fixed to two components of the protocol: the key establishment between both parties and the communication channel protection using the established key (mostly consisting of an encryption algorithm and a scheme for providing integrity like MACs or signature schemes).

Regarded attackers

In a group setting, the same attackers apply (network, provider, other users). However the requirements for secure communication differ. It is further necessary that only group members can write to and read content from the group. Additionally, only administrators of the group are able to add new members.

In addition to these standard requirements, we also evaluated the protocols' security guarantees if the client's secrets were revealed (forward secrecy and future secrecy).

Our Approach

We analyzed the mentioned protocols by reading the source code and debugging the apps. We also used alternative open source implementations of Threema and WhatsApp as a help and we traced the network traffic. When using alternative implementations, we only took incoming traffic into account, which was generated by official applications. Thereby we extracted the protocol descriptions and evaluated them regarding the defined requirements.

Our Findings

In WhatsApp and Threema, the provider was able to manipulate the set of members. Threema only allowed the provider to rewind the set of members to a previous state. As a consequence previously removed members could have been added to the group again. The WhatsApp provider is able to arbitrarily manipulate the member set. Thereby further members and administrators can be added to the group. Since the authenticity of group manipulation is not protected, the WhatsApp provider can set the real group administrator as the source of manipulation even though this administrator was not active.

Since Signal's key exchange protocol provides future secrecy, we also evaluated the protocol's ability to recover into a secure group state after a member's state was compromised. The essential weakness here is that a sender only needs to know the static group ID to send a message to the group. If a group member receives a message with the correct group ID, no verification regarding the current member set takes place but the message is directly added to the group communication. Consequently it is sufficient to retrieve the group ID in order to send messages to the group. Since Signal treats content messages the same way as messages for the manipulation of the group set, an attacker who knows the group ID can add herself to the group and thereby read the subsequent group communication.

In addition to this, in all cases the delivery state of sent messages was not securely provided. Threema's group chats do not inform the sender about the delivery state while Signal and WhatsApp do not protect the delivery information on the end-to-end layer. Therefore the central provider can forge this information and drop messages without letting the communicating parties detect this.

Also the order of messages was manipulable for the providers of the applications such that the provider is able to deliver the messages in a different order than they were sent. Threema's weakness of rewinding a group state results from missing replay attack protection.

Impact of Weaknesses

Even though end-to-end encryption is implemented in all analyzed applications, the central providers can largely manipulate the communication in groups and partially also read it.
In all applications, the provider can undetectably drop and reorder messages during the delivery and thereby manipulate the view of the communication such that further attacks can be obfuscated.
The central servers of WhatsApp can be used to add arbitrary users to groups and thereby receive their communication.
To achieve the same result for Signal, it suffices to retrieve the group ID. An earlier member who left the group once still knows this ID since it is static. However, in contrast to WhatsApp, the origin of the manipulation is correctly displayed in the Signal application (which was not the fact when we started our analysis).

As a result, the end-to-end protection of WhatsApp is not sufficient to reach confidentiality in groups. For Signal no future secrecy is reached in groups and Threema was vulnerable to replay attacks which resulted in further weaknesses.

Responsible Disclosure

We disclosed our findings to the developers and received varying response. Threema updated their protocol in version 3.14 such that our attacks are not feasible anymore. Moxie Marlinspike responded that Signal is "working on an entirely new group mechanism that we should be deploying soon". WhatsApp did not hold out the prospect of fixing the described vulnerabilities.

Beliebte Posts aus diesem Blog

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers. The issue: CORS misconfiguration Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misc…