En janvier 2019, une faille critique a été signalée dans la fonctionnalité de discussions de groupe FaceTime d’Apple qui permettait aux utilisateurs de lancer un appel vidéo FaceTime et d’écouter les cibles en ajoutant leur propre numéro en tant que troisième personne dans une discussion de groupe avant même que la personne sur le l’autre extrémité a accepté l’appel entrant.

La vulnérabilité a été jugée si grave que le fabricant de l’iPhone a complètement supprimé la fonctionnalité de discussion de groupe FaceTime avant que le problème ne soit résolu dans une mise à jour iOS ultérieure.

Depuis lors, un certain nombre de lacunes similaires ont été découvertes dans plusieurs applications de chat vidéo telles que Signal, JioChat, Mocha, Google Duo et Facebook Messenger – le tout grâce au travail de la chercheuse Google Project Zero Natalie Silvanovich.

« Tandis que [the Group FaceTime] bogue a été rapidement corrigé, le fait qu’une vulnérabilité aussi grave et facile à atteindre se soit produite en raison d’un bogue logique dans une machine d’état appelante – un scénario d’attaque que je n’avais jamais vu envisagé sur aucune plate-forme – m’a fait me demander si d’autres machines d’état avaient des vulnérabilités également, « Silvanovich a écrit dans un mardi approfondi de son travail.

Comment fonctionne la signalisation dans WebRTC?

Bien que la majorité des applications de messagerie reposent aujourd’hui sur WebRTC pour la communication, les connexions elles-mêmes sont créées en échangeant des informations de configuration d’appel à l’aide du protocole de description de session (SDP) entre pairs dans ce qu’on appelle la signalisation, qui fonctionne généralement en envoyant une offre SDP du côté de l’appelant, à laquelle l’appelé répond avec une réponse SDP.

En d’autres termes, lorsqu’un utilisateur lance un appel WebRTC vers un autre utilisateur, une description de session appelée « offre » est créée contenant toutes les informations nécessaires à l’établissement d’une connexion – le type de média envoyé, son format, le protocole de transfert utilisé et l’adresse IP et le port du point final, entre autres. Le destinataire répond alors avec une «réponse», y compris une description de son point final.

L’ensemble du processus est un machine d’état, qui indique « où dans le processus de signalisation de l’échange d’offre et de réponse la connexion est actuellement. »

Également inclus en option dans le cadre de l’échange offre / réponse, la capacité des deux pairs à échanger Candidats SDP les uns aux autres afin de négocier le lien réel entre eux. Il détaille les méthodes qui peuvent être utilisées pour communiquer, quelle que soit la topologie du réseau – une structure WebRTC appelée Interactive Connectivity Establishment (LA GLACE).

Une fois que les deux pairs sont d’accord sur un candidat mutuellement compatible, le SDP de ce candidat est utilisé par chaque pair pour construire et ouvrir une connexion, à travers laquelle le média commence alors à circuler.

De cette manière, les deux appareils partagent entre eux les informations nécessaires pour échanger de l’audio ou de la vidéo via la connexion peer-to-peer. Mais avant que ce relais puisse se produire, les données multimédias capturées doivent être attachées à la connexion à l’aide d’une fonction appelée pistes.

Bien que l’on s’attende à ce que le consentement de l’appelé soit garanti avant la transmission audio ou vidéo et qu’aucune donnée ne soit partagée tant que le récepteur n’a pas interagi avec l’application pour répondre à l’appel (c’est-à-dire avant d’ajouter des pistes à la connexion), Silvanovich a observé un comportement contraire .

Plusieurs applications de messagerie affectées

Non seulement les failles des applications permettaient aux appels d’être connectés sans interaction de l’appelé, mais elles permettaient également potentiellement à l’appelant de forcer un appareil appelé à transmettre des données audio ou vidéo.

• Signal (corrigé en septembre 2019) – Une faille d’appel audio dans l’application Android de Signal a permis à l’appelant d’entendre l’environnement de l’appelé en raison du fait que l’application n’a pas vérifié si l’appareil recevant le message de connexion de l’appelé était l’appelant dispositif.

• JioChat (fixé en juillet 2020) et Moka (corrigé en août 2020) – Ajout de candidats aux offres créées par Reliance JioChat et les applications Android Mocha de Viettel qui permettaient à un appelant de forcer l’appareil cible à envoyer de l’audio (et de la vidéo) sans le consentement de l’utilisateur. Les failles provenaient du fait que la connexion peer-to-peer avait été établie avant même que l’appelé ne réponde à l’appel, augmentant ainsi la «surface d’attaque à distance de WebRTC».

• Facebook Messenger (corrigé en novembre 2020) – Une vulnérabilité qui aurait pu permettre à un attaquant connecté à l’application de lancer simultanément un appel et d’envoyer un message spécialement conçu à une cible qui est connectée à la fois à l’application et à un autre client Messenger tel en tant que navigateur Web, et commencez à recevoir l’audio de l’appareil appelé.

• Google Duo (corrigé en décembre 2020) – Une condition de concurrence entre la désactivation de la vidéo et la configuration de la connexion qui, dans certaines situations, pourrait amener l’appelé à fuir des paquets vidéo d’appels sans réponse.

D’autres applications de messagerie comme Telegram et Viber se sont avérées ne présenter aucun des défauts ci-dessus, bien que Silvanovich ait noté que des défis importants de rétro-ingénierie lors de l’analyse de Viber rendaient l’enquête « moins rigoureuse » que les autres.

« La majorité des machines d’état appelantes que j’ai étudiées présentaient des vulnérabilités logiques qui permettaient de transmettre du contenu audio ou vidéo de l’appelé à l’appelant sans le consentement de l’appelé », a conclu Silvanovich. « C’est clairement un domaine qui est souvent négligé lors de la sécurisation des applications WebRTC. »

« La majorité des bogues ne semblent pas être dus à une mauvaise compréhension des fonctionnalités de WebRTC par les développeurs. Au lieu de cela, ils étaient dus à des erreurs dans la façon dont les machines d’état sont implémentées. Cela dit, un manque de connaissance de ces types de problèmes était probablement un facteur. , » elle a ajouté.

« Il est également préoccupant de noter que je n’ai examiné aucune fonctionnalité d’appel de groupe de ces applications, et que toutes les vulnérabilités signalées ont été trouvées dans des appels peer-to-peer. C’est un domaine de travail futur qui pourrait révéler des problèmes supplémentaires. »