Un exploit public de preuve de concept (PoC) a été publié pour la faille de force brute des identifiants Microsoft Azure Active Directory découverte par Secureworks et signalé pour la première fois par Ars. L’exploit permet à quiconque d’effectuer à la fois une énumération de nom d’utilisateur et un forçage brutal de mot de passe sur des serveurs Azure vulnérables. Bien que Microsoft ait initialement qualifié le mécanisme d’ouverture de session automatique de choix de « conception », il semble que la société travaille maintenant sur une solution.
Script PoC publié sur GitHub
Hier, un exploit PoC « pulvérisation de mot de passe » a été publié pour la faille de force brute Azure Active Directory sur GitHub. Le script PowerShell, un peu plus de 100 lignes de code, est fortement basé sur précédent travail par le Dr Nestori Syynimaa, chercheur principal en sécurité chez Secureworks.
POC vient d’éclater pour le spray SSO https://t.co/Ly2AHsR8Mr
– rvrsh3ll (@424f424f) 29 septembre 2021
Selon la Counter Threat Unit (CTU) de Secureworks, l’exploitation de la faille, comme la confirmation des mots de passe des utilisateurs par force brute, est assez facile, comme le démontre le PoC. Cependant, les organisations qui utilisent des politiques d’accès conditionnel et l’authentification multifacteur (MFA) peuvent bénéficier du blocage de l’accès aux services via l’authentification par nom d’utilisateur/mot de passe. « Donc, même lorsque l’acteur menaçant est en mesure d’obtenir [a] mot de passe de l’utilisateur, ils peuvent ne pas être [able to] l’utiliser pour accéder aux données de l’organisation », a déclaré Syynimaa à Ars dans une interview par e-mail.
Que peuvent faire les organisations pour se protéger ?
Bien qu’il ait été rendu public après la divulgation de Secureworks cette semaine, le problème de force brute d’Azure AD semble avoir été connu auparavant par certains chercheurs, dont le chercheur Dirk-jan :
Assez intéressant, j’ai signalé ce problème en décembre 2020 à @msftsecresponse, le dernier que j’ai entendu est qu’il est toujours en développement pour un correctif. Assez étrange que d’autres personnes obtiennent un verdict différent sur le même problème. https://t.co/2EtfEIM5BE
– Dirk-jan (@_dirkjan) 28 septembre 2021
Microsoft a déclaré à Ars que la technique démontrée par Secureworks ne constitue pas une vulnérabilité de sécurité et que des mesures sont déjà en place pour protéger les utilisateurs Azure :
« Nous avons examiné ces affirmations et déterminé que la technique décrite n’implique pas de faille de sécurité et que des protections sont en place pour garantir que les clients restent en sécurité », a déclaré un porte-parole de Microsoft à Ars. Après avoir examiné la rédaction initiale de Secureworks, Microsoft a conclu que les protections contre les attaques par force brute s’appliquent déjà aux points de terminaison décrits, protégeant ainsi les utilisateurs contre de telles attaques.
De plus, selon Microsoft, les jetons émis par le WS-Trust usernamemixed
le point de terminaison ne donne pas accès aux données et doit être présenté à Azure AD pour obtenir les jetons réels. « Toutes ces demandes de jetons d’accès sont alors protégées par Accès conditionnel, Authentification multifacteur Azure AD, Protection d’identité Azure AD et a fait surface dans journaux de connexion, » a conclu Microsoft dans sa déclaration à Ars.
Mais, Secureworks a également partagé des informations supplémentaires qu’il a reçues de Microsoft après avoir publié son une analyse cette semaine, indiquant que Microsoft travaille sur une solution.
« Tout d’abord, l’événement de connexion sera renseigné dans les journaux de connexion Azure AD. Deuxièmement, les organisations auront la possibilité d’activer ou de désactiver le point de terminaison en question. Ceux-ci devraient être disponibles pour les organisations dans les deux prochaines semaines », Syynimaa dit Ars.
Architecte de solutions de sécurité Nathan McNulty déjà signalé avoir vu des événements de connexion réussis apparaître dans les journaux de connexion :
Un travail incroyable de l’équipe Azure Identity !
Ils ont déjà ajouté la journalisation des audits de réussite pour le point de terminaison WS-Trust MEX aux journaux de connexion non interactifs (aucun échec pour le moment)
Get-AzureADAuditSignInLogs ne semble pas s’afficher dans l’API Graph (bonne nouvelle pour les SIEM) 🙂 https://t.co/A130Uh7OeY
– Nathan McNulty (@NathanMcNulty) 29 septembre 2021
Azure AD est également livré avec un « Verrouillage intelligent » fonction conçue pour verrouiller automatiquement les comptes ciblés pendant un certain temps si trop de tentatives de connexion sont détectées.
« Lorsqu’il est verrouillé, le message d’erreur est toujours ‘verrouillé’, peu importe [of the password being correct or not]. En tant que telle, la fonctionnalité semble effectivement bloquer le forçage brutal », a ajouté Syynimaa à Ars. « Cependant, la pulvérisation de mots de passe, où plusieurs comptes sont ciblés avec quelques mots de passe, ne sera probablement pas bloquée par Smart Lockout. »
Le conseil de Syynimaa aux organisations à la recherche d’une solution de contournement contre cette attaque est d’ajuster le nombre d’authentifications ayant échoué avant que Smart Lockout ne démarre et ne verrouille les comptes. « Définir la valeur sur une valeur faible (comme 3) permet d’éviter également la pulvérisation de mots de passe, mais peut également verrouiller les comptes trop facilement lors de l’utilisation quotidienne normale. » Le réglage du temps de verrouillage est une autre option.