Attaque contre Active Directory via Microsoft Intune - et comment l'endiguer avec TameMyCerts

Auteur Uwe GradeneggerPublié le Catégories Test d'intrusion, Service d'enregistrement des périphériques réseau (NDES), Sécurité, TameMyCerts, Utilisation du certificat, Autorité de certificationÉtiquettes , , , , , , , , , , , , , , , ,

Dirk-jan Mollema a récemment présenté une attaque permettant d'obtenir un certificat pour des comptes hautement privilégiés via Intune.. Celui-ci peut ensuite être utilisé pour compromettre l'ensemble de l'environnement Active Directory.

L'attaque est comparable dans ses grandes lignes à ce que j'ai déjà décrit dans l'article "De zéro à Enterprise Administrator grâce au service d'enregistrement des périphériques réseau (NDES) - et ce qui peut être fait à ce sujet" et dans l'article "Vecteur d'attaque sur le service d'annuaire Active Directory via le mécanisme de connexion par carte à puce"(également connu sous le nom de ESC1).

La nouveauté consiste toutefois à exploiter le système de gestion des appareils mobiles (MDM) - en l'occurrence Microsoft Intune - de manière appropriée.

Ce qui n'est pas nouveau en revanche, c'est ce qui peut être fait contre cela avec le module de politique TameMyCerts pour les Active Directory Certificate Services afin de réduire drastiquement la surface d'attaque...

Nous ne devrions pas non plus nous sentir faussement en sécurité si notre entreprise utilise un autre système MDM. L'attaque fondamentale est la même partout, et dans la plupart des autres systèmes MDM, le processus de demande de certificat est encore beaucoup moins sûr.

Le problème fondamental est que les attaques de ce type exploitent le fait que le cas d'utilisation du certificat utilisé exige que le modèle de certificat correspondant soit configuré de manière à accepter toutes les identités demandées par le demandeur (modèle de certificat hors ligne).

Cette configuration est une source d'ennuis

Si un attaquant obtient maintenant la possibilité d'envoyer directement ou indirectement une demande de certificat à l'autorité de certification, il peut se faire délivrer des certificats pour n'importe quelle identité, y compris celles de comptes privilégiés.

TameMyCerts résout ce dilemme.

Qu'est-ce que TameMyCerts et comment fonctionne-t-il ?

TameMyCerts est un Module de politiquepour sécuriser l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend les fonctions de l'autorité de certification et permet de l'application élargie de la réglementationIl permet d'automatiser en toute sécurité l'émission de certificats. TameMyCerts est unique dans l'écosystème Microsoft et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement.

TameMyCerts s'implique dans le processus d'émission de certificats (graphique © Microsoft)

TameMyCerts est open source et peut être utilisé gratuitement. Toutefois, pour une utilisation en entreprise, il est recommandé d'utiliser le Conclusion d'un contrat de maintenance. Cela garantit que vous recevrez un soutien qualifié et que le module pourra être développé à long terme avec une qualité élevée.

TameMyCerts est également synonyme de qualité exceptionnelle. Ainsi, toutes les fonctions sont accompagnées de tests automatiques afin de garantir un fonctionnement irréprochable.

TameMyCerts cherche toujours des raisons de refuser une demande de certificat validée par l'autorité de certification Microsoft. L'inverse ne se produit jamais, à savoir qu'une demande de certificat déjà refusée est à nouveau validée.

Forcer des champs de certificat exactement définis avec une syntaxe exactement définie

TameMyCerts permet de définir avec précision le contenu de certificat pouvant être demandé pour les modèles de certificats hors ligne.

Il nous permet d'appliquer les restrictions suivantes.

  • Limiter les types de noms distincts relatifs au sujet (RDN) et de noms alternatifs au sujet (SAN) autorisés.
  • Appliquer des règles syntaxiques (expressions régulières, masques de sous-réseau IP) par rapport aux types de RDN et de SAN définis

Relier (mapper) l'identité demandée en retour sur les comptes concernés

TameMyCerts peut mettre en correspondance le contenu du certificat demandé avec le compte concerné. Pour cela, le contenu du certificat est évalué selon des règles définies et un objet correspondant est recherché dans l'Active Directory.

Un refus est alors prononcé dans les cas suivants :

  • Aucun objet correspondant aux critères de recherche n'a été trouvé.
  • Plus d'un objet correspondant aux critères de recherche a été trouvé.
  • L'objet trouvé est désactivé.
  • L'objet trouvé n'est pas membre de groupes de sécurité définis (facultatif, mais très utile).
  • L'objet trouvé est membre de groupes de sécurité interdits définis (facultatif, mais très utile).
  • Les attributs sur l'objet trouvé ne correspondent pas aux critères syntaxiques définis (facultatif, mais très utile).

Mise en œuvre concrète d'une configuration de politique

TameMyCerts est largement documenté. La documentation est consultable en ligne.

Ainsi, afin de permettre l'émission de certificats pour les utilisateurs réguliers d'Intune dans une mesure bien définie, nous créons, après la Installation de TameMyCerts l'ensemble de règles décrites ci-dessous. Nous utiliserons une configuration pour les certificats d'utilisateur. La logique de base est toutefois comparable pour les certificats de périphérique.

Création d'un fichier de configuration

La première étape consiste à créer un fichier de configuration (XML) avec le même nom que le modèle de certificat dans le répertoire créé lors de l'installation.

Dans notre exemple, le modèle de certificat s'appelle "ADCSLaborIntuneUser", notre fichier de configuration s'appelle en conséquence "ADCSLaborIntuneUser.xml".

Ensuite, nous affinons notre ensemble de règles jusqu'à ce qu'il limite au maximum les possibilités de demande de certificat.

Voir la structure de base comme suit :

<CertificateRequestPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- here we will place our rules -->
</CertificateRequestPolicy>

Étape 1 : Règles syntaxiques

Dans notre exemple, nous partons du principe que nous avons défini les règles suivantes dans Intune :

Le contenu du certificat demandé sera donc le suivant :

  • Le Subject Distinguished Name (DN) contient le nom d'utilisateur (CN={{UserName}}}) et l'adresse électronique de l'utilisateur (E={EmailAddress}}).
  • Le Subject Alternative Name (SAN) contiendra le nom principal de l'utilisateur ({{UtilisateurPrincipalName}})

Nos règles syntaxiques se présentent donc comme suit :

<Subject>
  <SubjectRule>
    <Field>commonName</Field>
    <Mandatory>true</Mandatory>
    <Patterns>
      <Pattern>
        <Expression>^[a-zA-Z0-9]*$</Expression>
      </Pattern>
    </Patterns>
  </SubjectRule>
  <SubjectRule>
    <Field>emailAddress</Field>
    <Mandatory>true</Mandatory>
    <Patterns>
      <Pattern>
        <Expression>^[a-zA-Z0-9]*\@intra\.adcslabor\.de$</Expression>
      </Pattern>
    </Patterns>
  </SubjectRule>
</Subject>
<SubjectAlternativeName>
  <SubjectRule>
    <Field>userPrincipalName</Field>
    <Mandatory>true</Mandatory>
    <Patterns>
      <Pattern>
        <Expression>^[a-zA-Z0-9]*\@intra\.adcslabor\.de$</Expression>
      </Pattern>
    </Patterns>
  </SubjectRule>
</SubjectAlternativeName>

Étape 2 : Mappage du contenu du certificat demandé sur le compte Active Directory correspondant

Nous savons que nos utilisateurs Intune se trouvent tous dans une unité organisationnelle spécifique. Nous limitons donc la recherche en conséquence.

<DirectoryServicesMapping>
  <!-- ... -->
  <SearchRoot>OU=ADCS Labor Users,DC=intra,DC=adcslabor,DC=de</SearchRoot>
</DirectoryServicesMapping>

Pour établir le lien entre le contenu du certificat demandé et le compte Active Directory, il faut des critères de correspondance clairs. Étant donné que les demandes de certificats sont soumises au userPrincipalName peut être utilisé. Nous souhaitons donc que le contenu du userPrincipalName SAN de la demande de certificat, afin d'inclure des objets de type user avec la même valeur dans son userPrincipalName attribut.

Une règle correspondante se présenterait comme suit. Mais comme il s'agit du paramètre par défaut, elle peut aussi être omise.

<DirectoryServicesMapping>
  <!-- ... -->
  <CertificateAttribute>userPrincipalName</CertificateAttribute>
  <DirectoryServicesAttribute>userPrincipalName</DirectoryServicesAttribute>
  <ObjectCategory>user</ObjectCategory>
</DirectoryServicesMapping>

Nous savons également que tous les utilisateurs d'Intune doivent être membres d'un certain groupe de sécurité pour obtenir un certificat.

<DirectoryServicesMapping>
  <!-- ... -->
  <AllowedSecurityGroups>
    <string>CN=Intune Users,OU=ADCS Labor Groups,DC=intra,DC=adcslabor,DC=de</string>
  </AllowedSecurityGroups>
</DirectoryServicesMapping>

De plus, nous ne souhaitons en aucun cas que les membres de groupes privilégiés reçoivent un tel certificat.

<DirectoryServicesMapping>
  <!-- ... -->
  <DisallowedSecurityGroups>
    <string>CN=Domain Admins,CN=Users,DC=intra,DC=adcslabor,DC=de</string>
  </DisallowedSecurityGroups>
</DirectoryServicesMapping>

En option : extension du certificat SID

Tant qu'on y est, on pourrait aussi ajouter l'extension Security Identifier Certificate dans le certificat émis.

<SecurityIdentifierExtension>Add</SecurityIdentifierExtension>

L'approche alternative du SID Uniform Resource Identifier (URI) est également pris en charge par TameMyCerts. Et en général, il est recommandé de ne pas faire demander ces informations hautement sensibles par le demandeur, mais de les faire inscrire dans le certificat par l'autorité de certification avec TameMyCerts. Cela permet de garantir que le SID correspondant au compte associé se retrouve dans le certificat.

Facultatif : utiliser les attributs Active Directory du compte mappé pour améliorer le contenu du certificat.

Les attributs utilisables sont ici documenté.

Nous pourrions également décider de modifier le contenu du certificat demandé. Par exemple, nous pourrions ajouter le nom de l'entreprise et écrire le nom du département dans les propriétés du compte utilisateur dans le Subject Distinguished Name du certificat délivré.

<OutboundSubject>
  <OutboundSubjectRule>
    <Field>organizationName</Field>
    <Value>ADCS Labor</Value>
  </OutboundSubjectRule>
  <OutboundSubjectRule>
    <Field>organizationalUnitName</Field>
    <Value>{ad:department}</Value>
  </OutboundSubjectRule>
</OutboundSubject>

Résumé

D'autres exemples sont fournis avec TameMyCerts. Les fichiers de configuration d'exemple sont également consultable sur GitHub.

La définition complète de la politique se présente alors comme suit :

<CertificateRequestPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Subject>
    <SubjectRule>
      <Field>commonName</Field>
      <Mandatory>true</Mandatory>
      <Patterns>
        <Pattern>
          <Expression>^[a-zA-Z0-9]*$</Expression>
        </Pattern>
      </Patterns>
    </SubjectRule>
    <SubjectRule>
      <Field>emailAddress</Field>
      <Mandatory>true</Mandatory>
      <Patterns>
        <Pattern>
          <Expression>^[a-zA-Z0-9]*\@intra\.adcslabor\.de$</Expression>
        </Pattern>
      </Patterns>
    </SubjectRule>
  </Subject>
  <SubjectAlternativeName>
    <SubjectRule>
      <Field>userPrincipalName</Field>
      <Mandatory>true</Mandatory>
      <Patterns>
        <Pattern>
          <Expression>^[a-zA-Z0-9]*\@intra\.adcslabor\.de$</Expression>
        </Pattern>
      </Patterns>
    </SubjectRule>
  </SubjectAlternativeName>
  <DirectoryServicesMapping>
    <SearchRoot>OU=ADCS Labor Users,DC=intra,DC=adcslabor,DC=de</SearchRoot>
    <AllowedSecurityGroups>
      <string>CN=Intune Users,OU=ADCS Labor Groups,DC=intra,DC=adcslabor,DC=de</string>
    </AllowedSecurityGroups>
    <DisallowedSecurityGroups>
      <string>CN=Domain Admins,CN=Users,DC=intra,DC=adcslabor,DC=de</string>
    </DisallowedSecurityGroups>
  </DirectoryServicesMapping>
  <OutboundSubject>
    <OutboundSubjectRule>
      <Field>organizationName</Field>
      <Value>ADCS Labor</Value>
    </OutboundSubjectRule>
    <OutboundSubjectRule>
      <Field>organizationalUnitName</Field>
      <Value>{ad:department}</Value>
    </OutboundSubjectRule>
  </OutboundSubject>
  <SecurityIdentifierExtension>Add</SecurityIdentifierExtension>
</CertificateRequestPolicy>

Enregistrement et alerte

Les événements consignés par TameMyCerts sont les suivants ici documenté.

Si l'autorité de certification refuse une demande de certificat par TameMyCerts, cet événement est consigné sur l'autorité de certification et une alerte correspondante peut être déclenchée.

Test de fonctionnement

Pour tester, j'utilise le PSCertificateEnrollment module PowerShell. Le type de demande de certificat - c'est-à-dire par MS-WCCE, par SCEP, et avec ou sans Mobile Device Management - ne joue aucun rôle pour le test, car la vérification de la demande de certificat s'effectue directement sur l'autorité de certification et est donc indépendante du type de demande.

Cas de test 1 : violation du contenu défini du certificat

Pour le premier test, nous demandons un certificat qui n'est qu'un commonName comprend.

New-CertificateRequest -Subject "CN=rudi" |
Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

Cependant, comme nous le rappelons, nos règles syntaxiques exigent également qu'une emailAddress ainsi qu'un userPrincipalName sont inclus. La demande de certificat est refusée en conséquence et un événement est consigné.

Cas de test 2 : Les règles syntaxiques empêchent l'émission de certificats

Pour le deuxième test, nous demandons bien tous les champs définis, mais nous construisons une erreur dans les userPrincipalName un.

New-CertificateRequest `
  -Subject "CN=rudi,E=rudi@intra.adcslabor.de"  `
  -Upn "rudi@adcslabor.de" | 
Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

La demande de certificat est refusée en conséquence.

Cas-test 3 : Échec de la cartographie de l'objet demandé

Pour le test suivant, nous demandons un userPrincipalName qui n'est pas connu dans le domaine.

New-CertificateRequest `
  -Subject "CN=rudi,E=rudi@intra.adcslabor.de" `
  -Upn "rudy@intra.adcslabor.de" |
Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

La demande de certificat est refusée en conséquence.

Nous corrigeons notre erreur, mais l'utilisateur que nous recherchons ne se trouve pas dans l'unité organisationnelle définie.

New-CertificateRequest -Subject "CN=rudi,E=rudi@intra.adcslabor.de" -Upn "rudi@intra.adcslabor.de" | Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

Notre demande de certificat est refusée en conséquence.

Cas-test 4 : Les adhésions de groupe pour l'objet demandé échouent

Maintenant que nous avons déplacé notre utilisateur test Rudi dans l'unité d'organisation correcte, nous tentons à nouveau notre chance.

New-CertificateRequest `
  -Subject "CN=rudi,E=rudi@intra.adcslabor.de" `
  -Upn "rudi@intra.adcslabor.de" | 
Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborIntuneUser"

L'utilisateur n'est cependant pas membre d'un des groupes définis - en conséquence, la demande de certificat est à nouveau refusée.

Ok, alors ajoutons maintenant Rudi dans les "Intune Users" définis et essayons à nouveau.

Cependant, comme l'utilisateur est membre du groupe interdit des administrateurs de domaine, nous échouons à nouveau.

Cas-test 5 : Délivrance réussie du certificat

Si notre utilisateur Rudi remplit enfin toutes les conditions, nous recevrons enfin notre certificat.

Dans le Subject Distinguished Name, nous voyons que le "département"du compte Active Directory associé a été transféré dans le champ organizationalUnit du certificat. De même, le nom de l'entreprise a été transféré dans le champ organizationName champ du certificat.

L'extension du certificat Security Identifier se trouve également dans le certificat délivré.

Conclusion

La confiance c'est bien, le contrôle c'est mieux. TameMyCerts permet aux administrateurs de PKI de reprendre le contrôle sur les certificats qu'ils émettent et d'augmenter considérablement le niveau de sécurité de la PKI.

TameMyCerts est open source et peut être utilisé gratuitement. Toutefois, pour une utilisation en entreprise, il est recommandé d'utiliser le Conclusion d'un contrat de maintenance. Cela garantit que vous recevrez un soutien qualifié et que le module pourra être développé à long terme avec une qualité élevée.

Mais attendez... il y a plus

TameMyCerts peut faire bien plus encore, et peut en conséquence offrir une valeur ajoutée significative dans un grand nombre de cas d'application. Voici un extrait de ces...

Liens complémentaires :

Sources externes

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais