Aperçu

Récemment, Eric Saraga, chercheur chez Varonis, a publié un article de blog annonçant une nouvelle attaque contre Azure Active Directory (Azure AD) qui peut permettre à un attaquant de se connecter en tant qu’utilisateur synchronisé. La méthode d’attaque exploite une faille dans la méthode de vérification de mot de passe d’authentification Pass-Through (PTA) permettant aux utilisateurs d’utiliser leurs informations d’identification Active Directory sur site pour se connecter à Azure et Office 365.

PTA est un mécanisme disponible pour les organisations permettant aux utilisateurs d’utiliser leur Active Directory sur site (également connu sous le nom de services d’annuaire Active Directory, ou « AD DS » et à ne pas confondre avec Azure AD, qui est le service d’annuaire basé sur le cloud de Microsoft – clair comme mud?)

PTA transmet simplement le nom d’utilisateur et le mot de passe de l’utilisateur et le transmet en toute sécurité aux AD DS sur site de l’organisation pour vérification. Les deux autres méthodes disponibles sont:

  • Synchronisation de hachage de mot de passe : cette méthode synchronise les hachages de mot de passe d’AD sur site dans Azure AD (en passant, cette méthode n’est pas recommandée par Assura).
  • Fédération via les services de fédération Active Directory (ADFS) : Cette méthode repose sur la fonction SAML (Security Assertion Markup Language) de Microsoft disponible sur site pour Microsoft Windows Server.

PTA est facilité par Microsoft Azure AD Connect qui facilite tout un ensemble de services, y compris la synchronisation des utilisateurs et des groupes d’AD sur site vers Azure AD / Office 365. De toute évidence, avec un seul serveur sur site facilitant le PTA, cela présente aux organisations un point de défaillance unique qui, s’il est hors ligne, empêcherait les utilisateurs de se connecter aux services Azure et Office 365. Ainsi, pour résoudre ce problème, Microsoft a développé un agent autonome qui peut s’exécuter sur un serveur différent et créer un mécanisme d’authentification haute disponibilité pour PTA.

Pour être clair, l’attaque n’exploite pas une faiblesse dans la PTA elle-même, elle exploite une faiblesse dans la façon dont l’agent fait sa chose. Cependant, et pour être clair, le serveur exécutant l’agent doit d’abord être compromis pour que l’attaque contre l’agent puisse réussir. Par conséquent, un attaquant a besoin d’un accès au réseau local ou doit exploiter une machine locale à distance et basculer vers l’agent via l’hôte compromis. L’attaquant doit également obtenir des privilèges d’administration sur le serveur hébergeant l’agent.

Une fois qu’un attaquant a réussi à compromettre un serveur exécutant l’agent Azure, il manipule le flux d’authentification en accrochant la fonction API LogonUserW. Une fois que l’attaquant s’est connecté avec succès à la fonction API, il peut compromettre les mots de passe des utilisateurs synchronisés se connectant à Azure AD / Office 365. Varonis a poussé cela un peu plus loin et a automatisé la collecte des informations d’identification en injectant une DLL personnalisée (bibliothèque de liens dynamiques) dans le flux de processus qui authentifiera toujours l’utilisateur, mais en plus, écrit le nom d’utilisateur et le mot de passe de l’individu dans un fichier texte spécifié. Bien que cela donne à l’attaquant de nombreuses façons de s’authentifier, cela ne fournit pas la « clé squelette ». »Pour y parvenir, nous avons besoin de plus.

La modification de la valeur de retour dans la fonction API, LogonUserW, pour accepter n’importe quel mot de passe comme correct pour n’importe quel utilisateur est la clé pour transformer cette attaque en attaque de clé squelette. LogonUserW est une fonction booléenne qui nécessite la population du jeton de l’utilisateur. Si ce jeton renvoie une valeur true, l’authentification est réussie. Le processus utilisé par l’agent Azure pour authentifier les utilisateurs a son propre jeton et la fonction API LogonUserW est appelée à l’intérieur de ce processus, de sorte que les chercheurs de Varonis se sont demandé : « Pourquoi ne pas utiliser le propre jeton du processus agent? »Et voilà, la clé squelette Azure AD a été créée: le propre jeton du processus permettra à un attaquant de se connecter en tant qu’utilisateur, y compris un compte administrateur global.

Les détails sanglants peuvent être trouvés dans le post de Saraga ici: https://blogvaronis2.wpengine.com/azure-skeleton-key/

Coup de chapeau à notre pote Steven Rennard chez Varonis pour nous avoir alertés sur cette recherche.

Prise d’Assura

Bien qu’il s’agisse certainement d’une attaque à fort impact, il semble d’après la communication de Varonis avec Microsoft qu’il n’est pas prévu de corriger cette vulnérabilité de sitôt. En tant que tel, il devient d’autant plus important de s’assurer que votre environnement et vos utilisateurs sont parfaitement protégés grâce à des pratiques de configuration sécurisées et à des technologies de sécurité modernes.

La détection d’un attaquant entrant dans votre réseau via une technologie IDS / IPS ou SIEM, la limitation de la capacité de l’attaquant à escalader les privilèges ou à pivoter via un outil de détection et de réponse de point de terminaison et la prévention de cette attaque par clé squelette via la mise en œuvre de la technologie d’authentification multifacteur (MFA) sont toutes des options viables et pratiques pour atténuer cette menace.

Si vous êtes un client SIEM Géré par Assura, une Protection de point de terminaison gérée ou un client d’authentification Multifacteur gérée, nous prenons activement des mesures pour vous protéger de ces attaques. Si vous êtes déjà un client Assura, contactez votre ISO virtuel ou votre POC Assura pour obtenir des conseils supplémentaires.

Restez en sécurité, restez en bonne santé et, comme toujours, n’hésitez pas à soumettre vos questions à ce sujet ou à toute autre question de cybersécurité via notre site Web ou à [email protected] .

Cordialement,

L’équipe Assura

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.