Imaginez avoir des tentatives illimitées pour deviner le nom d’utilisateur et le mot de passe de quelqu’un sans vous faire prendre. Cela constituerait un scénario idéal pour un acteur de menace furtif laissant les administrateurs de serveur avec peu ou pas de visibilité sur les actions de l’attaquant, sans parler de la possibilité de les bloquer.
Un bogue récemment découvert dans l’implémentation d’Active Directory (AD) de Microsoft Azure permet justement cela : le forçage brutal à un seul facteur des informations d’identification AD d’un utilisateur. Et, ces tentatives ne sont pas connectées au serveur.
En juin de cette année, des chercheurs de Secureworks Counter Threat Unit (CTU) ont découvert une faille dans le protocole utilisé par Azure Active Directory Seamless Single Sign-Onservice.
« Cette faille permet aux acteurs de la menace d’effectuer des attaques par force brute à facteur unique contre Azure Active Directory sans générer d’événements de connexion dans le locataire de l’organisation ciblée », expliquent les chercheurs.
Le même mois, Secureworks a signalé la faille à Microsoft qui a ensuite confirmé que ce comportement existait en juillet, mais a décidé qu’il était “par conception”.
Ce mois-ci, Secureworks alerte ses clients de la faille, selon une communication partagée avec Ars par une source.
Le service Azure AD Seamless SSO connecte automatiquement les utilisateurs à leurs appareils d’entreprise, connectés au réseau de leur lieu de travail. Avec Seamless SSO activé, les utilisateurs n’auront pas à saisir leurs mots de passe, ni même généralement leurs noms d’utilisateur, pour se connecter à Azure AD. « Cette fonctionnalité permet à vos utilisateurs d’accéder facilement à vos applications basées sur le cloud sans avoir besoin de composants supplémentaires sur site », explique Microsoft.
Mais, comme de nombreux services Windows, le service Seamless SSO repose sur le protocole Kerberos pour l’authentification. “Lors de la configuration Seamless SSO, un objet informatique nommé AZUREADSSOACC est créé dans le domaine Active Directory (AD) sur site et reçoit le nom principal de service (SPN) https://autologon.microsoftazuread-sso.com“, expliquent les chercheurs de la CTU. “Ce nom et le hachage du mot de passe duAZUREADSSOACC objet ordinateur sont envoyés à Azure AD.”
Le point de terminaison d’ouverture de session automatique suivant appelé « windowstransport » reçoit des tickets Kerberos. Et, l’authentification unique transparente se produit automatiquement sans aucune interaction de l’utilisateur :
Le workflow d’authentification a été démontré avec l’illustration suivante :
De plus, il y a un usernamemixedpoint final à …/winauth/trust/2005/usernamemixed qui accepte le nom d’utilisateur et le mot de passe pour l’authentification à un seul facteur. Pour authentifier un utilisateur, un fichier XML contenant son nom d’utilisateur et son mot de passe est envoyé à ce usernamemixed point final.
Le workflow d’authentification pour ce point de terminaison est beaucoup plus simple :
Et c’est là que la faille s’insinue. La connexion automatique tente d’authentifier l’utilisateur auprès d’Azure AD en fonction des informations d’identification fournies. Si le nom d’utilisateur et le mot de passe correspondent, l’authentification réussit et le service de connexion automatique répond avec une sortie XML contenant un jeton d’authentification, appelé DesktopSSOToken, qui est envoyé à Azure AD. Si, toutefois, l’authentification échoue, un message d’erreur est généré.
Ce sont ces codes d’erreur, dont certains ne sont pas correctement enregistrés, qui peuvent aider un attaquant à effectuer des attaques par force brute non détectées.
“Les événements d’authentification réussis génèrent des journaux de connexion… Cependant, l’authentification de la connexion automatique [step] à Azure AD n’est pas enregistré. Cette omission permet aux acteurs de la menace d’utiliser les usernamemixed point de terminaison pour les attaques par force brute non détectées », expliquent les chercheurs de la CTU dans leur article.
Les codes d’erreur AADSTS utilisés lors du workflow d’authentification Azure AD sont indiqués ci-dessous :
Les chercheurs de Secureworks déclarent que la plupart des outils de sécurité et des contre-mesures visant à détecter les attaques par force brute ou par pulvérisation de mot de passe reposent sur des journaux d’événements de connexion et recherchent des codes d’erreur spécifiques. C’est pourquoi n’avoir aucune visibilité sur les tentatives de connexion infructueuses est un problème.
“[Our] l’analyse indique que le service de connexion automatique est implémenté avec Azure Active Directory Federation Services (AD FS) », expliquent les chercheurs de la CTU. « La documentation de Microsoft AD FS recommande de désactiver l’accès Internet au windowstransport point final. Cependant, cet accès est requis pour Seamless SSO. Microsoft indique que le usernamemixed le point de terminaison n’est requis que pour les clients Office hérités antérieurs à la mise à jour Office 2013 de mai 2015.”
La faille ne se limite pas aux organisations utilisant Seamless SSO. “Les acteurs menaçants peuvent exploiter la connexion automatique usernamemixed point de terminaison dans n’importe quelle organisation Azure AD ou Microsoft 365, y compris les organisations qui utilisent l’authentification directe (PTA) », expliquent les chercheurs. Bien que les utilisateurs sans mot de passe Azure AD ne soient pas affectés.
Étant donné que le succès d’une attaque par force brute dépend en grande partie de la force du mot de passe, Secureworks a classé la faille comme gravité « moyenne » dans sa rédaction.
Au moment de la rédaction, il n’y a pas de correctifs ou de solutions de contournement connus pour bloquer l’utilisation duusernamemixed point final. Secureworks indique que l’utilisation de l’authentification multifacteur (MFA) et de l’accès conditionnel (CA) n’empêchera pas l’exploitation car ces mécanismes ne se produisent qu’après une authentification réussie.
Ars a contacté Microsoft et Secureworks bien avant la publication. Microsoft n’a pas répondu à notre demande de commentaire. Secureworks a étrangement répondu avec une invitation à un futur événement en ligne mais n’a pas commenté la question.
Comme indiqué ci-dessus, Microsoft semble considérer cela comme un choix de conception plutôt que comme une vulnérabilité. En tant que tel, il reste difficile de savoir si ou quand la faille sera corrigée, et les organisations pourraient rester vulnérables aux attaques furtives par force brute.
Ax Sharma / Ax Sharma est chercheur, ingénieur et journaliste en sécurité.
