Zoom, la sécurité et le respect de la vie privée

Dernière mise à jour : 29/4/2020

Zoom est devenu depuis début mars le logiciel le plus exposé de la planète : un passage de 10 millions à 200 millions de connexion par jour, c’est colossal et tout ça sans impact sur la qualité du service. Mais cela a un revers : quand on devient un logiciel très utilisé, tout ce qu’il y a de hacker et trolls dans le monde cherche les failles pour pouvoir tirer parti de l’infrastructure à une fin ou une autre.

Dans le cas de Zoom, cela a révélé un certain nombre de problèmes liés à des choix légers ou contestables dans l’implémentation de certaines fonctionnalités ou dans la façon d’installer les clients (essentiellement sur le Mac pour ce dernier point), pour l’essentiel sans conséquence pratique. Certaines fonctionnalités ont aussi été détournée, par exemple le partage d’écran pour diffuser des images pornographiques ou ultraviolentes (pratique connue sous le nom de Zoombombing). Dans tous les cas, Zoom a réagi extrêmement rapidement : tous les problèmes ont été corrigés dans les 24 à 48h suivant leur diffusion, des guides de bonnes pratiques pour se prémunir des détournements de fonctionnalités comme le Zoombombing ont été publiés immédiatement. Pour plus de détail sur les différents problèmes recensés et l’analyse qui en a été faite, voir ci-dessous.

Comme résumé par un des principaux responsables de la sécurité au CERN : « those days, Zoom is the most scrutinized software currently on the market. Up to them to benefit from that and make security & privacy their core feature » (Zoom est le logiciel du marché le plus scruté actuellement, c’est à eux d’en bénéficier et de démontrer que la sécurité et la protection des données personnelles sont au coeur de leurs préoccupations). Il y  a des raisons de croire que le message a été entendu : Zoom a décidé le 1/4 un « feature freeze » de Zoom de 90 jours (en clair un arrêt de tous les développements de nouvelles fonctionnalités) pour mettre les toutes les forces de développements dans la correction de toutes les faiblesses identifiées. Depuis, des évolutions tant du client que du service ont apporté des solutions à l’ensemble des problèmes identifiés, y compris un encryptage plus robuste des communications (en cours de déploiement avec la version 5.0 du client) et la possibilité d’exclure des zones géographiques du transit de l’information.

Le Département Informatique d’IJCLAb prend très au sérieux les enjeux de sécurité et de protection des données personnelles et nous vous invitons à tenir compte des conseils publiés sur la page Zoom de ce site, en particulier pour se prémunir du Zoombombing. Pour l’instant, nous partageons l’analyse du CERN et d’un certain nombre d’autres acteurs (Ecole Polytechnique par exemple) sur le sérieux de la réponse de Zoom et ne voyons aucune raison qui justifierait la remise en cause du choix du seul service de video-conférence qui ait démontré sa capacité de passage à l’échelle, même dans une période de forte demande comme celle du confinement. Par ailleurs, nous avons informé la DR4 du CNRS de notre choix, avec notre analyse des différents problèmes mentionnés à propos de Zoom. La réponse reçue en retour affirme :

« votre démarche est très constructive et tout à fait justifiée au vu des besoins que vous avez. Vous avez fait une analyse des risques et vous avez interdit l’utilisation de cet outil pour les données sensibles, cela respecte totalement les consignes du CNRS.« 

Analyse des problèmes Zoom dans le contexte IJCLab

Cette section contient une analyse tous les problèmes signalés à propos du service et des clients Zoom, les réponses de Zoom et chaque fois que cela était nécessaire, les mesures mises en oeuvre en termes de configuration pour que les utilisateurs IJCLab ne soient pas exposés à ces problèmes.

Dans l’analyse qui suit nous distinguons les problèmes de sécurité, ceux qui permettent via Zoom de prendre le contrôle de la machine cliente ou de certaines de ses ressources, des problèmes de protection des données personnelles (privacy).

Sécurité

  • Escalade de privilèges via l’installeur MacOS : problème résolu le 2/4 par une nouvelle version du client, 48h après la publication de la vulnérabilité. Même si le terme “escalade de privilège” peut faire peur, le risque réel était proche de 0 puisqu’il fallait déjà avoir un accès local à la machine. Donc soit être son utilisateur, soit avoir déjà réussi à installer un code malicieux permettant d’avoir accès à la machine et donnant déjà probablement la capacité de faire l’escalade de privilège.
  • Vol de mot de passe sous Windows en mettant des paths UNC dans le chat pour qu’un autre utilisateur clique dessus. Cette vulnérabilité a été corrigée le 2/4 par une nouvelle version du client, 48h après sa publication. Son risque était essentiellement théorique dans un contexte comme IJCLab pour deux raisons : la personne malicieuse devait participer à la réunion, or les invitations aux réunions IJCLab ne sont pas envoyées urbi et orbi; il semble hautement improbable qu’un path UNC soit tapé dans un chat de réunion, le partage de fichier dans notre environnement utilisant des services type Owncloud/MyCore.
  • Possibilité pour un utilisateur indésirable de rejoindre l’instance IJCLab et de passer des appels vidéo “malveillants” avec d’autres utilisateurs IJCLab (ou non) : rendu impossible par la configuration de notre instance qui impose que l’identifiant de l’utilisateur soit son adresse mail @ijclab.in2p3.fr. C’est-à-dire un utilisateur légitime de IJCLab (pour créer le compte, il faut répondre à un message de validation envoyé à cet email).
  • Transmissions des clés de chiffrement vers des serveurs chinois : en fait il s’agit du fait d’avoir fait transiter du trafic non asiatique par des serveurs chinois, ce qui inclut donc la transmission des clés pour pouvoir faire l’encryptage tout au long du trajet. Zoom s’est expliqué sur cette anomalie qui a duré quelques jours : pour faire face à la croissance exponentielle du trafic, Zoom a relaxé certaines règles concernant le délestage de trafic entre serveurs et une erreur de configuration a conduit à ce transit considéré indésirable par beaucoup, au vu de certaines pratiques en matière de surveillance de trafic. Zoom a corrigé le problème dès son signalement. Depuis le 18/4, il est possible de sélectionner les zones géographiques des serveurs qu’on souhaite exclure de la gestion du trafic de l’instance : pour IJCLab, comme par défaut, la Chine est exclue. Chaque organisateur de réunion peut voir à trouver le bouton Information du client la zone utilisée pour sa réunion.

Privacy

  • Zoom bombing: le plus médiatisé des problèmes probablement… Il ne résulte pas d’une faiblesse de Zoom mais d’un mauvais usage dans le contexte de réunion annoncée sur les réseaux sociaux, généralement sans mot de passe. Dans le contexte IJCLab, les réunions ne sont pas annoncées sur les réseaux sociaux, par défaut toutes les réunions ont un mot de passe, et les utilisateurs sont encouragés à ne pas mettre les URL des réunions contenant le mot de passe encodé sur des sites Web mais à publier séparément l’URL de connexion (sans mot de passe inclus) et le mot de passe (voir la page sur les bonnes pratiques). De plus, dans sa dernière version du client, Zoom a rendu facile le fait de désactiver le partage d’écran pour les participants, hors autorisation explicite de l’animateur.
  • Envoi de données à Facebook sur iOS : ne touchait théoriquement que les iPhone et iPad qui représente 3% de nos clients. Mais dans les faits ce problème n’a jamais affecté l’utilisation dans l’instance IJCLab puisque le login à travers les réseaux sociaux (dont Facebook) y a été désactivé. Ce problème a aussi été traité dans les 48h de sa révélation par Zoom qui a désactivé le login via Facebook sur iOS.
  • Possible injection de code pour prendre le contrôle de la caméra et de l’enregistrement sur un Mac : comme l’élévation de privilège dans l’installeur, il s’agit d’une possibilité théorique pour un risque très limité, car pour cela il faut soit être l’utilisateur local de la machine (qui a déjà les privilèges pour le faire), soit un utilisateur malicieux qui a déjà pris le contrôle de la machine et a probablement des moyens plus simples de le faire…
  • Attention tracking : nous avons désactivé cette fonctionnalité, sans possibilité pour un animateur de réunion de le réactiver, dès le premier jour. Elle est maintenant totalement désactivé par Zoom (pour information, Zoom n’a pas inventé cette fonctionnalité mais l’a copié de CISCO/Webex à la demande des personnes utiisant Zoom pour des activités d’enseignement).
  • Absence d’encryptage de bout en bout : sur ce point le seul reproche fait à Zoom est d’avoir laissé entendre qu’il faisait mieux que les autres alors qu’il ne fait que la même chose (par exemple Jitsi, le logiciel open-source vidéoconférence fait exactement la même chose)… Il n’y a pas de problème particulier : en particulier si on utilise des clients Zoom pour participer à la réunion, ce qui est le cas de 100% des utilisateurs IJCLab, il y a bien encryptage de bout en bout. Le problème ne concerne que les participations par téléphone (ça semble évident) et les participations depuis une salle H323 où il y a désencryptage/réencryptage en bordure du Zoom cloud.
  • Enregistrement de réunion disponible sur Amazon : Zoom n’y est pour rien. Un animateur de réunion peut enregistrer une réunion (Zoom a des fonctionnalités pour s’assurer que tous les participants ont donné leur consentement ou ont quitté la réunion) et on doit se fier à sa responsabilité pour ne pas rendre cet enregistrement disponible sur un site inapproprié. Zoom a récemment ajouté la possibilité de protéger par un mot de passe les enregistrements et de définir un enregistrement dans le cloud comme non partageable, ainsi qu’une durée de conservation maximum.
  • Faiblesse de l’algorithme d’encryptage : un rapport de Citizen Lab laisse entendre que Zoom utiliserait un cryptage AES 128-bit et non pas 256. Même si Zoom (voir webinaire le 8/4) utilisait bien un encodage 256-bit (128-bit n’étant utilisé que pour la connexion des salles H323), il a reconnu utiliser une variante faible de cet algorithme (ECB) . Zoom a depuis commencé à déployer la possibilité d’utiliser la version mainstream (GCM) de l’algorithme AES-256 (le plus robuste actuellement) qui sera le seul disponible à partir du 30/5 (cela suppose la mise à jour du client en v5, disponible dès maintenant). Zoom  a pris 2 autres engagements importants sur ce point : la possibilité pour un client dans les mois qui viennent d’exécuter lui-même le service de génération de clé plutôt que d’utiliser le service interne de Zoom et surtout la release en open-source du code de ce générateur de telle sorte qu’il puisse être inspecté par tous les experts sécurité de la planète.