Az - Conditional Access Policies / MFA Bypass

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

Informations de base

Les politiques d'accès conditionnel Azure sont des règles mises en place dans Microsoft Azure pour imposer des contrôles d'accès aux services et applications Azure en fonction de certaines conditions. Ces politiques aident les organisations à sécuriser leurs ressources en appliquant les bons contrôles d'accès dans les bonnes circonstances. Les politiques d'accès conditionnel définissent essentiellement Qui peut accéder à Quoi depuis et Comment.

Voici quelques exemples :

  1. Politique de risque de connexion : Cette politique peut être configurée pour exiger une authentification multifacteur (MFA) lorsqu'un risque de connexion est détecté. Par exemple, si le comportement de connexion d'un utilisateur est inhabituel par rapport à son modèle habituel, comme se connecter depuis un pays différent, le système peut demander une authentification supplémentaire.

  2. Politique de conformité des appareils : Cette politique peut restreindre l'accès aux services Azure uniquement aux appareils conformes aux normes de sécurité de l'organisation. Par exemple, l'accès pourrait être autorisé uniquement à partir d'appareils dotés d'un logiciel antivirus à jour ou exécutant une certaine version du système d'exploitation.

Contournements des politiques d'accès conditionnel

Il est possible qu'une politique d'accès conditionnel vérifie des informations qui peuvent être facilement altérées permettant ainsi de contourner la politique. Et si par exemple la politique configurait l'authentification multifacteur, l'attaquant pourra la contourner.

Plateformes d'appareils - Condition d'appareil

Il est possible de définir une condition basée sur la plateforme de l'appareil (Android, iOS, Windows, macOS), cependant, cela est basé sur l'agent utilisateur donc il est assez facile à contourner. Même en rendant toutes les options obligatoires pour l'authentification multifacteur, si vous utilisez un agent utilisateur qu'il ne reconnaît pas, vous pourrez contourner l'authentification multifacteur.

Emplacements : Pays, Plages d'adresses IP - Condition d'appareil

Bien sûr, si cela est défini dans la politique conditionnelle, un attaquant pourrait simplement utiliser un VPN dans le pays autorisé ou essayer de trouver un moyen d'accéder depuis une adresse IP autorisée pour contourner ces conditions.

Applications clientes Office365

Vous pourriez indiquer que si les clients accèdent aux applications Office 365 depuis le navigateur, ils ont besoin de l'authentification multifacteur :

Pour contourner cela, il est possible de faire semblant de vous connecter à une application à partir d'une application de bureau (comme Microsoft Teams dans l'exemple suivant) ce qui contournera la protection :

roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokrns-stdout

<token>

Comme l'application Microsoft Teams a beaucoup de permissions, vous pourrez utiliser cet accès.

Vous pouvez trouver l'ID de plus d'applications publiques avec des autorisations prédéfinies Office365 dans la base de données de roadtools:

SELECT appId, displayName FROM ApplicationRefs WHERE publicCLient = 1 ORDER BY displayName ASC

Cette attaque est particulièrement intéressante car par défaut, les applications publiques Office365 auront des autorisations pour accéder à certaines données.

Autres applications

Par défaut, les autres applications créées par les utilisateurs n'auront pas d'autorisations et pourraient être privées. Cependant, les utilisateurs pourraient également créer des applications publiques leur accordant certaines autorisations.

Un scénario potentiel où une politique est définie pour exiger une authentification multifacteur pour accéder à une application lorsque l'utilisateur utilise un navigateur (peut-être parce qu'il s'agit d'une application web et que ce sera donc le seul moyen), s'il y a une application proxy - une application autorisée à interagir avec d'autres applications au nom des utilisateurs -, l'utilisateur pourrait se connecter à l'application proxy puis à travers cette application proxy se connecter à l'application initialement protégée par MFA.

Consultez les techniques Invoke-MFASweep et donkeytoken.

Autres contournements de l'authentification multifacteur Az

Sonnerie

Une option Azure MFA est de recevoir un appel sur le numéro de téléphone configuré où il sera demandé à l'utilisateur d'envoyer le caractère #.

Comme les caractères ne sont que des tons, un attaquant pourrait compromettre le message vocal de ce numéro de téléphone, configurer le message vocal avec le ton # et ensuite, lors de la demande de MFA, s'assurer que le téléphone de la victime est occupé (en l'appelant) afin que l'appel Azure soit redirigé vers la messagerie vocale.

Appareils conformes

Les politiques demandent souvent un appareil conforme ou une authentification multifacteur, donc un attaquant pourrait enregistrer un appareil conforme, obtenir un jeton PRT et contourner ainsi l'authentification multifacteur.

Commencez par enregistrer un appareil conforme dans Intune, puis obtenez le PRT avec :

$prtKeys = Get-AADIntuneUserPRTKeys - PfxFileName .\<uuid>.pfx -Credentials $credentials

$prtToken = New-AADIntUserPRTToken -Settings $prtKeys -GertNonce

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

Outils

Obtenez toutes les politiques

roadrecon plugin policies

MFASweep est un script PowerShell qui tente de se connecter à divers services Microsoft en utilisant un ensemble d'identifiants fournis et tentera d'identifier si l'authentification multifacteur (MFA) est activée. Selon la configuration des politiques d'accès conditionnel et d'autres paramètres d'authentification multifacteur, certains protocoles peuvent finir par être laissés en facteur unique. Il dispose également d'une vérification supplémentaire pour les configurations ADFS et peut tenter de se connecter au serveur ADFS local s'il est détecté.

Invoke-MFASweep -Username <username> -Password <pass>

Donkey token est un ensemble de fonctions qui visent à aider les consultants en sécurité qui ont besoin de valider les stratégies d'accès conditionnel, de tester les portails Microsoft activés pour la double authentification, etc.

Import-Module 'C:\Users\Administrador\Desktop\Azure\Modulos ps1\donkeytoken' -Force

Tester chaque portail s'il est possible de se connecter sans MFA :

Test-MFA -credential $cred -Verbose -Debug -InformationAction Continue

Parce que le portail Azure n'est pas restreint, il est possible de collecter un jeton à partir du point de terminaison du portail pour accéder à tout service détecté par l'exécution précédente. Dans ce cas, Sharepoint a été identifié, et un jeton pour y accéder est demandé:

$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
Read-JWTtoken -token $token.access_token

En supposant que le jeton ait l'autorisation Sites.Read.All (de Sharepoint), même si vous ne pouvez pas accéder à Sharepoint depuis le web en raison de MFA, il est possible d'utiliser le jeton pour accéder aux fichiers avec le jeton généré:

$data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl

Références

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert de l'équipe rouge HackTricks AWS)!

Autres façons de soutenir HackTricks:

Dernière mise à jour