Le chercheur en sécurité Amit Serper de Guardicore a découvert une grave faille dans le protocole de découverte automatique de Microsoft, qui permet la configuration automatique d’un compte de messagerie avec uniquement l’adresse et le mot de passe requis. La faille permet aux attaquants qui achètent des domaines nommés “autodiscover” – par exemple autodiscover.com ou autodiscover.co.uk – d’intercepter les identifiants de compte en texte clair des utilisateurs qui rencontrent des difficultés de réseau (ou dont les administrateurs ont mal configuré le DNS).
Guardicore a acheté plusieurs domaines de ce type et les a exploités comme pièges d’identification de preuve de concept du 16 avril au 25 août de cette année :
Autodiscover.com.brAutodiscover.com.cnAutodiscover.com.coAutodiscover.esAutodiscover.frAutodiscover.inAutodiscover.itAutodiscover.sgAutodiscover.ukAutodiscover.xyzAutodiscover.online
Un serveur Web connecté à ces domaines a reçu des centaines de milliers d’informations d’identification de courrier électronique, dont beaucoup font également office d’informations d’identification de domaine Windows Active Directory, en texte clair. Les informations d’identification sont envoyées par les clients qui demandent l’URL /Autodiscover/autodiscover.xml, avec un en-tête d’authentification HTTP Basic qui inclut déjà les informations d’identification encodées en Base64 de l’utilisateur malheureux.
Trois failles majeures contribuent à la vulnérabilité globale : le comportement “backoff and escalate” du protocole de découverte automatique en cas d’échec de l’authentification, son incapacité à valider les serveurs de découverte automatique avant d’abandonner les informations d’identification de l’utilisateur et sa volonté d’utiliser des mécanismes non sécurisés tels que HTTP Basic en premier lieu .
Le vrai travail du protocole de découverte automatique est la simplification de la configuration du compte – vous pouvez peut-être compter sur un utilisateur normal pour se souvenir de son adresse e-mail et de son mot de passe, mais des décennies d’informatique nous ont appris que leur demander de se souvenir et de saisir correctement des détails comme POP3 ou IMAP4, TLS ou SSL, TCP 465 ou TCP 587, et les adresses des serveurs de messagerie réels sont plusieurs ponts trop loin.
Le protocole de découverte automatique permet aux utilisateurs normaux de configurer leurs propres comptes de messagerie sans aide, en stockant toutes les parties non privées de la configuration du compte sur des serveurs accessibles au public. Lorsque vous configurez un compte Exchange dans Outlook, vous lui fournissez une adresse e-mail et un mot de passe : par exemple, [email protected]avec mot de passe Hunter2.
Armé de l’adresse e-mail de l’utilisateur, la découverte automatique se charge de rechercher des informations de configuration dans un document XML publié. Il essaiera les connexions HTTP et HTTPS aux URL suivantes. (Noter: contosoest un Microsoftisme, représentant un exemple de nom de domaine plutôt qu’un domaine spécifique.)
http(s)://Autodiscover.example.contoso.com/Autodiscover/Autodiscover.xmlhttp(s)://example.contoso.com/Autodiscover/Autodiscover.xml
Jusqu’ici, tout va bien – nous pouvons raisonnablement supposer que toute personne autorisée à placer des ressources dans l’un ou l’autre example.contoso.comou son Autodiscoversous-domaine a reçu une confiance explicite du propriétaire de example.contoso.comlui-même. Malheureusement, si ces tentatives de connexion initiales échouent, la découverte automatique reculera et tentera de trouver des ressources dans un domaine de niveau supérieur.
Dans ce cas, la prochaine étape d’Autodiscover serait de rechercher /Autodiscover/Autodiscover.xmlau contoso.comlui-même, ainsi que Autodiscover.contoso.com. Si cela échoue, la découverte automatique échoue encore une fois vers le haut, cette fois en envoyant des informations d’e-mail et de mot de passe à autodiscover.comlui-même.
Ce serait déjà assez grave si Microsoft possédait autodiscover.com– mais la réalité est bien plus trouble. Ce domaine a été enregistré à l’origine en 2002 et appartient actuellement à une personne ou à une organisation inconnue utilisant le bouclier de confidentialité WHOIS de GoDaddy.
Au cours des quatre mois environ, Guardicore a exécuté son piège d’informations d’identification de test, il a collecté 96 671 ensembles uniques de noms d’utilisateur et de mots de passe de messagerie en texte clair. Ces informations d’identification provenaient d’un large éventail d’organisations – sociétés cotées en bourse, fabricants, banques, compagnies d’électricité, etc.
Les utilisateurs concernés ne voient pas les erreurs HTTPS/TLS dans Outlook-lorsque le protocole de découverte automatique échoue à partir de Autodiscover.contoso.com.brà Autodiscover.com.br, la protection offerte par contosola propriété de son propre certificat SSL disparaît. Celui qui a acheté Autodiscover.com.br-dans ce cas, Guardicore fournit simplement son propre certificat, qui satisfait aux avertissements TLS bien qu’il n’appartienne pas à contosodu tout.
Dans de nombreux cas, Outlook ou un client similaire proposera initialement les informations d’identification de son utilisateur dans un format plus sécurisé, tel que NTLM. Malheureusement, un simple HTTP 401 du serveur Web demandant l’authentification HTTP Basic à sa place est tout ce qui est nécessaire, auquel le client utilisant la découverte automatique se conformera (généralement sans erreur ni avertissement à l’utilisateur) et enverra les informations d’identification en texte brut codé en Base64, entièrement lisible par le serveur web répondant à la requête Autodiscover.
La vraie mauvaise nouvelle ici est que, du point de vue du grand public, ilest aucune stratégie d’atténuation pour ce bogue de découverte automatique. Si l’infrastructure de découverte automatique de votre organisation passe une mauvaise journée, votre client “échouera vers le haut” comme décrit, exposant potentiellement vos informations d’identification. Cette faille n’a pas encore été corrigée – selon le directeur principal de Microsoft, Jeff Jones, Guardicore a divulgué publiquement la faille avant de la signaler à Microsoft.
Si vous êtes un administrateur réseau, vous pouvez atténuer le problème en refusant les requêtes DNS pour les domaines de découverte automatique. Si chaque demande de résolution d’un domaine commençant par « Découverte automatique » est bloquée, le protocole de découverte automatique ne pourra pas divulguer les informations d’identification. Même dans ce cas, vous devez être prudent : vous pourriez être tenté de “bloquer” de telles requêtes en retournant127.0.0.1, mais cela peut permettre à un utilisateur intelligent de découvrir l’adresse e-mail et/ou les informations d’identification Active Directory de quelqu’un d’autre, s’il peut tromper la cible pour qu’elle se connecte au PC de l’utilisateur.
Si vous êtes un développeur d’applications, le correctif est plus simple : n’implémentez pas la partie défectueuse de la spécification de découverte automatique en premier lieu. Si votre application ne tente jamais de s’authentifier auprès d’un domaine “en amont”, elle ne divulguera pas les informations d’identification de vos utilisateurs via la découverte automatique.
Pour plus de détails techniques, nous recommandons vivement le propre article de blog de Guardicore ainsi que la propre documentation de découverte automatique de Microsoft.
Image de la liste par Just_Super via Getty Images