Réponse à MR Charles Blanc chef de projet sécurité numériques Grades Pays de la Loire
Ce matin je me permet de rétablir quelques précisions au sujet de votre publication concernant l’adresse IP publique des client teams (Il est possible de géolocaliser n’importe quel utilisateur Teams (et plus encore…) : quels sont les risques et comment se protéger ? (apssis.com))
Bonjour
J’ai bien lu votre article et je me permet d’apporter quelques nuances à vos affirmations.
Localisation par l’adresse IP Publique
Les fonctions Stun et Turn effectivement obligent via la publication des adresses IP (IP candidate) de publier l’adresse ip publique des participants. Vous avez parfaitement raison sur ce point. Seulement votre article laisse pensez que « n’importe quelle personne qui émet un appel Teams peut connaitre l’adresse IP de son correspondant même si il ne décroche pas ».
Tout d’abord pour connaitre l’adresse IP publique du correspondant il faut capturer le trafic et analyser les journaux afin de retrouver le dialogue établi afin d’identifier l’adresse IP publique. Je doute que cela soit à la portée de « n’importe quelle personne ».
Mais admettons que notre utilisateur « de base » récupère cette adresse IP publique via l’interception du trafic. L’adresse IP publique dans la majorité des cas correspond à une adresse IP publique natée d’un routeur Interne, ce qui est bien différent de l’adresse IP du poste de travail.
Connaitre l’adresse IP natée d’une sortie internet est assez simple à découvrir il n’y a pas besoin de client Teams pour cela.
Bien sûr il faut imaginer…..
Ce qui me gêne également dans votre article c’est l’emploi du terme « il est possible d’imaginer » et de l’emploi du conditionnel « Un attaquant pourrait » ou encore « Si l’attaquant découvrait une vulnérabilité dans le client Teams ». En théorie on peut imaginer plein de scénario, mais encore une fois connaitre l’adresse IP natée d’un client Teams c’est une chose, et pouvoir à travers ce biais lancer une attaque depuis l’extérieur vers l’adresse IP natée d’un client vers une supposée faille du client teams , en traversant le pare-feu en est une autre.
Quelques approximations
Dans votre publication j’ai noté également plusieurs approximations comme celles-ci
« Il est donc possible pour n’importe qui de géolocaliser plus ou moins précisément ». Connaitre l’adresse IP natée publique d’un ordinateur ne permet pas de connaitre précisément sa localisation tout le monde le sait. Tout réside donc dans « le plus ou moins précisément. ». Personnellement mon adresse IP publique me localise à plus de 800 km de là ou je suis actuellement.
« 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. »
Connaitre le fournisseur d’accès internet d’un personne n’est pas très compliqué à trouver nous n’avons pas besoin de Microsoft Teams pour cela 😉. On trouve beaucoup de choses dans les entêtes SMTP des messageries.
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à ?
Alors non ce n’est pas tout à fait exact. Prenons l’exemple de deux personnes qui sont connectée l’une au réseau Wifi du Mac Donald de Paris et l’autre au Mac Donald de Marseille. Toutes les deux sont connectées sur un réseau Interne du style 192.168.X.X. Pensez-vous vraiment que ses deux machines vont établir une connexion point à point ?. J’en doute. Le Média relay sera une machine hébergée chez Microsoft dans tous les cas. Pas de points à points dans ce cas-là.
Le point à point est possible si les deux machines peuvent communiquer entre elles. Ce n’est pas le cas avec les accès externes vers l’interne et encore plus rare d’externe vers externe.
Tout cela semble donc plus relever de l’improbable que d’une réalité.
La solution que vous proposez n’est pas appropriée
L’usage d’un VPN dégrade très fortement la qualité des flux audio-Video. Pour avoir réalisé plusieurs projets internationaux Teams, je peux vous garantir que cela n’est pas la bonne solution et ce pour plusieurs raisons que je ne vais pas détailler ici.
Le blocage des port UDP est également un mauvaise solution car elle aussi dégrade fortement la qualité audio et vidéo. Microsoft recommande à juste titre l’usage des ports UDP (3478-3481) pour permettre une qualité audio et vidéo optimale.
La question de la localisation
Le problème que vous soulevez à juste titre se focalise sur le géolocalisation des utilisateurs. Celle-ci doit être portée à la connaissance de ses derniers par tous les moyens de communication que l’entreprise dispose . Renoncer à géolocaliser les utilisateurs c’est,
- S’interdire de bannir des connexions vers Azure provenant de pays comme la Chine, la Corée du nord, voir l’Iran (Règles d’accès conditionnels)
- s’empêcher de contrôler les voyages dit impossibles
- Ne plus être capable de percevoir des connexions depuis des réseaux identifiés par Microsoft comme étant dangereux.
Observer les connexions de utilisateurs ainsi que le comportement de leurs connexions voir de leur traffic applicatifs vers le tenant de l’entreprise est beaucoup plus utile que de vouloir cacher à tout prix leurs adresses IP nattées. Mais là ou je vous rejoint, c’est qu’il faut porter à la connaissance des utilisateurs le fait qu’ils sont géolocalisés.
Cordialement
Laurent TERUIN MVP
Travailler ensemble 