diff --git a/src/pentesting-cloud/azure-security/az-device-registration.md b/src/pentesting-cloud/azure-security/az-device-registration.md index 065e6845a..91b076f03 100644 --- a/src/pentesting-cloud/azure-security/az-device-registration.md +++ b/src/pentesting-cloud/azure-security/az-device-registration.md @@ -1,20 +1,20 @@ -# Az - Enregistrement de l'appareil +# Az - Enregistrement d'appareil {{#include ../../banners/hacktricks-training.md}} ## Informations de base -Lorsqu'un appareil rejoint AzureAD, un nouvel objet est créé dans AzureAD. +Quand un appareil rejoint AzureAD, un nouvel objet est créé dans AzureAD. -Lors de l'enregistrement d'un appareil, **l'utilisateur est invité à se connecter avec son compte** (demandant une MFA si nécessaire), puis il demande des jetons pour le service d'enregistrement des appareils et demande ensuite une confirmation finale. +Lors de l'enregistrement d'un appareil, l'**user is asked to login with his account** (demande de MFA si nécessaire), puis il demande des jetons pour le service d'enregistrement d'appareil et demande ensuite une confirmation finale. -Ensuite, deux paires de clés RSA sont générées dans l'appareil : La **clé de l'appareil** (**clé publique**) qui est envoyée à **AzureAD** et la **clé de transport** (**clé privée**) qui est stockée dans le TPM si possible. +Ensuite, deux RSA keypairs sont générés sur l'appareil : la **device key** (**public** key) qui est envoyée à **AzureAD** et la **transport** key (**private** key) qui est stockée dans le TPM si possible. -Ensuite, l'**objet** est généré dans **AzureAD** (pas dans Intune) et AzureAD renvoie à l'appareil un **certificat** signé par lui. Vous pouvez vérifier que l'**appareil est joint à AzureAD** et des informations sur le **certificat** (comme s'il est protégé par le TPM). +Ensuite, l'**object** est généré dans **AzureAD** (pas dans Intune) et AzureAD renvoie à l'appareil un **certificate** signé par celui-ci. Vous pouvez vérifier que l'**device is AzureAD joined** et obtenir des informations sur le **certificate** (par exemple s'il est protégé par TPM).: ```bash dsregcmd /status ``` -Après l'enregistrement de l'appareil, un **Primary Refresh Token** est demandé par le module LSASS CloudAP et remis à l'appareil. Avec le PRT est également livré la **clé de session chiffrée afin que seul l'appareil puisse la déchiffrer** (en utilisant la clé publique de la clé de transport) et elle est **nécessaire pour utiliser le PRT.** +Après l'enregistrement de l'appareil, un **Primary Refresh Token** est demandé par le module LSASS CloudAP et remis à l'appareil. Avec le PRT est aussi fournie la **clé de session chiffrée de sorte que seul l'appareil puisse la déchiffrer** (en utilisant la clé publique de la transport key) et elle est **nécessaire pour utiliser le PRT.** Pour plus d'informations sur ce qu'est un PRT, consultez : @@ -24,18 +24,18 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md ### TPM - Trusted Platform Module -Le **TPM** **protège** contre l'**extraction** de clés d'un appareil éteint (s'il est protégé par un code PIN) et contre l'extraction du matériel privé de la couche OS.\ -Mais il **ne protège pas** contre le **sniffing** de la connexion physique entre le TPM et le CPU ou **l'utilisation du matériel cryptographique** dans le TPM pendant que le système fonctionne à partir d'un processus avec des droits **SYSTEM**. +Le **TPM** **protège** contre l'**extraction** de clés depuis un appareil éteint (si protégé par PIN) et contre l'extraction du matériel privé depuis la couche OS.\ +Mais il **ne protège pas** contre le **sniffing** de la connexion physique entre le TPM et le CPU ou contre **l'utilisation du matériel cryptographique** du TPM pendant que le système est en fonctionnement depuis un processus disposant des droits **SYSTEM**. -Si vous consultez la page suivante, vous verrez que **voler le PRT** peut être utilisé pour accéder comme un **utilisateur**, ce qui est génial car le **PRT est situé sur les appareils**, donc il peut être volé à partir d'eux (ou s'il n'est pas volé, abusé pour générer de nouvelles clés de signature) : +Si vous consultez la page suivante, vous verrez que **stealing the PRT** peut être utilisé pour obtenir l'accès comme l'**utilisateur**, ce qui est avantageux car le **PRT est stocké sur les appareils**, donc il peut leur être volé (ou, s'il n'est pas volé, abusé pour générer de nouvelles clés de signature) : {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} -## Enregistrement d'un appareil avec des jetons SSO +## Enregistrement d'un appareil avec des tokens SSO -Il serait possible pour un attaquant de demander un jeton pour le service d'enregistrement des appareils Microsoft depuis l'appareil compromis et de l'enregistrer : +Il serait possible pour un attaquant de demander un token pour le service d'enregistrement d'appareils Microsoft depuis l'appareil compromis et de l'enregistrer : ```bash # Initialize SSO flow roadrecon auth prt-init @@ -47,36 +47,36 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie # Custom pyhton script to register a device (check roadtx) registerdevice.py ``` -Ce qui vous donnera un **certificat que vous pouvez utiliser pour demander des PRT à l'avenir**. Cela permet de maintenir la persistance et **de contourner la MFA** car le jeton PRT original utilisé pour enregistrer le nouvel appareil **avait déjà des autorisations MFA accordées**. +Ce qui vous donnera un **certificat que vous pouvez utiliser pour demander des PRTs à l'avenir**. Permettant ainsi de maintenir la persistance et de **contourner la MFA** parce que le PRT original utilisé pour enregistrer le nouvel appareil **avait déjà les permissions MFA accordées**. > [!TIP] -> Notez que pour effectuer cette attaque, vous aurez besoin d'autorisations pour **enregistrer de nouveaux appareils**. De plus, enregistrer un appareil ne signifie pas que l'appareil sera **autorisé à s'inscrire dans Intune**. +> Notez que pour réaliser cette attaque vous aurez besoin des autorisations pour **register new devices**. De plus, enregistrer un appareil ne signifie pas que l'appareil sera **autorisé à s'enrôler dans Intune**. > [!CAUTION] -> Cette attaque a été corrigée en septembre 2021 car vous ne pouvez plus enregistrer de nouveaux appareils en utilisant des jetons SSO. Cependant, il est toujours possible d'enregistrer des appareils de manière légitime (en ayant un nom d'utilisateur, un mot de passe et MFA si nécessaire). Vérifiez : [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md). +> Cette attaque a été corrigée en septembre 2021 car vous ne pouvez plus enregistrer de nouveaux appareils en utilisant des SSO tokens. Cependant, il est toujours possible d'enregistrer des appareils de manière légitime (en ayant le username, password et MFA si nécessaire). Check: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md). ## Écraser un ticket d'appareil -Il était possible de **demander un ticket d'appareil**, **écraser** celui en cours de l'appareil, et pendant le flux **voler le PRT** (donc pas besoin de le voler depuis le TPM. Pour plus d'infos [**vérifiez cette présentation**](https://youtu.be/BduCn8cLV1A). +Il était possible de **request a device ticket**, **overwrite** celui courant de l'appareil, et durant le flux **steal the PRT** (donc pas besoin de le voler depuis le TPM). Pour plus d'infos [**voir cette conférence**](https://youtu.be/BduCn8cLV1A).
> [!CAUTION] > Cependant, cela a été corrigé. -## Écraser la clé WHFB +## Remplacer la clé WHFB -[**Vérifiez les diapositives originales ici**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf) +[**Voir les slides originales ici**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf) Résumé de l'attaque : -- Il est possible d'**écraser** la clé **WHFB enregistrée** d'un **appareil** via SSO -- Cela **contourne la protection TPM** car la clé est **interceptée lors de la génération** de la nouvelle clé -- Cela fournit également **de la persistance** +- Il est possible de **remplacer** la clé **WHFB enregistrée** d'un **appareil** via SSO +- Cela **déjoue la protection TPM** car la clé est **interceptée lors de la génération** de la nouvelle clé +- Cela fournit aussi de la **persistance**
-Les utilisateurs peuvent modifier leur propre propriété searchableDeviceKey via l'Azure AD Graph, cependant, l'attaquant doit avoir un appareil dans le locataire (enregistré à la volée ou ayant volé un certificat + clé d'un appareil légitime) et un jeton d'accès valide pour l'AAD Graph. +Les utilisateurs peuvent modifier leur propre propriété searchableDeviceKey via l'Azure AD Graph, cependant, l'attaquant doit disposer d'un appareil dans le tenant (enregistré à la volée ou ayant volé cert + key d'un appareil légitime) et d'un jeton d'accès valide pour l'AAD Graph. Ensuite, il est possible de générer une nouvelle clé avec : ```bash