Récemment la nouvelle a été publiée que des vulnérabilités ont été identifiées (CVE-2021-40823, CVE-2021-40824) dans la plupart des applications clientes pour la plateforme de communication décentralisée Matrice, qui permettent d'obtenir des informations sur les clés utilisées pour transférer les messages dans les chats cryptés de bout en bout (E2EE).
Un attaquant qui a compromis l'un des utilisateurs du chat peut déchiffrer les messages précédemment envoyés à cet utilisateur à partir d'applications clientes vulnérables. Une opération réussie nécessite l'accès au compte du destinataire du message et l'accès peut être obtenu à la fois par une fuite des paramètres du compte et par le piratage du serveur Matrix via lequel l'utilisateur se connecte.
Il est mentionné que les vulnérabilités sont les plus dangereuses pour les utilisateurs de salles de discussion cryptées auxquelles les serveurs Matrix contrôlés par les attaquants sont connectés. Les administrateurs de ces serveurs peuvent tenter d'usurper l'identité des utilisateurs du serveur pour intercepter les messages envoyés au chat à partir d'applications clientes vulnérables.
Vulnérabilités sont causées par des erreurs logiques dans les implémentations du mécanisme pour accorder le réaccès aux clés propositions dans les différents clients détectés. Les implémentations basées sur les bibliothèques matrix-ios-sdk, matrix-nio et libolm ne sont pas vulnérables aux vulnérabilités.
En conséquence, des vulnérabilités apparaissent dans toutes les applications qui ont emprunté le code problématique y ils n'affectent pas directement les protocoles Matrix et Olm/Megolm.
Plus précisément, le problème affecte le client principal Element Matrix (anciennement Riot) pour le Web, le bureau et Android, ainsi que les applications et bibliothèques clientes tierces, telles que FluffyChat, Nheko, Cinny et SchildiChat. Le problème n'apparaît pas dans le client iOS officiel, ni dans les applications Chatty, Hydrogen, mautrix, purple-matrix et Siphon.
Les versions corrigées des clients concernés sont désormais disponibles ; il est donc demandé qu'il soit mis à jour dès que possible et nous nous excusons pour la gêne occasionnée. Si vous ne pouvez pas effectuer la mise à niveau, envisagez de garder les clients vulnérables hors ligne jusqu'à ce que vous le puissiez. Si les clients vulnérables sont hors ligne, ils ne peuvent pas être amenés à révéler les clés. Ils peuvent être de nouveau en ligne en toute sécurité une fois qu'ils sont mis à jour.
Malheureusement, il est difficile, voire impossible, d'identifier rétroactivement les instances de cette attaque avec des niveaux de journalisation standard présents à la fois sur les clients et les serveurs. Cependant, étant donné que l'attaque nécessite de compromettre le compte, les administrateurs de serveur domestique peuvent souhaiter examiner leurs journaux d'authentification pour tout signe d'accès inapproprié.
Le mécanisme d'échange de clés, dans la mise en œuvre duquel des vulnérabilités ont été trouvées, permet à un client qui ne dispose pas des clés de déchiffrer un message de demander des clés à l'appareil de l'expéditeur ou à d'autres appareils.
Par exemple, cette capacité est nécessaire pour assurer le décryptage des anciens messages sur le nouvel appareil de l'utilisateur ou dans le cas où l'utilisateur perdrait des clés existantes. La spécification du protocole prescrit par défaut de ne pas répondre aux demandes de clés et de ne les envoyer automatiquement qu'aux appareils vérifiés du même utilisateur. Malheureusement, dans les implémentations pratiques, cette exigence n'a pas été satisfaite et les demandes d'envoi de clés ont été traitées sans identification de périphérique appropriée.
Les vulnérabilités ont été identifiées lors d'un audit de sécurité du client Element. Les correctifs sont désormais disponibles pour tous les clients en difficulté. Il est conseillé aux utilisateurs d'installer d'urgence les mises à jour et de déconnecter les clients avant d'installer la mise à jour.
Il n'y avait aucune preuve d'exploitation de la vulnérabilité avant la publication de l'examen. Il est impossible de déterminer le fait d'une attaque en utilisant les journaux client et serveur standard, mais comme l'attaque nécessite de compromettre le compte, les administrateurs peuvent analyser la présence de connexions suspectes en utilisant les journaux d'authentification sur leurs serveurs, et les utilisateurs peuvent évaluer la liste des appareils liés à leur compte pour les reconnexions récentes et les changements d'état de confiance.
source: https://matrix.org