Autodiscover est un protocole utilisé par Microsoft Exchange pour la configuration automatique de clients tels que Microsoft Outlook, et qui présente un défaut de conception entraînant une “Leak” ou “fuite” des requêtes web vers les domaines Autodiscover situés en dehors du domaine de l’utilisateur mais dans le même TLD (c’est-à-dire Autodiscover.com).
Guardicore Labs a acquis plusieurs domaines Autodiscover avec un suffixe TLD et les a configurés pour atteindre un serveur Web contrôlé. Peu après, Guardicore Lab a détecté une fuite massive d’informations d’identification de domaines Windows qui ont atteint le serveur.
Entre le 16 avril 2021 et le 25 août 2021, Guardicore Lab a capturé :
-
- 372 072 identifiants de domaine Windows au total.
96 671 identifiants UNIQUES ayant fui de diverses applications telles que Microsoft Outlook, des clients de messagerie mobiles et d’autres applications se connectant au serveur Exchange de Microsoft. - De plus, si l’attaquant dispose de capacités de contamination du DNS à grande échelle (comme un attaquant national, d’un Etat Nation), il pourrait systématiquement siphonner les mots de passe ayant fait l’objet d’une fuite par le biais d’une campagne de contamination du DNS à grande échelle basée sur ces TLD de découverte automatique.
Guardicore a mis au point une attaque – “The ol’ switcheroo” qui fait passer le schéma d’authentification d’un client d’un schéma sécurisé (OAuth, NTLM) à l’authentification HTTP de base, où les informations d’identification sont envoyées en clair.
- 372 072 identifiants de domaine Windows au total.
Introduction
Dans le cadre des efforts continus de recherche en matière de sécurité déployés par l’équipe de Guardicore Labs, celle-ci a découvert un cas intéressant de fuite d’informations d’identification affectant un grand nombre de personnes et d’organisations dans le monde entier.
Les informations d’identification qui font l’objet de la fuite sont des informations d’identification de domaine Windows valides utilisées pour s’authentifier sur les serveurs Microsoft Exchange.
La source de ces fuites est constituée de deux problèmes :
- La conception du protocole de découverte automatique de Microsoft (et de l’algorithme de « back-off », en particulier).
- Mauvaise implémentation de ce protocole dans certaines applications.
Le protocole Autodiscover de Microsoft a été conçu pour faciliter la configuration des clients Exchange tels que Microsoft Outlook.
L’objectif du protocole est de permettre à l’utilisateur final de configurer complètement son client Outlook en fournissant uniquement son nom d’utilisateur et son mot de passe et de laisser le reste de la configuration au protocole Autodiscover de Microsoft Exchange.
Il est important de comprendre que, puisque Microsoft Exchange fait partie de la “suite de solutions de domaine Microsoft”, les informations d’identification nécessaires pour se connecter à la boîte de réception d’une personne basée sur Exchange sont dans la plupart des cas, ses informations d’identification de domaine.
Les implications d’une fuite d’informations d’identification de domaine à une telle échelle sont considérables et peuvent mettre les organisations en péril.
En particulier dans le monde actuel sous le feu des attaques de ransomware, le moyen le plus facile pour un attaquant de pénétrer dans une organisation est d’utiliser des informations d’identification légitimes et valides.
Les vulnérabilités divulguées par Shape Security ont été corrigées, pourtant, nous voici en 2021 avec un paysage de menaces nettement plus vaste, traitant exactement le même problème, mais avec davantage d’applications tierces en dehors des clients de messagerie.
Guardicore Lab a lancé des processus de divulgation “responsables” avec certains des fournisseurs concernés.
Ce document explique en détail comment les problèmes de conception du protocole susmentionné provoquent une grave fuite d’informations d’identification qui permet à Guardicore Lab de recevoir des dizaines de milliers d’informations d’identification de domaine Windows valides sans envoyer un seul paquet.
En quoi consiste Autodiscover ?
Le protocole Autodiscover d’Exchange a été conçu pour permettre aux clients de configurer facilement leurs applications client Exchange. Habituellement, afin de configurer un client de messagerie, l’utilisateur doit configurer plusieurs paramètres :
Le nom d’utilisateur et le mot de passe.
Les noms d’hôte/adresses IP des serveurs de messagerie/de change.
Dans certains cas, des paramètres supplémentaires sont nécessaires (paramètres LDAP divers, calendriers WebDAV, etc.).
Le protocole a plusieurs itérations, versions et modes; leur documentation complète peut être trouvée sur le site web de Microsoft, cependant, dans cet article, nous allons simplement traiter et développer le sujet d’une implémentation spécifique d’Autodiscover basée sur le protocole POX XML.
Lorsque l’utilisateur ajoute un nouveau compte Microsoft Exchange à Outlook, il reçoit une invite lui demandant son nom d’utilisateur et son mot de passe :
Configuration automatique du compte Microsoft Outlook
Une fois que l’utilisateur a rempli tous les détails, Outlook essaiera alors d’utiliser la découverte automatique afin de configurer le client.
Cette étape du processus ressemble à ceci :
Processus de configuration automatique du compte Microsoft Outlook
Cependant, pour bien comprendre le fonctionnement d’Autodiscover, nous devons connaître ce qui se passe “en coulisses” :
Le client analyse l’adresse e-mail fournie par l’utilisateur – amit@example.com.
Le client essaie ensuite de construire une URL Autodiscover basée sur l’adresse e-mail avec le format suivant :
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
Si aucune de ces URL ne répond, Autodiscover lance sa procédure de “back-off”.
Ce mécanisme de “back-off” est le “coupable” de cette fuite car il essaie toujours de résoudre la partie Autodiscover du domaine et il essaiera toujours d'”échouer”, en quelque sorte.
Autrement dit, le résultat de la prochaine tentative de construction d’une URL Autodiscover sera : http://Autodiscover.com/Autodiscover/Autodiscover.xml.
Cela signifie que le propriétaire d’Autodiscover.com recevra toutes les demandes qui ne peuvent pas atteindre le domaine original.
Pour plus d’informations sur le fonctionnement d’Autodiscover, veuillez consulter la documentation de Microsoft.
Processus de “back-off” de la découverte automatique
Abus de la fuite
Afin de voir si le scénario de fuite Autodiscover est “viable”, Guardicore Lab a acheté les domaines suivants :
- Autodiscover.com.br – Brésil
- Autodiscover.com.cn – Chine
- Autodiscover.com.co – Colombie
- Autodiscover.es – Espagne
- Autodiscover.fr – France
- Autodiscover.in – Inde
- Autodiscover.it – Italie
- Autodiscover.sg – Singapour
- Autodiscover.uk – Royaume-Uni
- Autodiscover.xyz
- Autodiscover.online
- Autodiscover.cc
- Autodiscover.studio
- autodiscover.capital
- autodiscover.club
- autodiscover.company
- autodiscover.jp
- autodiscover.me
- autodiscover.mx
- autodiscover.ventures
Plus tard, ces domaines ont été attribués à un serveur Web (contrôlé) et ont simplement attendus l’arrivée de demandes Web pour divers points de terminaison de découverte automatique.
À sa grande surprise, Guardicore Lab a commencé à voir des quantités importantes de demandes de points de terminaison de découverte automatique provenant de divers domaines, adresses IP et clients.
La chose la plus étonnante à propos de ces demandes était qu’elles demandaient le chemin relatif de /Autodiscover/Autodiscover.xml avec l’en- tête d’ autorisation déjà renseigné avec les informations d’identification dans l’authentification de base HTTP.
exemple d’une simple requête HTTP GET avec l’en-tête Authorization déjà renseigné avec les informations d’identification
En règle générale, les requêtes Web ne doivent pas être envoyées aveuglément pré-authentifiées, mais plutôt en suivant le processus d’authentification HTTP :
- Un client demande l’accès à une ressource protégée.
- Le serveur Web renvoie une boîte de dialogue qui demande le nom d’utilisateur et le mot de passe (conformément aux méthodes d’authentification prises en charge, dans notre cas, l’authentification de base).
- Le client soumet le nom d’utilisateur et le mot de passe au serveur.
- Le serveur authentifie l’utilisateur et renvoie la ressource demandée.
Processus d’authentification de base HTTP illustré
Comme on peut le voir dans l’extrait suivant, les noms d’hôtes apparaissant dans le journal (supprimés pour des raisons de confidentialité) sont les domaines à partir desquels les clients d’Autodiscover ont essayé de s’authentifier, ainsi que leurs noms d’utilisateur et mots de passe respectés :
|
2021 – 05 – 18 03 : 30 : 45 W3SVC1 instance- 2 10.142.0.4 GET /Autodiscover/Autodiscover.xml – 80 – <adresse IP nettoyée> HTTP/ 1.1 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft +Outlook+16.0.13901;+Pro) – -<domaine de la victime nettoyé> 404 0 2 1383 301 265 <domaine de la victime nettoyé> Basic+<informations d’identification codées en base64 nettoyées>= – – 2021 – 05 – 18 03 : 30 : 52 instance W3SVC1 – |
Agents utilisateurs
Étant donné qu’autodiscover fonctionne sur HTTP/S, la partie agent utilisateur de la requête HTTP est particulièrement intéressante, car elle nous permet de comprendre quels clients atteignent le serveur avec des requêtes pré-authentifiées.
Vous pouvez trouver une liste des agents utilisateurs de Microsoft Outlook/Office que Guardicore Lab a capturés en train d’envoyer des demandes pré-authentifiées ici.
Comme vous pouvez le constater, l’implémentation problématique d’autodiscover existe sur différentes versions d’Outlook, même sur Outlook pour Mac.
Cependant, entre tous ces agents utilisateurs, nous avons remarqué un autre agent intéressant : “microsoft.windowscommunicationsapps” :
Selon la documentation officielle de Microsoft, cet agent utilisateur appartient également à Outlook (“Outlook Mail and Calendar” pour être exact !
Le problème intéressant d’une grande partie des demandes que Guardicore Lab a reçues est qu’il n’y a aucune tentative du côté du client de vérifier si la ressource est disponible, ou même existe sur le serveur, avant d’envoyer une demande authentifiée.
Habituellement, la façon de mettre en œuvre un tel 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 alors protégée par un mot de passe (ce qui déclencherait un code d’erreur HTTP 401), comme le montre le schéma ci-dessus.
Mais après une inspection minutieuse et des tests manuels de divers programmes, Guardicore est arrivé à la conclusion que cet agent utilisateur est également émis par Mail; le client de messagerie intégré à Windows :
De plus, les agents utilisateurs suivants se sont également connectés aux serveurs Guardicore, il s’agit d’agents utilisateurs de clients fonctionnant sous macOS d’Apple.
Nous pensons qu’il s’agit de divers clients de messagerie qui ont implémenté le protocole autodiscover de manière vulnérable :
- AppleExchangeWebServices / 807 + comptesd / 113
- Entreprise/ 6.28.1.8 +CFRéseau/1128.0.1+Darwin/19.6.0
- Entreprise/ 6.28.1.8 +CFRéseau/1220.1+Darwin/20.3.0
- Entreprise/ 6.28.1.8 +CFRéseau/1240.0.4+Darwin/20.5.0
- CFNetworkAgent+(inconnu+version)+CFNetwork/1121.2.2+Darwin/19.3.0
- CFNetworkAgent+(inconnu+version)+CFNetwork/1240.0.4+Darwin/20.6.0
- CFNetworkAgent+(inconnu+version)+CFNetwork/978.0.7+Darwin/18.7.0
- iTunes+(inconnu+version)+CFNetwork/520.51.3
- networkd+(inconnu+version)+CFNetwork/758.5.3+Darwin/15.6.0
- Entreprise/6.28.1.8+CFNetwork/1220.1+Darwin/20.3.0
- Entreprise/6.28.1.8+CFNetwork/1240.0.4+Darwin/20.5.0
En raison de la façon dont macOS implémente divers mécanismes et API de synchronisation de comptes, on ne peut pas savoir exactement quelle application utilisait l’API de découverte automatique, les agents utilisateurs ci-dessus semblent être liés à des composants du système d’exploitation tels que accountd .
Guardicore Lab a également observé des agents utilisateurs appartenant à divers téléphones Samsung, ces agents utilisateurs semblent représenter l’application de lecture de courrier intégrée sur les téléphones Samsung.
- SAMSUNG-GT-I9060/101.40202
- SAMSUNG-GT-I9195L/101.40402
- SAMSUNG-GT-I9508/101.40402
- SAMSUNG-GT-N5100/101.40402
- SAMSUNG-GT-N5110/101.40402
- SAMSUNG-SM-G355M/101.40402
- SAMSUNG-SM-G357M/101.40402
- SAMSUNG-SM-G386F/101.40202
- SAMSUNG-SM-G530M/101.40404
- SAMSUNG-SM-G7102/101.40402
- SAMSUNG-SM-T110/101.40202
- SAMSUNG-SM-T210/101.40402
- SAMSUNG-SM-T211/101.40402
- SAMSUNG-SM-T230/101.40402
- SAMSUNG-SM-T320/101.40402
- SAMSUNG-SM-T331C/101.40402
- SAMSUNG-SM-T531/101.40402
- SAMSUNG-SM-T700/101.40402
La bonne nouvelle est que ces appareils sont très anciens , exécutant de très anciennes versions d’Android et des progiciels sous-jacents de Samsung.
Il est donc probable que la raison pour laquelle Guardicore a vu que ces anciens appareils Samsung, vient du fait que ces vulnérabilités ont été divulguées à Samsung en 2017 par Shape Security après la publication de leur rapport et que Blackhat a parlé des problèmes de “découverte automatique”.
Entre le 16 avril 2021 et le 25 août 2021, Guardicore a capturé un grand nombre d’informations d’identification de cette manière, bien entendu, sans envoyer un seul paquet autre que celui requis pour établir une session HTTP/HTTPS entre son serveur et les divers clients.
Les données suivantes ont été collectées entre le 20 avril 2021 et le 25 août 2021 :
En examinant les domaines de ces informations d’identification divulguées, Guardicore a pu trouver des informations d’identification de diverses entreprises dans plusieurs secteurs verticaux :
Le vieux switcheroo
Illustation de l’ancienne attaque switcheroo
En observant les journaux du serveur HTTP, nous pouvons voir que le client est rétrogradé avec succès après avoir reçu la réponse HTTP 401 du serveur, lui indiquant d’utiliser l’authentification de base HTTP :
Ancienne attaque switcheroo réussie
Remarque : le “Token” de support (vide) est envoyé dans le cadre du processus d’autodécouverte de l’environnement, qui est décrit plus en détail dans la documentation de Microsoft.
Du côté de la victime, cependant, il est difficile de se rendre compte que l’utilisateur subit une attaque quelconque.
Lorsque la victime est redirigée vers le serveur Autodiscover de Guardicore en raison de la fuite, une alerte de sécurité s’affiche :
Alerte de sécurité demandée par Microsoft Outlook
Cet avertissement indique que même si le certificat est valide, il est auto-signé et ne doit pas être approuvé.
Cependant, cela pourrait être facilement évité en déployant un véritable certificat SSL.
Dans le cas de Guardicore, l’équipe a déployé un certificat LetsEncrypt en quelques secondes, ce qui a résolu le problème de l’affichage de l’avertissement SSL.
Installation de certificats SSL LetsEncrypt avec WinAcme
autodiscover.sg est maintenant sécurisé avec un certificat valide
Une fois qu’une session sécurisée a été établie, la victime verra maintenant cette invite d’authentification légitime affichée par Microsoft Outlook :
Boîte de dialogue d’authentification de base affichée dans Outlook à la suite d’une ancienne attaque switcheroo réussie
Il s’agit de la dernière étape de cette attaque; la victime entrera ses informations d’identification dans cette boîte de dialogue, qui à son tour enverra les informations d’identification au serveur Web Guardicore.
Les identifiants apparaissent désormais dans ses logs.
Atténuation
Atténuer le problème des fuites de découverte automatique est important, comme nous l’avons démontré précédemment.
Afin d’atténuer ce problème, deux approches distinctes sont nécessaires :
- Une approche doit être mise en œuvre par le grand public qui utilise des technologies basées sur Exchange telles qu’Outlook ou ActiveSync (le protocole de synchronisation Exchange mobile de Microsoft) et l’autre approche doit être mise en œuvre par les développeurs/fournisseurs de logiciels qui implémentent le protocole Autodiscover dans leurs produits :
- Pour le grand public : assurez-vous que vous bloquez activement la découverte automatique. domaines (tels que Autodiscover.com/Autodiscover.com.cn, etc.) dans votre pare-feu.
La sécurité DNS de Guardicore Centra permet de créer des règles de blocage pour les noms de domaine Autodiscover
- Lors du déploiement/ou de la configuration d’installations Exchange, assurez-vous que la prise en charge de l’authentification de base est désactivée .
L’utilisation de l’authentification de base HTTP revient à envoyer un mot de passe en texte clair sur le réseau. - Une liste textuelle complète de tous les domaines de premier niveau peut être trouvée dans l’url suivante : https://data.iana.org/TLD/tlds-alpha-by-domain.txt
- Guardicore Lab a préparé un fichier txt avec tous les domaines Autodiscover.TLD possibles qui peuvent être ajoutés à votre fichier d’hôtes locaux ou à la configuration de votre pare-feu afin d’atténuer le risque de résolution de ces domaines Autodiscover.
Veuillez consulter notre référentiel github pour plus d’informations : https://github.com/guardicore/labs_campaigns/tree/master/Autodiscover
- Guardicore Lab a préparé un fichier txt avec tous les domaines Autodiscover.TLD possibles qui peuvent être ajoutés à votre fichier d’hôtes locaux ou à la configuration de votre pare-feu afin d’atténuer le risque de résolution de ces domaines Autodiscover.
3. Guardicore pour les éditeurs et développeurs de logiciels :
- Assurez-vous que lorsque vous implémentez le protocole de découverte automatique dans votre produit, vous ne le laissez pas « fail upwards », ce qui signifie que des domaines tels que « Autodiscover ». ne devrait jamais être construit par l’algorithme « back-off ».
Conclusion
Dans ce document, nous avons discuté des implications du défaut de conception de base dans le protocole de découverte automatique (l’algorithme « back-off ») et nous avons démontré que si un attaquant contrôle les domaines de découverte automatique de niveau supérieur (ou si l’attaquant a la capacité de mener une “DNS-poisoning attack” à l’aide de ces domaines), ils peuvent facilement utiliser des informations d’identification de domaine valides à partir de ces demandes de découverte automatique qui “fuient”.
Souvent, les attaquants tentent d’amener les utilisateurs à leur envoyer leurs informations d’identification en appliquant diverses techniques, qu’elles soient techniques ou via l’ingénierie sociale (souvent se faisant passer pour une relation de travail).
Cependant, cet incident nous montre que des mots de passe peuvent être divulgués en dehors du périmètre de l’organisation par un protocole destiné à rationaliser les opérations du service informatique en ce qui concerne la configuration du client de messagerie sans que personne du service informatique ou de sécurité ne le sache, ce qui souligne l’importance d’une bonne segmentation et d’une confiance zéro (Zero Trust).
Guardicore Labs, poursuis continuellement ses efforts pour sécuriser les réseaux, les applications et les protocoles en trouvant, alertant et divulguant ces problèmes.
Source : Guardicore
Pour plus d’informations concernant les solutions GuardiCore
