X (formerly Twitter) ·
Today, we are publishing several practically-exploitable cryptographic vulnerabilities in the Matrix (
@matrixdotorg) standard and their flagship client Element, with Daniel Jones (
@djwj_), Benjamin Dowling (
@DowlingBJ) and Martin R. Albrecht (
@martinralbrecht).
Our attacks break confidentiality and authentication against malicious homeservers. The underlying vulnerabilities show a lack of a unified and formal approach to security guarantees in Matrix.
These vulnerabilities are caused by insecurity by design, by protocol confusion, by a lack of domain separation, or by implementation bugs. Let's explain them now!
(1) is a confidentiality break: a malicious homeserver can add new users (or new devices) under their control to end-to-end encrypted rooms. Once they have been added, they may decrypt future messages sent in the room.
To do this, we exploit the fact that room management messages were not authenticated (nor defined to do so per the spec). While the Matrix spec does not require a mitigation of this behaviour, when a user is added to a room, the Element client will display this in the timeline.
So, to users of Element this is might be detectable. However, this requires careful manual membership list inspection from users as it will appear as a legitimate group membership event.
(2) is an attack against out-of-band verification: in Matrix, each user has a cross-signing identity that serves as the root-of-trust for their cryptographic identity. Two devices establish a secure channel and then share their cryptographic identities with each other.
When each device receives the other's cryptographic identity, they sign it with their own. However, in some areas of the Matrix specification, device identifiers and key identifiers (used to identify cryptographic identities) are used interchangeably.
A malicious homeserver can use this lack of domain separation to convince their target to cryptographically sign a cross-signing identity controlled by the homeserver. This enables a mallory-in-the-middle (MITM) attack.
(3) is a "semi-trusted" impersonation attack: there exist situations where a device is missing inbound Megolm sessions that it should have access to. For example, when a user adds a new device, that device should be able to decrypt messages sent before.
A 'Key Request protocol' can be used to request a copy of needed keys from other devices. However, Matrix does not provide a cryptographic mechanism to ensure that the keys shared are legitimate. Instead, it relies on the fact that it should be completed between trusted devices.
However, no verification was implemented in Element on who to accept key shares from. Our attack exploits this lack of verification in order to send attacker-controlled Megolm sessions to a target device, claiming they belong to a session of the device they wish to impersonate.
This attack triggers a warning, but this is the same warning that legitimate behaviour triggers (hence, semi-trusted).
(4) is a fully trusted impersonation attack: Matrix uses the Megolm protocol to encrypt messages for confidentiality and authentication, and the Olm protocol (a modified version of Signal's X3DH and Double Ratchet protocols) for sharing Megolm sessions between devices.
When a Megolm session is first started, the owner of the session generates an outbound and an inbound session. The inbound session is distributed through an Olm channel.
However, prior to today's fixes, Element only required that messages are encrypted, not that they were encrypted with Olm. This opens Element (and others using the same SDK) to a protocol confusion attack and allows for a stronger version of the previous attack (without warnings)
(5) is an extension of the previous two and exploits the Secure Secret Storage and Sharing (SSSS) module (which provides a means for which a user's devices can share account-level secrets, either via encrypted backups on the homeserver or using a secret sharing protocol).
The protocol confusion described in the previous attack can be exploited by an attacker to impersonate a trusted device (from the same user as the target). The attacker uses the SSSS module to "share" a Megolm backup key under their control with the target device.
The target device then uses these keys to encrypts their backups. With this, an attacker and colluding homeserver are then able to decrypt the backups, giving them access to the plaintext of every Megolm message the target device has access to.
(6) is a theoretical attack and it is an IND-CCA break against the encryption used in both the SSSS protocol and in symmetric Megolm Key Backups.
Specifically, SSSS and Key Backups use AES-CTR, which is then MAC'd for authentication, but initialisation vector (IV) for AES-CTR is not included in the message authentication code (MAC).
This can be used to break the IND-CCA security of the underlying encryption scheme. This attack, however, remains theoretical.
Our attacks together show a rich attack surface in Matrix from both a protocol and implementation perspective. While it is important to perform security audits of implementations, they sometimes fail to catch attacks that are present due to protocol flaws.
