Privacy Checkup: Finden Sie heraus, wie es um Ihre Privatsphäre im Internet steht

Mehr erfahren

Stellungnahme zu ETH-Findings

· English version

Aktualisiert am 10.1.2023, 20:53 («Das Wichtigste in Kürze» hinzugefügt; Lead präzisiert)

Das Wichtigste in Kürze

  • Forscher der ETH Zürich haben ein Paper über das Kommunikationsprotokoll von Threema veröffentlicht.
  • Wir haben die Kritikpunkte zu Herzen genommen und danken den Forschern für ihre Bemühungen.
  • Sämtliche Issues wurden von uns innerhalb weniger Wochen behoben.
  • Die Einführung eines neuen Protokolls «Ibex» war seit längerer Zeit geplant und koinzidierte mit der Disclosure Period der Forscher.
  • Alle Apps wurden mit den Verbesserungen aktualisiert.

Letztes Jahr hat ein Student des Informatik-Departements der ETH Zürich seine Masterarbeit über Threemas Kommunikationsprotokoll geschrieben. Die ETH Zürich hat die Arbeit nun als Paper bzw. Preprint veröffentlicht. Die vorgelegten Findings wurden bereits berücksichtigt und gelten nicht mehr für Threemas gegenwärtiges Kommunikationsprotokoll «Ibex». Keines der Findings hatte jemals nennenswerte Relevanz in der Praxis.

Wir möchten uns bei Kien Tuong Truong sowie bei seinen Betreuern, Prof. Kenny Paterson und Matteo Scarlata von der Applied Cryptography Group der ETH Zürich, dafür bedanken, dass sie uns auf die Findings aufmerksam gemacht und sich während mehrerer Monate mit Threemas Verschlüsselung beschäftigt haben.

Auch wenn manche der vorgestellten Findings aus theoretischer Sicht interessant sein mögen, hatte keines von ihnen jemals nennenswerte Auswirkungen in der Praxis. Die meisten gehen von umfassenden und realitätsfernen Vorbedingungen aus, die an sich schon weit folgenschwerere Konsequenzen hätten als das jeweilige Finding selbst.

Eine solche Vorbedingung ist z.B. der physische Zugriff auf ein entsperrtes Android-Gerät über einen Zeitraum von ca. zwölf Stunden (und ohne, dass in Threema eine Passphrase gesetzt ist). In einem solchen Szenario muss das gesamte Gerät – und somit trivialerweise auch Threema – als kompromittiert betrachtet werden. Denn jede App kann immer nur so sicher sein wie das Gerät bzw. Betriebssystem, auf dem sie läuft.

Trotz des theoretischen Charakters dieser Findings haben wir im Rahmen der kontinuierlichen Bemühung, unsere strengen Integritäts- und Sicherheitsstandards aufrechtzuerhalten, geeignete Massnahmen implementiert, um auch all jene Findings zu berücksichtigen, welche nicht schon durch das Ibex-Protokoll obsolet wurden (s. Technische Details).

  • Weitere Informationen über Threemas kryptografisches Kommunikationsprotokoll «Ibex», das während eineinhalb Jahren entwickelt wurde und Perfect Forward Secrecy auf Ende-zu-Ende-Ebene der Verschlüsselung bietet, finden Sie in diesem Blogbeitrag.

Bevor wir auf die einzelnen Findings im Detail eingehen, hier eine Zusammenfassung:

  • Ein Finding (Nr. 5) ist nicht neu, sondern wurde bereits vor einiger Zeit von einem Sicherheitsforscher entdeckt und 2021 von Threema berücksichtigt (was dem Autor dieser Arbeit bekannt war).
  • Ein Finding (Nr. 1) ist von rein theoretischer Bedeutung und hat keinerlei Anwendbarkeit in der Praxis.
  • Vier Findings (Nr. 3, 4, 6 und 7) setzen ein sehr weit gefasstes Bedrohungsmodell sowie umfangreiche Vorbedingungen voraus, z.B. physischen Zugriff auf ein entsperrtes Mobilgerät über einen ausgedehnten Zeitraum oder direkten Zugriff auf die entsperrte Threema-App.
  • Ein Finding (Nr. 2), das auf Social Engineering beruht, hätte in der Praxis nicht angewendet werden können und bewusste, umfassende und ungewöhnliche Kooperation mit der Zielperson erfordert.

Bug-Bounty-Programm

Die Threema-Apps sind Open Source, und Sicherheitsforscher haben jederzeit die Möglichkeit, sie unabhängigen Prüfungen zu unterziehen. Dabei winkt pro relevantem Sicherheitshinweis eine Prämie von bis zu 10’000 CHF. Ausserdem werden regelmässig externe Experten mit der systematischen Überprüfung von Threemas Sicherheit betraut.

Technische Details (Englisch)

Finding 1 (C2S Ephemeral Key Compromise)

This theoretical finding would have allowed an adversary who has somehow managed to obtain an ephemeral private key used for connecting to the chat server, as well as a session transcript, to impersonate the user towards the chat server and thus view metadata of received messages and prevent selected messages from being delivered.

In practice, in order to obtain the ephemeral private key, the adversary would have needed the ability to read app memory contents or influence the device’s random number generator – at which point the adversary would have many other options to intercept any information processed by the user’s device in any app.

Thus, there is no practicability at all. No way of obtaining an ephemeral private key was found, even with physical access to the targeted user’s unlocked device.

  • Current app versions (Threema ≥5.0 for Android and Threema ≥4.8.5 for iOS) replace the legacy chat server authentication procedure (which was modelled after CurveCP) with a new protocol that solves this issue (along with finding 2). Ephemeral key caching has also been completely removed.

Finding 2 (Vouch Box Forgery)

This finding is described in two variants, both relying on social engineering, requiring extensive cooperation by the targeted user, and theoretically giving an adversary the opportunity to view metadata for incoming messages and prevent selected messages from being delivered.

  • Both variants are not reproducible in practice as Threema’s chat server verifies the validity of public keys before accepting them. Current app versions (Threema ≥5.0 for Android and Threema ≥4.8.5 for iOS) replace the legacy chat server authentication procedure with a new protocol that resolves the root issue with both variants (along with finding 1).

Finding 2a (Vouch Box Forgery – Threema Gateway)

This variant exploits a payload confusion issue in the legacy chat server authentication procedure combined with the use of a Threema Gateway ID with a specifically chosen public key.

An adversary would have needed to do all of the following:

  • Apply and pay for a Threema Gateway ID with a public key equivalent (for ECDH purposes) to the current chat server public key.
  • Spend the computing power of about 8,000 CPU cores for one week to find a Curve25519 private key whose corresponding public key has a certain form that allows it to be expressed in a text message.
  • Convince the targeted user to send this specially crafted “garbage” text message to the adversary’s Threema Gateway ID on average about 200 times for the exploit to work with adequate probability.

As this variant requires the purchase of a Threema Gateway ID with a specifically chosen public key, we can confirm that no such Gateway IDs exist, other than those created by the paper’s author. Therefore, there has never been an attempt to create such a Gateway ID in the wild. We have blocked the creation of new Gateway IDs with such public keys, rendering exploitation impossible.

Note that the adversary could not send any messages from their Threema Gateway ID (as they do not have the corresponding private key) and thus would have needed to use another channel or another Threema ID to communicate with the targeted user.

Threema OnPrem is not affected by this theoretical issue, as it requires administrative access to the on-premises server instance for the creation of Gateway IDs.

Finding 2b (Vouch Box Forgery – Android data backup)

This variant exploits a bug in a common ZIP library for Java (Zip4j). However, the prerequisites for this variant are so numerous and difficult to meet that a successful exploit would be extremely unlikely. Specifically, an adversary would need to do all of the following:

  • Obtain read and write access to the ZIP data backup created by a user of the Android version of the Threema app.
  • Know where in the encrypted and compressed contact list backup inside the ZIP file his public key is stored. It could be anywhere in a range of typically several thousand bytes; the adversary needs to guess blindly, must hit the exact byte offset and typically only gets one chance (see below).
  • Overwrite the location thus found/guessed, XORing in the difference between their own (compressed) public key and the server’s public key (as ZIP encryption uses AES-CTR). The fact that the backup data is compressed further complicates the exploit to the point where the adversary would essentially need to know the entire exact backup contents in advance.
  • Wait for (or entice) the user to restore their Threema app data from the tampered backup ZIP. If the offset guessed in the second step is wrong, then the exploit will not work.
  • Convince the targeted user to send a specially crafted “garbage” text message to the adversary’s Threema ID on average about 200 times for the exploit to work with adequate probability.

Finding 3 (Message Reordering and Omission)

A compromised Threema server could reorder or omit messages while they are in transit.

  • Perfect Forward Secrecy (PFS) has been introduced last year with our new Ibex protocol. The paper describes the situation prior to Ibex. With PFS, reordered or missing messages are detected, and the user is warned.

Note that even in 1:1 chats without PFS, omissions would be apparent to the sender anyway as they will not receive a delivery receipt. Also, reordering is only possible while a bundle of messages is in transit (typically messages are delivered/pushed immediately and individually as soon as they have been transmitted).

Finding 4 (Replay and Reflection)

A compromised Threema server could replay or reflect messages to a user who has lost their nonce database due to reinstalling the app. Only messages received prior to reinstallation could be replayed or reflected.

  • Perfect Forward Secrecy (PFS) has been introduced last year with our new Ibex protocol. The paper describes the situation prior to Ibex. With PFS, replayed/reflected messages are detected and dropped even if the user has lost the nonce database.

Finding 5 (Kompromat)

A compromised Threema directory server could theoretically trick a client into encrypting an arbitrary message to another user.

  • This is an old finding discovered by another researcher (Jonathan Krebs) and already addressed by Threema in 2021 (as the author of this paper was aware of). Furthermore, in current app versions (Threema ≥5.0 for Android and Threema ≥4.8.5 for iOS), the legacy directory server authentication procedure has been replaced.

Finding 6 (Cloning via Threema ID Export)

If a targeted user handed a completely unprotected and unlocked device to the adversary and the app had no PIN or biometric protection set, the adversary could, by design, clone the user’s Threema ID by means of the ID export feature. However, had the adversary connected to the Threema server at the same time as the targeted user, the latter would have been notified.

The ID export feature is designed to let users take control of their private key so they can move their Threema ID to another device without losing it when they switch to a new device. As Threema does intentionally not have traditional accounts tied to a username/password or a phone number, the app assumes that whoever has the unlocked device and also knows the app PIN (if set) is authorized to export the ID.

Users can easily guard against this issue by setting an app PIN or enabling biometric protection. Threema Work and OnPrem admins also have fine-grained control over their users’ backup/export capability via MDM parameters (th_disable_id_export and others).

  • To ensure that the user will be informed even if a private key has been compromised due to careless actions by the user, we have further improved the detection method that will alert the user if there has been any connection using their Threema ID from another device since the last time that they used the app.

Finding 7 (Private Key Recovery through Compression Side-Channel)

This finding exploits a compression oracle in the generation of Threema Safe backup data to recover the private key of the Threema ID. It would have required physical access to an unlocked device for an extended period of time (in the order of twelve hours) and would have only worked in the Android version of the app (due to implementation details) and also only if no passphrase was set in the app.

  • Threema Safe compression is disabled in current app versions (Threema ≥5.0 for Android and Threema ≥4.8.5 for iOS), thus resolving this issue.