Messenger billed as better than Signal is riddled with vulnerabilities

Academic researchers have discovered serious vulnerabilities in the core of Threema, an instant messenger that its Switzerland-based developer says provides a level of security and privacy “no other chat service” can offer. Despite the unusually strong claims and two independent security audits Threema has received, the researchers said the flaws completely undermine assurances of confidentiality and authentication that are the cornerstone of any program sold as providing end-to-end encryption, typically abbreviated as E2EE.

Threema has more than 10 million users, which include the Swiss government, the Swiss army, German Chancellor Olaf Scholz, and other politicians in that country. Threema developers advertise it as a more secure alternative to Meta’s WhatsApp messenger. It’s among the top Android apps for a fee-based category in Switzerland, Germany, Austria, Canada, and Australia. The app uses a custom-designed encryption protocol in contravention of established cryptographic norms.

The seven deadly flaws

Researchers from the Zurich-based ETH research university reported on Monday that they found seven vulnerabilities in Threema that seriously call into question the true level of security the app has offered over the years. Two of the vulnerabilities require no special access to a Threema server or app to cryptographically impersonate a user. Three vulnerabilities require an attacker to gain access to a Threema server. The remaining two can be exploited when an attacker gains access to an unlocked phone, such as at a border crossing.

A diagram showing the three threat models for the attack: when an attacker has access to (1) the network communication, (2) the Threema servers, and (3) the victim device itself.

Credit: Paterson et al.

“In totality, our attacks seriously undermine Threema’s security claims,” the researchers wrote. “All the attacks can be mitigated, but in some cases, a major redesign is needed.”

The seven vulnerabilities the researchers uncovered include:

1. External actor with no special access
   1. In the event an ephemeral key is exposed even once, an attacker can permanently impersonate the client to the server and then obtain all metadata in all E2EE messages. This is a remarkable shortcoming because ephemeral keys should never be able to authenticate a user. With Threema, leaking of an ephemeral key has the same effect as leaking a long-term key. Sloppy key management also causes Threema to reuse ephemeral keys in places they should never be reused.
   2. A flaw in the way Threema's client-to-server (C2S) protocol interacts with its end-to-end (E2E) protocol that causes a user to create a special Threema value known as a vouch box and send it to the attacker. The attacker can exploit it by tricking a user into sending a set of characters (u9j6ߓ'jjखԻ^߃1כW:-́;ܡRA) to a special but innocuous account. One possible way for an attacker to do this is to send spam to a large number of users that tells them to send the character string to a specific account in order to be eligible for a prize. From that point on, the attacker can impersonate the hacked client to the server.

      

      Attack 1.2 in practice: on the left, a suitable keypair that is base64 encoded. The public key bytes 1 to 31 , also encoded in the QR code, all consist of printable UTF-8 characters. On the right, the *LYTAAAS Threema gateway account (since revoked), with the hijacked public key of the server. User U sending the contents of the QR to *LYTAAAS as a message will allow *LYTAAAS to authenticate to Threema as the U.

      

      A figure showing the cross-protocol interaction of an E2E and a C2S session. The attacker claims the public key of the server and knows a keypair of the form (z, Z = 0x01 ∥ σ ∥ 0x01). They convince the victim U to send σ to them as an E2E text message (in blue, Left side). The attacker can now start a session of the C2S protocol (Right side) where they use the “ephemeral” keypair (z, Z) and the corresponding vouch box EK2 (Z) (in blue) in order to authenticate as U to the server.

2. When an attacker has compromised a Threema server:
   1. A lack of integrity protection on the message metadata. As a result, an attacker can surreptitiously reorder and/or delete messages sent from one client to another.
   2. Faulty usage nonce handling allows for “replay and reflection” attacks, in which the threat actor resends old messages and sends a user a message that user previously sent to someone else.
   3. A bug in the challenge-and-response protocol used for a client to authenticate itself to the server during registration. During the process, the client proves possession of its private key by encrypting a server-chosen message that’s encrypted with a server-chosen public key. A compromised server can exploit this design to create “kompromat,” or potentially incriminating messages that can be delivered at any later time to a targeted user. Threema patched this vulnerability in December 2021, when a separate researcher spotted it.
3. When an attacker gains access to an unlocked phone running Threema:
   1. A feature that allows users to export their private key from one device to another. Poor design decisions make it trivial for an attacker to use the key to clone a Threema account, unless users opt in to using a PIN or password to protect their account. From there, the attacker can go on to access all future messages. Combined with a compromised Threema server, the adversary can also obtain all previously sent messages.
   2. Message compression that occurs before encryption when Threema creates a backup, combined with the ability for an attacker to use a nickname feature to inject chosen strings into the backup. This allows a more sophisticated attacker to observe the size of the backup file over multiple iterations and eventually recover the user’s private key.

The composition of the end-to-end and client-to-server protocol. Each client establishes a secure channel with the server using the C2S protocol (in yellow) to send and receive E2E-encrypted messages from other users, which are relayed via the server (the connection in green).

Matteo Scarlata and Kien Tuong Truong, two of the ETH researchers who co-authored the paper, said that all the flaws stem from a single trait: the use of a custom protocol rather than an established one that has stood the test of time. In an email the researchers wrote:

The common cause is “rolling your own protocol”. At the time when Threema first released, the space of messaging protocols was still pretty empty, but OTR (from 2004) did already achieve forward secrecy. Threema is entirely built upon NaCl, the cryptographic library by Daniel J Bernstein. It was interesting to see, when talking to the team, that some of the bad design decisions (such as not authenticating the metadata of messages) arose from limitations of the NaCl APIs. Another point to be made is that a company whose main product is based on cryptography, should always have a cryptographer at hand to assess its security and to propose already-existing protocols when possible, for example the battle-tested TLS instead of creating their bespoke client-to-server protocol.

The Threema protocols lack(ed) basic properties that are nowadays considered de rigueur for a messenger app to be regarded as secure: forward secrecy with respect to a malicious server, and protection against replay, reflection, and reordering attacks. While developers mostly stopped “rolling their own” cryptographic primitives, rolling your own protocol can be as dangerous: the recent attacks on Mega and Matrix are also an example of this. We need more provable security, and more scrutiny for cryptographic protocols before they are deployed.

In a web post, Threema officials said the vulnerabilities applied to an old protocol that's no longer in use. It also said the researchers were overselling their findings.

"While some of the findings presented in the paper may be interesting from a theoretical standpoint, none of them ever had any considerable real-world impact," the post stated. "Most assume extensive and unrealistic prerequisites that would have far greater consequences than the respective finding itself."

Left out of the statement is that the protocol the researchers analyzed is old because they disclosed the vulnerabilities to Threema, and Threema updated it.

Much acclaim about nothing

There’s no evidence that any of the flaws have been actively exploited, and as noted earlier, the first two attacks, 1.1 and 1.2, are likely out of reach of all but the most skilled and well-resourced attackers. By contrast, attacks 2.1, 2.2, and 2.3, which rely on a compromised Threema server, are easy to carry out on either an on-premises server operated by an organization or on Threema itself. It would also be easy for an attacker to conceal such exploits.

The most practical exploit is 3.1, the unprotected export of the private key. Until recently, Threema provided no forward secrecy, which virtually all modern encryption protocols use to ensure that a compromised key can’t be used to decrypt encrypted messages sent in the past or future. That means that when the exploit is combined with the server exploit, “any Threema device left unlocked in the hands of an adversary for a few minutes could be permanently compromised and all messages sent and received could be decrypted,” Scarlata said.

Threema has introduced mitigations after the researchers privately shared their findings. The updates include a new custom protocol named Ibex, which fixes vulnerabilities 2.1 and 2.2. Threema developers also removed compression altogether, a change that fixes vulnerability 3.2. Attacks 1.1 and 1.2 were mitigated by use of better key separation, using a key derivation function. Threema has also added a new check that will allow non-compromised servers to detect the impersonation attacks described in 1.1 and 1.2.