Angriff auf das Active Directory über Microsoft Intune – und wie sie mit TameMyCerts eingedämmt werden können

Dirk Jan Mollema hat jüngst einen Angriff vorgestellt, bei welchem man sich über Intune ein Zertifikat für hochprivilegierte Konten erschleichen kann. Dieses kann dann verwendet werden, um die gesamte Active Directory Umgebung zu komprimittieren.

Der Angriff ist in seinen Grundzügen vergleichbar mit dem, was ich schon im Artikel "Von Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann" und im Artikel "Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus" beschrieben habe (im Allgemeinen auch auch bekannt als ESC1).

Neu ist jedoch, das Mobile Device Management (MDM) System – in diesem Fall Microsoft Intune – entsprechend auszunutzen.

Nicht neu ist hingegen was mit dem TameMyCerts Policy Modul für die Active Directory Certificate Services dagegen getan werden kann, um Angriffsoberfläche drastisch zu reduzieren.

Wir sollten uns auch nicht in falscher Sicherheit wägen, wenn unser Unternehmen ein anderes MDM-System einsetzt. Der grundsätzliche Angriff ist überall der gleiche, und bei den meisten anderen MDM-Systemen ist der Zertifikatbeantragungs-Prozess noch deutlich unsicherer.

Das grundsätzliche Problem ist, dass alle den Umstand ausnutzen, dass der verwendete Zertifikats-Use-Case erfordert, die dazugehörige Zertifikatvorlage so zu konfigurieren, dass jegliche durch den Antragsteller beantragten Identitäten angenommen werden (Offline-Zertifikatvorlage).

Diese Konfiguration schreit förmlich nach Ärger

Erlangt ein Angreifer nun die Möglichkeit, direkt oder indirekt einen Zertifikatantrag an die Zertifizierungsstelle zu senden, kann er sich Zertifikate für jegliche Identität – auch solche von privilegierten Konten – ausstellen lassen.

TameMyCerts löst dieses Dilemma.

Was ist TameMyCerts und wie funktioniert es

TameMyCerts ist ein Policy Modul, um die Microsoft Zertifizierungsstelle (Active Directory Certificate Services) abzusichern. Es erweitert die Funktionen der Zertifizierungsstelle und ermöglicht die erweitere Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikatausstellungen zu ermöglichen. TameMyCerts ist einzigartig im Microsoft-Ökosystem und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden.

TameMyCerts klinkt sich in den Zertifikatausstellungsprozess ein (Grafik © Microsoft)

TameMyCerts ist Open Source und kann kostenfrei verwendet werden. Für den Einsatz im Unternehmensbereich empfiehlt sich jedoch der Abschluss eines Wartungsvertrags. Dies stellt sicher, dass Sie qualifizierte Unterstützung erhalten und dass das Modul langfristig in hoher Qualität weiterentwickelt werden kann.

TameMyCerts steht auch für herausragende Qualität. So sind alle Funktionen mit automatischen Tests hinterlegt, um eine einwandfreie Funktionsweise zu gewährleisten.

TameMyCerts sucht grundsätzlich nach Gründen, einen durch die Microsoft-Zertifizierungsstelle freigegebene Zertifikatanforderung doch noch abzulehnen. Der umgekehrte Fall – dass eine bereits abgelehnte Zertifikatanforderung dennoch wieder freigegeben wird – wird niemals eintreten.

Erzwingen exakt definierter Zertifikatfelder mit exakt festgelegter Syntax

TameMyCerts erlaubt es, den beantragbaren Zertifikatinhalt für Offline-Zertifikatvorlagen exakt zu definieren.

Es erlaubt uns, folgende Einschränkungen vorzunehmen.

Einschränken der erlaubten Subject Relative Distinguished Name- (RDN) und Subject Alternative Name (SAN)-Typen.
Anwenden von Syntaxregeln (Reguläre Ausdrücke, IP-Subnetzmasken) gegen die definierten RDN- und SAN-Typen

Verbinden (mappen) der beantragten Identität zurück auf die betreffenden Konten

TameMyCerts kann den beantragten Zertifikatinhalt zurück auf das betreffende Konto mappen. Hierbei wird der Zertifikatinhalt anhand definierter Regeln ausgewertet und ein passendes Objekt im Active Directory gesucht.

Eine Ablehnung erfolgt dann in den folgenden Fällen:

Es wurde kein den Suchkriterien entsprechendes Objekt gefunden.
Es wurde mehr als ein den Suchkriterien entsprechendes Objekt gefunden.
Das gefundene Objekt ist deaktiviert.
Das gefundene Objekt ist nicht Mitglied definierter Sicherheitsgruppen.
Das gefundene Objekt ist Mitglied definierter verbotener Sicherheitsgruppen.
Attribute auf dem gefundenen Objekt entsprechen nicht definierter syntaktischer Kriterien.

Konkrete Umsetzung einer Richtlinien-Konfiguration

TameMyCerts ist umfassend dokumentiert. Die Dokumentation ist online einsehbar.

Um also die Ausstellung von Zertifikaten für reguläre Intune-Benutzer in genau definiertem Umfang zu ermöglichen, erstellen wir nach der Installation von TameMyCerts das nachfolgend beschriebene Regelwerk. Wir werden eine Konfiguration für Benutzer-Zertifikate verwenden. Die grundsätzliche Logik ist für Geräte-Zertifikate jedoch vergleichbar.

Erstellen einer Konfigurationsdatei

Der erste Schritt besteht darin, eine Konfigurationsdatei (XML) mit dem gleichen Namen wie die Zertifikatvorlage im während der Installation erzeugten Verzeichnis zu erstellen.

In unserem Beispiel heißt die Zertifikatvorlage "ADCSLaborIntuneUser", unsere Konfigurationsdatei entsprechend "ADCSLaborIntuneUser.xml".

Anschließend verfeinern wir unser Regelwerk, bis es die Möglichkeiten zur Zertifikatbeantragung maximal einschränkt.

Schritt 1: Syntaxregeln

In unserem Beispiel gehen wir davon aus, dass wir in Intune wir folgende Regeln definiert haben:

Der beantragte Zertifikatinhalt wird somit wie folgt aussehen:

Der Subject Distinguished Name (DN) beinhaltet den Benutzernamen (CN={{UserName}}) und die E-Mail Adresse des Benutzers (E={{EmailAddress}}).
Der Subject Alternative Name (SAN) wird den Benutzerprinzipalnamen des Benutzers enthalten ({{UserPrincipalName}})

Unsere Syntaxregeln sehen somit wie folgt aus:

<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>

Schritt 2: Mapping des beantragten Zertifikatinhalts auf das dazugehörige Active Directory Konto

Wir wissen, dass unsere Intune-Benutzer alle in einer bestimmten Organisationseinheit befinden. Also schränken wir die Suche entsprechend ein.

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

Zum Herstellen der Verbindung zwischen dem beantragten Zertifikatinhalt und dem Active Directory-Konto braucht es eindeutige Mapping-Kriterien. Da die Zertifikatanträge den userPrincipalName beinhalten, kann dieser verwendet werden. Wir möchten also, dass der Inhalt des userPrincipalName SANs des Zertifikatantrages genommen wird, um Objekte vom Typ user mit dem gleichen Wert in dessen userPrincipalName Attribut zu finden.

Eine entsprechende Regel würde wie folgt aussehen. Da es sich hierbei aber um die Standardeinstellung handelt, kann sie auch entfallen.

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

Ebenfalls wissen wir, dass alle Intune-Benutzer Mitglieder einer bestimmten Sicherheitsgruppe sein müssen, um ein Zertifikat ausgestellt zu bekommen.

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

Außerdem möchten wir unter keinen Umständen, dass Mitglieder privilegierter Gruppen ein entsprechendes Zertifikat erhalten sollen.

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

Optional: SID-Zertifikaterweiterung

Wenn wir schon dabei sind, könnten wir auch gleich die Security Identifier Zertifikaterweiterung in das ausgestellte Zertifikat eintragen.

<SecurityIdentifierExtension>Add</SecurityIdentifierExtension>

Der alternative Ansatz des SID Uniform Resource Identifier (URI) wird von TameMyCerts ebenso unterstützt. Und generell ist es empfehlenswert, diese hochsensiblen Informationen nicht durch den Antragsteller beantragen zu lassen, sondern stattdessen durch die Zertifizierungsstelle mit TameMyCerts in die Zertifikat einzutragen. Dadurch ist sichergestellt, dass die zum verbundenen Konto zugehörige SID im Zertifikat landet.

Optional: Verwenden der Active Directory Attribute des gemappten Kontos, um den Zertifikatinhalt aufzuwerten

Die verwendbaren Attribute sind hier dokumentiert.

Auch könnten wir uns dazu entscheiden, den beantragten Zertifikatinhalt zu ändern. Beispielsweise könnten wir den Unternehmensnamen hinzufügen und den Abteilungsnamen aus den Eigenschaften des Benutzerkontos in den Subject Distinguished Name des ausgestellten Zertifikats schreiben.

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

Zusammenfassung

Weitere Beispiele liegen TameMyCerts bei. Die Beispiel-Konfigurationsdateien sind außerdem auf GitHub einsehbar.

Die komplette Richtliniendefinition sieht dann wie folgt aus:

<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>

Protokollierung und Alarmierung

Die von TameMyCerts protokollierten Ereignisse sind hier dokumentiert.

Lehnt die Zertifizierungsstelle durch TameMyCerts eine Zertifikatanforderung ab, wird dieses Ereignis auf der Zertifizierungsstelle protokolliert, und es kann eine entsprechende Alarmierung ausgelöst werden.

Funktionstest

Ich verwende zum testen das PSCertificateEnrollment PowerShell Modul. Die Art der Zertifikatbeantragung – also ob per MS-WCCE, per SCEP, und mit oder ohne Mobile Device Management – spielt für den Test keine Rolle, da die Prüfung des Zertifikatantrages direkt auf der Zertifizierungsstelle erfolgt und somit unabhängig von der Art der Beantragung ist.

Fall 1: Verstoß gegen definierten Zertifikatinhalt

Für den ersten Test beantragen wir ein Zertifikat, welches nur einen commonName beinhaltet.

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

Wie wir uns erinnern, erfordern unsere Syntaxregeln jedoch, dass auch eine emailAddress sowie ein userPrincipalName enthalten sind. Der Zertifikatantrag wird entsprechend abgelehnt und ein Ereignis protokolliert.

Fall 2: Syntaxregeln verhindern Ausstellung

Für den zweiten Test beantragen wir zwar alle definierten Felder, bauen uns aber einen Fehler in den userPrincipalName ein.

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"

Die Zertifikatanforderung wird entsprechend abgelehnt.

Fall 3: Mappen des beantragten Objektes schlägt fehl

Für den nächsten Test beantragen wir einen userPrincipalName, der nicht in der Domäne bekannt ist.

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"

Die Zertifikatanforderung wird entsprechend abgelehnt.

Wir korrigieren unseren Fehler, jedoch befindet sich unser gesuchter Benutzer nicht in der definierten Organisationseinheit.

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"

Unsere Zertifikatanforderung wird entsprechend abgelehnt.

Fall 4: Gruppenmitgliedschaften für das beantragte Objekt schlagen fehl

Nachdem wir unseren Testbenutzer Rudi nun in die korrekte Organisationseinheit verschieben, versuchen wir unser Glück erneut.

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"

Der Benutzer ist jedoch nicht Mitglied einer der definierten Gruppen – entsprechend wird der Zertifikatantrag wieder abgelehnt.

Okay, dann nehmen wir Rudi nun in die definierte "Intune Users" auf und versuchen es erneut.

Da der Benutzer jedoch Mitglied der verbotenen Gruppe der Domänen-Administratoren befindet, scheitern wir erneut.

Fall 5: Erfolgreiche Ausstellung

Wenn unser Benutzer Rudi nun endlich alle Voraussetzungen erfüllt, bekommen wir endlich unser Zertifikat ausgestellt.

Im Subject Distinguished Name sehen wir, dass das "department" Attribut aus dem verbundenen Active Directory Konto in das organizationalUnit Feld des Zertifikats übertragen wurde. Ebenso wurde der Firmenname in das organizationName Feld der Zertifikats eingetragen.

Die Security Identifier Zertifikaterweiterung findet sich ebenfalls im ausgestellten Zertifikat.

Fazit

Vertrauen ist gut, Kontrolle ist besser. TameMyCerts erlaubt PKI-Administratoren, die Kontrolle über ihre ausgestellten Zertifikate zurückzugewinnen und das Sicherheitsniveau der PKI erheblich zu steigern.

Aber Moment… da geht noch mehr

TameMyCerts kann noch deutlich mehr, und kann entsprechend bei einer Vielzahl von Anwendungsfällen einen deutlichen Mehrwert bieten. Hier ist ein Auszug dieser…