Certifried-Sicherheitslücke

Certifried ist eine Sicherheitslücke, die im Mai 2022 veröffentlicht wurde als CVE-2022-26921 und CVE-2022-26923. Oliver Lyak beschrieb eine Privilege-Escalation-Schwachstelle die er mithilfe der Zertifikatsauthentifizierung entdeckt hatte. Er beschreibt, dass ein Angreifer möglicherweise ein Zertifikat registrieren kann, das ihm die Authentifizierung als Computerkonto des Domain Controllers ermöglicht und dadurch eine AD-Domäne (und einen AAD-Tenant, falls verbunden) übernehmen kann. Microsoft begegnete den Schwachstellen mit einem Patch in KB5014754. Dieser Artikel beschreibt, wie sich dies auf Organisationen auswirkt, die SCEPman betreiben, und wie SCEPman dazu beitragen kann, das Sicherheitsproblem zu entschärfen.

Zusammenfassung für Führungskräfte

• SCEPman-Zertifikate können in den meisten Fällen nicht für Certifried-Angriffe verwendet werden

• Der Einsatz von SCEPman hilft, Certifried-Angriffe zu entschärfen, da SCEPman-CA-Zertifikate im Gegensatz zu Microsoft-CA-Zertifikaten normalerweise nicht im NTAuth-Store vorhanden sein müssen

• Der Patch von Microsoft wirkt sich in den meisten Fällen nicht auf SCEPman-Installationen aus. In diesen Fällen ist es eine gute Idee, den Full Enforcement-Modus zu aktivieren.

Folgen des Microsoft-Patches

Der Patch in KB5014754 fügt standardmäßig nur einige zusätzliche Audit-Ereignisse hinzu. Der Full Enforcement-Modus beginnt am 11. Februar 2025 — oder früher, wenn er manuell aktiviert wird. Im Full Enforcement-Modus können Zertifikate nur dann für Benutzer- und Geräteauthentifizierung verwendet werden, wenn sie entweder die SID eines Kontos enthalten oder, im Fall von Benutzerzertifikaten, wenn das AD-Objekt des Benutzers einen Verweis auf das konkrete Zertifikat enthält. Ersteres erfordert eine neue proprietäre X.509-Erweiterung, letzteres wird Certificate Mapping genannt und verwendet das Attribut altSecurityIdentities.

Im Allgemeinen betrifft dies nur AD-Authentifizierungen. Dafür muss das CA-Zertifikat dem NTAuth Store des Forests hinzugefügt werden. Standardmäßig wird SCEPman dem NTAuth Store nicht hinzugefügt, wenn Sie dies nicht ausdrücklich und manuell tun. Wenn Sie dies bisher noch nicht getan haben und es auch nicht vorhaben, hat der Patch keine Auswirkungen auf Ihre SCEPman-Instanz. Es gibt einen Anwendungsfall, bei dem die SCEPman-Dokumentation empfiehlt, das SCEPman-CA-Zertifikat dem NTAuth Store hinzuzufügen, nämlich wenn Sie SCEPman Domain-Controller-Zertifikate für die Kerberos-Authentifizierung ausstellen lassen.

Intune-Gerätezertifikate

Gerätezertifikate könnten für Windows Hello for Business Certificate Trustverwendbar sein. Wenn Sie die AD-DNS-Namen zu Gerätezertifikaten hinzugefügt haben, um sie für Certificate Trust zu verwenden, könnten Sie betroffen sein. Dafür ist ein Geräteobjekt sowohl in AAD als auch in AD erforderlich. Für diesen seltenen Anwendungsfall empfehlen wir den Wechsel zu WHfB Cloud Trust.

Intune-Benutzerzertifikate

Benutzerzertifikate können für Windows Hello for Business Certificate Trust verwendet werden. Sie könnten auch für andere Formen der zertifikatsbasierten AD-Authentifizierung verwendet werden, etwa RDP-Sitzungen zu Mitgliedsservern oder WiFi-Authentifizierung basierend auf NPS. Wenn Sie dies tun möchten, können Sie die Einstellung AppConfig:AddSidExtension verwenden, um SCEPman das Erstellen von Strong Certificate Mapping-Zertifikaten zu erlauben. Benutzerzertifikate für Benutzer, die zwischen AD und Entra ID synchronisiert sind, erhalten automatisch die Erweiterung mit der OID 1.3.6.1.4.1.311.25.2, um sie eindeutig AD-Benutzern zuzuordnen. Das Intune-Team plant außerdem einen SAN-Wert hinzuzufügen um das starke Zertifikats-Mapping zu implementieren. Sie können diese Methode auch als Alternative zur SID-Erweiterung verwenden.

DC-Zertifikate

Zertifikate für Domain Controller sind von der Schwachstelle nicht betroffen und daher im Allgemeinen auch nicht vom Patch betroffen. Es kann vorkommen, dass DC-Zertifikate für die Client-Authentifizierung verwendet werden, wofür sie zuvor zugelassen waren. Das funktioniert nach der Aktivierung von Full Enforcement nicht mehr. Achten Sie auf Audit-Ereignisse nach dem Patchen, um herauszufinden, ob dies Sie betreffen könnte. In den meisten Fällen sollte das kein Problem sein.

Angriffe mit SCEPman-Zertifikaten

Der Certifried-Angriff kann nur mit CA-Zertifikaten im NTAuth Store verwendet werden. Standardmäßig ist dies beim SCEPman-CA-Zertifikat nicht der Fall. Wenn Sie SCEPman also verwenden, um Zertifikate über Intune statt über Microsoft Active Directory Certificate Services auszustellen, besteht eine gute Chance, dass Ihre Umgebung gegen den Angriff immun ist. Wenn Ihr SCEPman jedoch Domain-Controller-Zertifikate ausstellt, befindet sich Ihr SCEPman-CA-Zertifikat im NTAuth Store und Sie sollten weiterlesen.

Ein Angreifer benötigt ein Zertifikat mit entweder einem gefälschten UPN in der Subject Alternative Name (SAN)-Erweiterung und der Extended Key Usage (EKU) Smart Card Logon oder einem gefälschten DNS-Namen im SAN und der EKU Client Authentication.

Intune-Benutzerzertifikate

Angenommen, ein Angreifer übernimmt ein AAD-Benutzerkonto, um SCEPman ein Benutzerzertifikat ausstellen zu lassen. Wie könnte der Angreifer SCEPman dazu bringen, ein für den Angriff nutzbares Zertifikat auszustellen?

Benutzerzertifikate enthalten normalerweise die EKU Client Authentication. Wenn Sie jedoch den Empfehlungen folgen, enthalten sie keinen DNS-Namen im SAN. Daher können diese Zertifikate nicht verwendet werden.

Wenn Sie die EKU Smart Card Logon konfiguriert haben, kann das Zertifikat für die Authentifizierung verwendet werden, jedoch nur für das Konto im UPN. Der UPN kommt aus AAD und wird überprüft, sodass der Angreifer keinen UPN eines Kontos in das Zertifikat einbringen kann, über das er nicht ohnehin verfügt. Wenn Sie außerdem Starke Zertifikatzuordnungverwenden, können Sie sicherstellen, dass Zertifikate nicht für ein anderes Konto funktionieren, wenn sich der UPN ändert.

Intune-Gerätezertifikate

Wenn Sie unseren grundlegenden Empfehlungen folgen, haben Gerätezertifikate die EKU Client Authentication. Ihr SAN enthält einen URI-Eintrag im SAN, der nicht für den Exploit verwendet werden kann. Sie können dem SAN jedoch zusätzlich einen DNS-Namen hinzufügen, zum Beispiel DeviceName.contoso.com. Wenn Sie das SCEPman-CA-Zertifikat ebenfalls in den NTAuth Store importiert haben, können diese Zertifikate für die lokale Authentifizierung als Gerät mit demselben DNS-Namen verwendet werden. Da Benutzer ihre Gerätenamen frei wählen können, könnten sie ihr Gerät "PrimaryDomainController" nennen und sich lokal als PrimaryDomainController.contoso.com authentifizieren, selbst wenn ein solcher Computer in AD bereits existiert. Dies ist übrigens nicht spezifisch für SCEPman und würde auch andere SCEP-Implementierungen wie NDES betreffen.

Daher sollten Sie keine DNS-Namenseinträge hinzufügen, die auf benutzerkontrollierten Daten wie dem Gerätenamen basieren, mit Domänennamen, die auch für lokale Domänen verwendet werden, wenn Sie dieselbe SCEPman-Instanz auch für DC-Zertifikate verwenden! Wenn Sie dies dennoch benötigen, müssen Sie den Full Enforcement-Modus aktivieren, um den Privilege-Escalation-Angriff zu verhindern. Sie könnten auch zwei separate SCEPman-Instanzen betreiben, eine für DC-Zertifikate und eine für die Intune-Registrierung.

Jamf Pro Benutzer- und Gerätezertifikate

Über Jamf Pro ausgestellte Zertifikate haben die EKU Client Authentication. Wenn Sie unserer Dokumentation folgen, wird kein Zertifikatstyp einen DNS-Namen im SAN haben. Daher sind diese Zertifikate für einen Certifried-Angriff unbrauchbar. Wenn Sie das SCEPman-CA in Ihrem AD NTAuthStore haben, zum Beispiel weil Sie DC-Zertifikate ausstellen, sollten Sie keine DNS-Namen zum SAN hinzufügen oder sicherstellen, dass Sie den Full Enforcement-Modus in Ihrer AD-Domäne aktivieren.

Certificate Master-Zertifikate

Es gibt mit Version 2.1 von SCEPman drei Möglichkeiten, Zertifikate über die Certificate Master-Komponente auszustellen.

TLS-Serverzertifikate sind nicht betroffen, da sie weder Smart Card Logon noch Client Authentication als EKU enthalten.

Manuelle Client-Zertifikate sind ebenfalls nicht betroffen. Sie enthalten die EKU Client Authentication, jedoch keinen DNS-SAN-Eintrag.

Benutzerdefinierte CSR-Anfragen sind frei konfigurierbar und umfassen Authentifizierungszertifikate. Da jeder, der Zugriff auf die Certificate Master-Anwendung hat, ein solches Zertifikat ausstellen kann, sollten Sie mindestens eine der folgenden Vorsichtsmaßnahmen treffen:

• Stellen Sie sicher, dass nur privilegierte Konten auf Certificate Master zugreifen können. Sie könnten zum Beispiel den Zugriff auf die Certificate Master-Komponente gewähren nur einer einzelnen AAD-Gruppe, die Sie als privilegierte Zugriffsgruppe.

• verwenden Sie separate SCEPman-Instanzen und CA-Zertifikate für DC-Zertifikate (deren CA-Zertifikat sich im NTAuth Store befindet) und Certificate Master.

• Aktivieren Sie den Full Enforcement-Modus in Ihrer AD-Domäne.

Domain-Controller-Zertifikate

Wenn ein Angreifer über die erforderlichen Zugriffsrechte verfügt, um Domain-Controller-Zertifikate auszustellen, hat dieser Angreifer wahrscheinlich bereits die Kontrolle über einen Domain Controller und besitzt die Domäne bereits. Der Angreifer benötigt den Certifried-Angriff nicht.