jeudi, 28 mars 2024

La fonctionnalité de découverte automatique d’Exchange peut entraîner une fuite des informations d’identification d’Outlook

Crédit : Temps de rêve

Les chercheurs en sécurité avertissent qu’un problème de conception dans le fonctionnement de la fonctionnalité de découverte automatique de Microsoft Exchange peut entraîner la fuite d’informations d’identification de domaine Windows en texte brut 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.

L’objectif du protocole de découverte automatique de Microsoft pour Exchange est d’aider les applications clientes à configurer automatiquement leur connexion à Exchange. Pour ce faire, ils 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 qui a également été 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.

Des chercheurs de la société de sécurité Guardicore en ont enregistré certains domaines externes et, au cours d’environ une semaine en août, a réussi à collecter 96 671 identifiants d’utilisateurs uniques d’organisations du monde entier qui ont été envoyés automatiquement par les applications clientes à leur serveur Web.

Qu’est-ce qui cause le problème ?

« Le service Exchange Autodiscover offre à votre application cliente un moyen simple de se configurer elle-même avec un minimum d’interventions de l’utilisateur, » la documentation de Microsoft dit. « La plupart des utilisateurs connaissent leur adresse e-mail et leur mot de passe, et avec ces deux informations, vous pouvez récupérer toutes les autres informations dont vous avez besoin pour être opérationnel.

« Pour les clients des services Web Exchange (EWS), la découverte automatique est généralement utilisée pour rechercher l’URL du point de terminaison EWS, mais la découverte automatique peut également fournir des informations pour configurer les clients qui utilisent d’autres protocoles. La découverte automatique fonctionne pour les applications clientes situées à l’intérieur ou à l’extérieur des pare-feu et fonctionnera dans des scénarios de forêt de ressources et de forêts multiples. »

Le protocole de découverte automatique tentera de trouver l’URL de configuration par étapes. Tout d’abord, il recherchera dans les objets de point de connexion de service (SCP) dans les services de domaine Active Directory (AD DS).

Si ce n’est pas disponible parce que le client n’a pas accès à AD ou ne peut pas y accéder, le protocole construira des URL candidates de découverte automatique en fonction du domaine de l’adresse e-mail saisie par l’utilisateur. Pour user@example.com, où example.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 example.com est le nom de domaine de l’entreprise.

Mais s’il n’y a aucune réponse de l’un ou l’autre, la routine de recherche d’URL agressive du protocole continuera à essayer de construire des URL candidates et peut finir par essayer Autodiscover + le TLD + le chemin : Autodiscover.com pour l’exemple ci-dessus ou Autodiscover.co .uk si l’e-mail de l’utilisateur est user@something.co.uk et ainsi de suite. Le problème est que ce sont des noms de domaine public 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, vice-président de la recherche en sécurité chez Guardicore, au CSO. C’était probablement après un document de recherche de 2017 par des chercheurs de Shape Security qui a mis en évidence le même problème de collision de domaine Autodiscover lors de l’enquête Le client de messagerie de Samsung pour Android et l’application de messagerie iOS d’Apple.

« C’est un problème à la fois avec la conception de la façon dont Microsoft a initialement mis en œuvre ce [protocole] et également un problème dans la façon dont les tiers le mettent en œuvre », a déclaré Serper. « C’est un double problème : il s’agit à la fois d’un problème de conception et d’un problème de mise en œuvre.

Serper a déclaré que le serveur Web de Guardicore ne recevait pas seulement des demandes de Microsoft Outlook, mais également des applications tierces qui s’interfacent avec Exchange et ne sont pas des clients de messagerie. Guardicore est toujours engagé dans le processus de divulgation responsable avec les développeurs de certaines de ces applications et a refusé de les nommer jusqu’à ce qu’ils aient eu la possibilité de corriger leurs implémentations.

Identifiants en texte brut et attaques par rétrogradation

Un autre aspect est que la plupart des demandes observées par Guardicore incluaient des informations d’identification en texte brut encodées en base64 sans même que le serveur ne demande l’authentification.

« Le problème intéressant avec une grande partie des demandes que nous avons reçues était qu’il n’y avait aucune tentative du côté du client pour vérifier si la ressource est disponible, ou même existe sur le serveur, avant d’envoyer une demande authentifiée, » le les chercheurs ont dit.

« Habituellement, la façon de mettre en œuvre un tel scénario serait de vérifier d’abord si la ressource demandée par le client est valide, car elle peut être inexistante (ce qui déclenchera une erreur HTTP 404) ou il peut s’agir d’un mot de passe protected (ce qui déclenchera un code d’erreur HTTP 401). »

Microsoft Outlook tente parfois de s’authentifier avec un jeton au lieu d’un nom d’utilisateur et d’un mot de passe, mais le serveur malveillant peut effectuer une attaque de rétrogradation en indiquant au client que les jetons ne sont pas acceptés.

Cela forcera une invite d’authentification sur le client et, si le serveur n’a pas de certificat TLS de confiance, il générera un avertissement. Cependant, l’avertissement peut être facilement corrigé par un attaquant 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 informations d’identification en clair est un problème de sécurité sérieux 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 DNS.

Les chercheurs ont vu des informations d’identification provenant de différentes versions d’Outlook, mais lorsqu’ils ont essayé de reproduire le comportement en laboratoire, ils n’ont pas toujours réussi sans recourir à l’attaque de rétrogradation.

« Je suppose que c’est une sorte de configuration [sur ces systèmes], a déclaré Serper au CSO. « Disons que vous travaillez depuis votre bureau avec votre ordinateur portable et que vous êtes dans le réseau de l’entreprise et que tous ces serveurs vous sont accessibles, puis vous ramenez votre ordinateur portable à la maison parce que vous travaillez à domicile.

« Alors, vous ramenez votre ordinateur portable à la maison et vous n’êtes pas connecté au VPN ou, pour une raison quelconque, ces serveurs ne sont pas accessibles depuis l’endroit où vous vous trouvez, puis cette tâche s’exécute simplement en arrière-plan, en essayant de se connecter au serveur et finissant par des fuites de mots de passe. »

Atténuation

Pour protéger leurs utilisateurs, en particulier les utilisateurs itinérants, les entreprises doivent déployer des règles de pare-feu sur les points de terminaison qui bloquent les requêtes vers tous les domaines Autodiscover.TLD. Guardicore a créé une liste de ces domaines de découverte automatique à risque qui peut être ajouté au fichier hosts d’un ordinateur, ce qui empêchera la résolution de ces domaines via 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 informations d’identification en texte brut ne soient pas envoyées sur le réseau.

Enfin, les développeurs d’applications qui implémentent le protocole Exchange Autodiscover doivent s’assurer que le protocole n’échoue pas vers le haut et finissent par construire des URL candidates sur les domaines Autodiscover.TLD, ont déclaré les chercheurs.

Microsoft n’a pas immédiatement répondu à une demande de commentaire.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici