Il est possible de géolocaliser n’importe quel utilisateur Teams (et plus encore...) : quels sont les risques et comment se protéger ?
Depuis la crise sanitaire ayant débuté en 2020, l’application Teams de Microsoft est totalement rentrée dans les mœurs. Échanges avec les proches pendant les périodes de confinement, démocratisation du télétravail, multiplication des réunions en distanciel, les cas d’usages ne manquent pas. L’utilisation de Teams dans le cadre de téléconsultations a même été « tolérée » en France au début de la pandémie. Même si Microsoft dispose d’une certification HDS, lui permettant de proposer à ses clients français du secteur de la santé, un service d’hébergement de données de santé, le service Teams ne rentre pas dans cette case.
Par Charles BLANC - ROLIN - Chef de projet sécurité numérique - GRADES Pays de la Loire et Vice-Président de l'APSSIS & Maître Omar YAHIA - Avocat et Vice-Président de l'APSSIS
Charles BLANC-ROLIN : Maître, pouvez-vous nous rappeler dans quel cadre réglementaire cette «autorisation» a été donnée et si elle est toujours d’actualité aujourd’hui ?
Omar YAHIA : On ne peut pas vraiment parler d’autorisation. Certes, par application des dispositions des articles R. 1111-9 et suivants du code de la santé publique, Microsoft a obtenu la certification HDS en novembre 2018 pour ses quatre centres d'hébergement en France et pour l'ensemble de ses services "cloud" disponibles sur Azure*, Office 365* et Dynamics 365*.
Cela étant, de l’eau a coulé sous les ponts depuis, et dans le prolongement de l'arrêt du 16 juillet 2020 dit « Schrems II » de la Cour de justice de l'Union européenne et de la position des autorités de contrôle des États membres, la CNIL a par exemple vivement déconseillé aux établissements d'enseignement supérieur l’utilisation de l’application Teams.
Car en l'absence de mesures supplémentaires susceptibles d'assurer un niveau de protection adéquat, l’autorité de régulation recommande de recourir à des suites collaboratives proposées par des prestataires exclusivement soumis au droit européen qui hébergent les données au sein de l'Union européenne et ne les transfèrent pas vers les États-Unis, ce qui exclut clairement l’application Teams.
C.B-R. : Même si Teams offre aujourd’hui de nombreuses fonctionnalités, celle qui fait son succès, c’est son système de visioconférence ou d’appel vidéo en ligne. Si à première vue, le fonctionnement semble identique, on observe rapidement quelques nuances entre l’organisation d’une réunion et l’émission d’un appel :
- Il est possible d’organiser une visioconférence avec plusieurs personnes, un appel ne peut se faire qu’entre deux utilisateurs.
- Il est possible d’inviter un utilisateur qui ne dispose pas d’un compte Teams à une réunion sans qu’il n’ait besoin d’en créer un, pour passer un appel, les deux utilisateurs doivent disposer d’un compte Microsoft.
- Les participants à une réunion Teams ne sont pas obligés de disposer de l’application, l’utilisation d’un navigateur Web implémentant le protocole WebRTC suffit parfaitement pour rejoindre une visioconférence organisée par un utilisateur Teams, pour effectuer un appel, les deux correspondants doivent disposer de l’application, peut importe le système d’exploitation utilisé. Teams est disponible pour les systèmes d’exploitation Windows, macOS, Linux, Android et iOS.
Sur le plan technique, les protocoles utilisés pour permettre d’établir la connexion entre les machines des utilisateurs avant de pouvoir lancer les flux audio et vidéo, sont, dans les deux cas, les protocoles STUN et TURN. Ces protocoles permettent à des machines ne disposant pas elles-mêmes d’une adresse IP publique (adresse translatée via routeur / pare-feu) d’entrer en relation.
Lorsqu’un utilisateur rejoint une réunion Teams, c’est un serveur STUN de Microsoft qui est contacté, sur le port 3478/UDP par défaut :
Les machines dialoguent ensuite à l’aide d’un serveur TURN qui relaye les paquets émis par une machine, aux autres machines connectées à la réunion.
Voici donc un schéma très simplifié des échanges lors d’une visioconférence Teams entre deux machines :
Lorsque la fonction « appel » est utilisée, la connexion STUN n’est pas établie avec un serveur Microsoft, mais directement en « pire tout pire » (comprenez peer to peer ou paire à paire en français) avec la machine du correspondant sur des ports aléatoires.
Cela permet donc à toute personne qui émet un appel Teams de connaître l’adresse IP publique de son correspondant, même si celui-ci ne décroche pas !
À l’inverse, la réception d’un appel, même sans décrocher là encore, permet aussi de connaître l’adresse IP publique de l’appelant.
Lorsqu’un client Teams pour Linux est utilisé, le fonctionnement diffère légèrement, une première connexion STUN est établie avec un serveur Microsoft, c’est uniquement lorsque le client Teams pour Linux décroche que la connexion STUN se fait entre les deux clients Teams et qu’il est possible de voir apparaître l’adresse IP publique du correspondant.
Lorsque le correspondant contacté dispose de plusieurs appareils connectés à son compte Teams, dans cet exemple, un ordinateur Windows et un smartphone Android, la simple tentative d’appel va permettre de découvrir les adresses IP publiques de sortie Internet pour ces deux appareils.
À partir de ces informations, il est donc possible d’imaginer plusieurs scénarios d’exploitation de cette « fonctionnalité » :
- Un attaquant pourrait facilement connaître l’adresse IP publique utilisée en sortie par un utilisateur, ce qui pourrait lui donner une plage d’adresses IP à scanner pour effectuer une reconnaissance et tenter de découvrir des vulnérabilités à exploiter dans le système d’information de sa victime. Il pourrait également mener une opération de déni de service sur la connexion Internet du SI victime.
- Un attaquant pourrait également connaître le fournisseur d’accès Internet de sa victime, ainsi que son opérateur mobile, des informations intéressantes pour réaliser une attaque ciblée, en usurpant l’identité d’un de ses fournisseurs.
- Si l’attaquant découvrait une vulnérabilité dans le client Teams, puisque les machines se connectent en « pire tout pire » lors d’un appel, il pourrait également s’attaquer à tous les terminaux de tous les utilisateurs de Teams ! Elle pourrait faire très mal cette vulnérabilité ! Et qui nous dit qu’elle n’existe pas déjà ?
Mais aussi...
Plus « simplement », il est donc possible pour n’importe qui de géolocaliser plus ou moins précisément un utilisateur de Teams à partir de son adresse IP publique. Qui dit adresse IP publique et géolocalisation associées à une personne dit données à caractère personnel et risque de non conformité RGPD…
C.B-R. : Maître, si je suis employeur et que je n’ai pas protégé mes collaborateurs contre ce risque, ma responsabilité peut-elle être engagée ?
O.Y. : En sa qualité de responsable de traitement, l’employeur doit mettre en place des mesures techniques et organisationnelles pour garantir la sécurité et la confidentialité des données personnelles de ses salariés.
Le respect des principes de finalité et de proportionnalité du traitement doit gouverner le recours, par les employeurs, à des procédés de géolocalisation. Ainsi, le Conseil d'État rappelle, aux visas de l'ancien article 6 de la loi de 1978 et de l'article L. 1121-1 du code du travail, que « l'utilisation par un employeur d'un systèmes de géolocalisation pour assurer le contrôle de la durée du travail de ses salariés n'est licite que lorsque ce contrôle ne peut pas être fait par un autre moyen, fût-il moins efficace que la géolocalisation ». En dehors de cette hypothèse, « la collecte et le traitement de telles données à des fins de contrôle du temps de travail doivent être regardés comme excessifs au sens du 3º de l'article 6 de la loi du 6 janvier 1978 » (CE 15 déc. 2015, no 403776, Rec. CE).
C.B-R. : Je suis employeur, mais je n’avais pas connaissance (mon RSSI et mon DPO non plus) de ce mécanisme de fonctionnement et des risques associés car Microsoft n’a pas explicité ce fonctionnement. Ce n’est pas ma faute ! C’est Microsoft ! Puis-je être inquiété malgré tout ?
O.Y. : Assurément oui, pour la simple et bonne raison que c’est le responsable de traitement qui détermine les finalités et les moyens du traitement des données personnelles. Il est chargé de veiller à ce que le traitement des données soit effectué conformément aux principes du RGPD, tels que la licéité, la transparence, la limitation des finalités, la minimisation des données, l'exactitude, la limitation de conservation, l’intégrité et la confidentialité.
C.B-R. : Je suis DSI et j’ai découvert qu’il m’était possible de géolocaliser mes collaborateurs lorsqu’ils sont en télétravail, du coup, lorsque j’ai un doute, je lance un appel et je récupère l’adresse IP de mon collaborateur pour savoir s’il se trouve bien chez lui. Qu’est-ce que je risque ?
O.Y. : D’abord, si l’entité est correctement organisée, elle doit être dotée d’un règlement intérieur et d’une charte d’utilisation des ressources informatiques auxquels tous les salariés, quelle que soit leur fonction, sont censés avoir adhérés. Leur inobservation expose leur auteur à un risque de sanction disciplinaires.
Ensuite, il s’expose à un risque de plainte de la part des salariés concernés si jamais cette information parvenait à leur oreille. Il pourrait s’agir - en fonction des situations rencontrées - d’une plainte civile visant à obtenir des dommages intérêts, d’une plainte pénale, d’une dénonciation auprès de la CNIL.
Enfin, l’employeur lui-même n’est pas à l’abri de poursuites s’il est avéré qu’il avait connaissance de ces agissements et qu’il a sciemment laissé faire.
Comment se protéger ?
C.B-R. : Pour les comptes professionnels, il est possible de bloquer sur son « tenant » Microsoft la possibilité d’émettre et de recevoir des appels en dehors de sa structure, ce qui va limiter la possibilité pour quelqu’un d’externe de découvrir l’adresse IP publique de mes collaborateurs. En revanche, les comptes rattachés à mon « tenant » Microsoft en auront toujours la possibilité. Un collaborateur malintentionné ou un compte piraté pourront toujours permettre d’exploiter cette « fonctionnalité ».
Si elle n’empêcherait pas l’exploitation d’une potentielle vulnérabilité, l’utilisation d’un VPN peut permettre de masquer son adresse IP publique réelle.
La solution la plus efficace reste l’utilisation d’un pare-feu matériel ou logiciel pour empêcher au client Teams d’établir une connexion STUN avec un autre client. Le blocage des ports aléatoires UDP en sortie par exemple, permettra de bloquer l’utilisation du protocole STUN, et tous les flux audio et vidéo seront encapsulés dans un flux TLS avec les serveurs de Microsoft uniquement.
Afin de détecter si une machine de votre réseau n’est pas conforme à votre configuration et si celle-ci établit des connexions STUN directes avec d’autres clients Teams, j’ai ajouté des règles de détection pour Suricata au projet Paw Patrules1.