Az - Conditional Access Policies / MFA Bypass

Soutenez HackTricks

Informations de base

Les politiques d'accès conditionnel Azure sont des règles configurées dans Microsoft Azure pour appliquer 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 pourrait être configurée pour exiger une authentification multi-facteurs (MFA) lorsqu'un risque de connexion est détecté. Par exemple, si le comportement de connexion d'un utilisateur est inhabituel par rapport à son schéma régulier, comme se connecter depuis un autre pays, 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 depuis des appareils disposant 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 certaines informations qui peuvent être facilement falsifiées, permettant ainsi de contourner la politique. Et si, par exemple, la politique configurait la MFA, 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 le user-agent, donc c'est assez facile à contourner. Même en imposant la MFA pour toutes les options, si vous utilisez un user-agent non reconnu, vous pourrez contourner la MFA.

Emplacements : Pays, plages 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 la MFA :

Pour contourner cela, il est possible de prétendre se connecter à une application depuis 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 dispose de nombreuses autorisations, vous pourrez utiliser cet accès.

Vous pouvez trouver l'ID de plus d'applications publiques avec des autorisations Office365 prédéfinies 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 permissions pour accéder à certaines données.

Autres applications

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

Un scénario potentiel où une politique est définie pour exiger MFA pour accéder à une application lorsque l'utilisateur utilise un navigateur (peut-être parce que c'est une application web et donc ce sera 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 et ensuite, via cette application proxy, se connecter à l'application initialement protégée par MFA.

Consultez les techniques Invoke-MFASweep et donkeytoken.

Autres contournements MFA Az

Sonnerie

Une option MFA Azure 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 de la messagerie vocale du numéro de téléphone, configurer comme message le ton de # 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 MFA, donc un attaquant pourrait enregistrer un appareil conforme, obtenir un jeton PRT et contourner ainsi le MFA.

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>

Trouvez plus d'informations sur ce type d'attaque à la page suivante :

Az - Pass the PRT

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 de justificatifs fournis et tentera d'identifier si MFA est activé. Selon la configuration des politiques d'accès conditionnel et d'autres paramètres d'authentification multi-facteurs, 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 visant à aider les consultants en sécurité qui doivent valider les Conditional Access Policies, tester les portails Microsoft avec 2FA activé, 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 contraint, il est possible de récupérer un jeton depuis le 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 la permission Sites.Read.All (de Sharepoint), même si vous ne pouvez pas accéder à Sharepoint depuis le web à cause 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

Soutenez HackTricks

Last updated