Des chercheurs en sécurité signalent qu'en raison d'un problème de conception dans la fonction Microsoft Exchange Autodiscover, Outlook et d'autres applications clientes Exchange tierces peuvent laisser échapper des informations d'identification de domaine Windows en clair vers des serveurs externes. Le risque est nettement plus élevé pour les appareils utilisés en dehors des réseaux d'entreprise, un scénario courant pendant la pandémie. Le protocole Autodiscover de Microsoft pour Exchange permet aux applications clientes de configurer automatiquement leur connexion à Exchange.

Pour cela, elles s'appuient sur un fichier de configuration distant hébergé sur ce qui est censé être un domaine d'entreprise. Cependant, en raison d'un problème de conception déjà mis en évidence dans le passé, le protocole peut finir par rechercher la configuration sur des domaines externes qui sont ou peuvent être enregistrés par n'importe qui. Au mois d’août, des chercheurs de l’entreprise de sécurité Guardicore ont enregistré certains de ces domaines externes et, en l’espace d'une semaine environ, ils ont réussi à collecter 96 671 identifiants d'utilisateurs uniques provenant d’entreprises du monde entier et envoyées automatiquement par des applications clientes à leur serveur Web.

Des domaines enregistrés depuis plusieurs années

« Le service Exchange Autodiscover permet à votre application cliente de se configurer elle-même facilement avec un minimum de saisie de l'utilisateur », indique la documentation de Microsoft. « La plupart des utilisateurs connaissent leur adresse électronique et leur mot de passe, et avec ces deux informations, vous pouvez récupérer tous les autres détails dont vous avez besoin pour être opérationnel », inique encore la documentation. Pour les clients Exchange Web Services (EWS), Autodiscover sert généralement à trouver l'URL du point de terminaison EWS, mais Autodiscover peut également fournir des informations pour configurer les clients qui utilisent d'autres protocoles. Autodiscover fonctionne pour les applications client qui se trouvent à l'intérieur ou à l'extérieur des pare-feux et fonctionnera dans une topologie de forêt ressource Exchange (appelée aussi forêt Exchange dédiée) et inter-forêts Exchange ».

Le protocole Autodiscover va tenter de trouver l'URL de configuration par étapes. Tout d'abord, il cherche dans les objets SCP (Service Connection Point) des services de domaine Active Directory (AD DS). Si cela n'est pas possible parce que le client n'a pas accès à AD ou ne peut pas y accéder, le protocole construit des candidats URL Autodiscover sur la base du domaine de l'adresse électronique saisie par l'utilisateur. Pour user@example.com, où exemple.com est le nom de domaine de l'entreprise, le service essaiera d'atteindre :

- https://Autodiscover.example.com/Autodiscover/Autodiscover.xml

- http://Autodiscover.example.com/Autodiscover/Autodiscover.xml

- https://example.com/Autodiscover/Autodiscover.xml

- http://example.com/Autodiscover/Autodiscover.xml

Jusqu'à présent, tout semble assez sûr si l'on considère que exemple.com est le nom de domaine de l'entreprise. Mais s'il n'y a pas de réponse de l'un ou l'autre, la routine agressive de recherche d'URL du protocole essayera encore de construire des candidats URL et peut finir par essayer Autodiscover + le Top Level Domain (TLD) + le chemin : Autodiscover.com pour l'exemple ci-dessus ou Autodiscover.com si l'email de l'utilisateur est user@something.com et ainsi de suite. Le problème, c’est qu'il s'agit de noms de domaine publics que quelqu'un d'autre possède.

« Guardicore a enregistré certains de ces domaines et certains ont été enregistrés par d'autres parties depuis plusieurs années », a déclaré Amit Serper, VP de la recherche en sécurité chez Guardicore. Cette recherche a probablement été entreprise après la publication, en 2017, d’un document de recherche par des chercheurs de Shape Security dans lequel ils ont mis en évidence le même problème de collision de domaines Autodiscover alors qu’ils enquêtaient sur le client de messagerie de Samsung pour Android et l'application Mail iOS d'Apple. « Le problème est lié à la fois à la conception du protocole initial par Microsoft, mais aussi à la façon dont les tiers le mettent en œuvre », a déclaré Amit Serper. « C’est donc un problème de conception et d'implémentation », a-t-il ajouté. Il a aussi déclaré que le serveur web de Guardicore ne recevait pas seulement des demandes de Microsoft Outlook, mais aussi des applications tierces qui s'interfacent avec Exchange et qui ne sont pas des clients de messagerie. Guardicore respecte toujours son engagement de divulgation responsable avec les développeurs de certaines de ces applications et a refusé de les nommer jusqu'à ce qu'ils aient la possibilité de corriger leurs implémentations.

Identifiants en clair et attaques par rétrogradation

Un autre aspect du problème, c’est qu'un grand nombre des requêtes observées par Guardicore comprenaient des identifiants en texte clair codés en base64 sans que le serveur ne demande d’authentification. « Le problème intéressant posé par une grande partie des requêtes que nous avons reçues, c’est que, côté client, rien n’est fait pour vérifier si la ressource est disponible, ou même si elle existe sur le serveur, avant l’envoi d’une requête authentifiée », ont déclaré les chercheurs. « Habituellement, l’implementation de ce genre de scénario serait de vérifier d'abord si la ressource que le client demande est valide, car elle pourrait être inexistante (ce qui déclencherait une erreur HTTP 404) ou être protégée par un mot de passe (ce qui déclencherait un code d'erreur HTTP 401) ».

Microsoft Outlook essaye parfois de s'authentifier à l'aide d'un jeton au lieu d'un nom d'utilisateur et d'un mot de passe, mais le serveur malveillant peut effectuer une attaque dite par rétrogradation ou par repli où il indique au client que les jetons ne sont pas acceptés. Le client est alors invité à s'authentifier et, si le serveur ne dispose pas d'un certificat TLS fiable, un avertissement est généré. Cependant, un attaquant peut facilement corriger cet avertissement en obtenant un certificat gratuit pour le domaine qu'il possède auprès de Let's Encrypt. L'utilisation de l'authentification HTTP de base avec des identifiants en clair pose un grave problème de sécurité si l'attaquant peut renifler le trafic sur le même réseau que l'utilisateur ou s'il peut lancer une attaque par empoisonnement du cache DNS.

Les identifiants collectés par les chercheurs provenaient de différentes versions d'Outlook, mais quand ils ont essayé de reproduire ce comportement en laboratoire, ils n'ont pas toujours réussi sans l’aide de l'attaque par rétrogradation. « Je suppose que cela correspond à une sorte de configuration [sur ces systèmes] », a déclaré Amit Serper. « Par exemple, l’utilisateur travaille depuis son bureau avec son ordinateur portable. Il est connecté au réseau de l'entreprise et à accès à tous ces serveurs. Ensuite, il emporte son ordinateur portable à la maison pour continuer à travailler. Mais il n’est pas connecté au VPN ou pour une raison quelconque, ces serveurs ne sont pas accessibles depuis son domicile. Alors, cette tâche s'exécute simplement en arrière-plan, essaye de se connecter au serveur et finit par divulguer des mots de passe », a-t-il expliqué.

Mesures d'atténuation

Pour protéger leurs utilisateurs, en particulier les employés nomades, les entreprises doivent déployer des règles de pare-feu sur les terminaux qui bloquent les requêtes vers tous les domaines Autodiscover.TLD. Guardicore a créé une liste de ces domaines Autodiscover à risque qui peut être ajoutée au fichier hosts d'un ordinateur, ce qui empêchera ces domaines de se résoudre via le DNS. En outre, lors du déploiement d'Exchange, les administrateurs doivent s'assurer que l'authentification de base HTTP est désactivée afin que les identifiants en clair ne soient pas envoyés sur le réseau. Enfin, les développeurs d'applications qui mettent en œuvre le protocole Exchange Autodiscover doivent s'assurer que le protocole n'échoue pas vers le haut, c’est-à-dire se perpétuer malgré les échecs, et ne construit pas d'URL candidates sur les domaines Autodiscover.TLD, indiquent encore les chercheurs. Microsoft n'a pas répondu immédiatement à une demande de commentaire.