CVE-2020-6514

L'exploit Lors de l'écriture de l'exploit, j'ai initialement modifié les paquets SCTP envoyés au périphérique cible en modifiant le source de WebRTC et en le recompilant. Cela n'était pas pratique pour attaquer des applications à source fermée, j'ai donc finalement opté pour l'utilisation de Frida pour hooker le binaire du périphérique attaquant à la place. La fonctionnalité de hooking de Frida permet d'exécuter du code avant et après l'appel d'une fonction native spécifique, ce qui a permis à mon exploit de modifier les paquets SCTP sortants ainsi que d'inspecter les entrants. Fonctionnellement, cela équivaut à modifier le source du client attaquant, mais au lieu que les modifications soient apportées dans le source à la compilation, elles sont effectuées dynamiquement par Frida à l'exécution. Le code source de l'exploit est disponible ici.

Il y a sept fonctions que le périphérique attaquant doit hooker, comme suit.

usrsctp_conninput // reçoit les SCTP entrants DtlsTransport::SendPacket // envoie les SCTP sortants cricket::SctpTransport::SctpTransport // détecte quand le transport SCTP est prêt calculate_crc32c // calcule la somme de contrôle pour les paquets SCTP sctp_hmac // effectue HMAC pour deviner la clé secrète sctp_hmac_m // signe le paquet SCTP SrtpTransport::ProtectRtp // supprime RTP pour réduire le bruit du tas

Ces fonctions peuvent être hookées en tant que symboles, ou en tant qu'offsets dans le binaire.

Il y a aussi trois offsets d'adresse à partir du binaire du périphérique cible qui sont nécessaires pour que l'exploit fonctionne. L'offset entre la fonction system et la fonction malloc, ainsi que l'offset entre le gadget décrit dans l'article précédent et la fonction malloc font partie de ces offsets. Ces offsets se trouvent dans libc, qui est une bibliothèque système Android, donc ils doivent être déterminés en fonction de la version Android du périphérique cible. L'offset entre l'emplacement de la vtable de cricket::SctpTransport et l'emplacement de malloc dans la table des offsets globaux est également nécessaire. Cela doit être déterminé à partir du binaire qui contient WebRTC dans l'application attaquée.

Notez que les scripts d'exploit fournis ont une limitation sérieuse : à chaque lecture de mémoire, cela ne fonctionne que si le bit 31 du pointeur est défini. Les raisons de cela sont expliquées dans la Partie 2. Le script d'exploit contient un exemple de la façon de corriger cela et de lire n'importe quel pointeur en utilisant les chunks FWD_TSN, mais cela n'est pas implémenté pour chaque lecture. À des fins de test, j'ai réinitialisé l'appareil jusqu'à ce que la bibliothèque WebRTC soit mappée dans un emplacement favorable.

Applications Android Une liste d'applications Android populaires intégrant WebRTC a été déterminée en recherchant des fichiers APK sur Google Play pour une chaîne spécifique dans usrsctp. Environ 200 applications avec plus de cinq millions d'utilisateurs semblaient utiliser WebRTC. J'ai évalué ces applications pour déterminer si elles pouvaient plausiblement être affectées par les vulnérabilités de l'exploit, et quel serait l'impact.

Il s'est avéré que les façons dont les applications utilisent WebRTC sont assez variées, mais peuvent être séparées en quatre catégories principales.

Projection : l'écran et les commandes d'une application mobile sont projetés dans un navigateur de bureau avec le consentement de l'utilisateur pour une meilleure utilisabilité Streaming : le contenu audio et vidéo est envoyé d'un utilisateur à plusieurs utilisateurs. Il y a généralement un serveur intermédiaire, donc l'expéditeur n'a pas besoin de gérer potentiellement des milliers de pairs, et le contenu est enregistré pour une visualisation ultérieure Navigateurs : tous les principaux navigateurs contiennent WebRTC pour implémenter l'API JavaScript WebRTC Conférence : deux utilisateurs ou plus communiquent via audio ou vidéo en temps réel

L'impact des vulnérabilités utilisées dans l'exploit est différent pour chacune de ces catégories. La projection est à faible risque, car beaucoup d'interaction utilisateur est nécessaire pour établir la connexion WebRTC, et l'utilisateur a accès aux deux côtés de la connexion dès le départ, donc il y a peu à gagner en compromettant l'autre côté.

Le streaming est également assez faible risque. Bien qu'il soit possible que certaines applications utilisent des connexions peer-to-peer lorsqu'un flux a un faible nombre de spectateurs, elles utilisent généralement un serveur intermédiaire qui termine la connexion WebRTC du pair émetteur et démarre de nouvelles connexions avec les pairs récepteurs. Cela signifie que l'attaquant ne peut généralement pas envoyer de paquets malformés directement à un pair. Même avec une configuration où le streaming est effectué en peer-to-peer, une interaction utilisateur est nécessaire pour que la cible visionne le flux, et il n'y a souvent aucun moyen de limiter qui peut accéder à un flux. Pour cette raison, les applications de streaming qui utilisent WebRTC ne sont probablement pas utiles pour des attaques ciblées. Bien sûr, il est possible que ces vulnérabilités affectent les serveurs utilisés par les services de streaming, mais cela n'a pas été étudié dans cette recherche.

Les navigateurs sont presque certainement vulnérables à la plupart des bugs dans WebRTC, car ils permettent un grand contrôle sur la façon dont il est configuré. Pour exploiter un tel bug dans un navigateur, un attaquant devrait configurer un hôte qui agit comme l'autre pair dans la connexion peer-to-peer, et convaincre la cible de visiter une page web qui démarre un appel vers cet hôte. Dans ce cas, la vulnérabilité aurait un impact similaire à d'autres vulnérabilités de corruption mémoire en JavaScript.

La conférence est l'utilisation la plus risquée de WebRTC, mais l'impact réel d'une vulnérabilité dépend beaucoup de la façon dont les utilisateurs d'une application se contactent. La conception la plus risquée est une application où tout utilisateur peut contacter n'importe quel autre utilisateur sur la base d'un identifiant. Certaines applications exigent que le destinataire ait interagi d'une manière spécifique avec l'appelant avant qu'un appel puisse être effectué, ce qui rend plus difficile pour les utilisateurs de contacter une cible et réduit généralement le risque. Certaines applications exigent que les utilisateurs entrent un code ou visitent un lien pour démarrer un appel, ce qui a un effet similaire. Il existe également un grand groupe d'applications où il est difficile ou impossible d'appeler un utilisateur spécifique, par exemple les applications de chat roulette, et les applications qui ont des fonctionnalités permettant à un utilisateur de démarrer un appel vers le support client.

Pour cette recherche, je me suis concentré sur les applications de conférence qui permettent aux utilisateurs de contacter d'autres utilisateurs spécifiques. Cela a réduit ma liste de 200 applications à 14 applications, comme suit.