Certifried-Sicherheitslücke

Certifried ist eine Sicherheitslücke, die im Mai 2022 als CVE-2022-26921 und CVE-2022-26923. Oliver Lyak beschrieb eine Privilegieneskalations-Schwachstelle die er unter Verwendung von Zertifikatsauthentifizierung entdeckt hatte. Er beschreibt, dass ein Angreifer ein Zertifikat ausstellen lassen könnte, das ihm erlaubt, sich als Computer-Konto des Domänencontrollers zu authentifizieren und damit eine AD-Domäne zu übernehmen (und einen AAD-Mandanten, falls verbunden). Microsoft hat die Schwachstellen mit einem Patch in KB5014754. Dieser Artikel beschreibt, wie sich dies auf Organisationen auswirkt, die SCEPman betreiben, und wie SCEPman helfen kann, das Sicherheitsproblem zu mildern.

Zusammenfassung für Führungskräfte

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

• Die Verwendung von SCEPman hilft, Certifried-Angriffe zu mildern, weil SCEPman-CA-Zertifikate im Gegensatz zu Microsoft-CA-Zertifikaten in der Regel nicht im NTAuth-Store sein müssen

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

Folgen von Microsofts Patch

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 eine Referenz auf das spezifische Zertifikat enthält. Erstere erfordert eine neue proprietäre X.509-Erweiterung, letztere wird als Certificate Mapping bezeichnet und verwendet das Attribut altSecurityIdentities.

Allgemein gesprochen wirkt sich dies nur auf AD-Authentifizierungen aus. Es erfordert das Hinzufügen des CA-Zertifikats in den NTAuth-Store der Gesamtstruktur. Standardmäßig wird SCEPman nicht in den NTAuth-Store aufgenommen, sofern Sie dies nicht explizit und manuell tun. Wenn Sie das noch nicht getan haben und nicht planen, es zu tun, hat der Patch keine Auswirkung auf Ihre SCEPman-Instanz. Es gibt einen Anwendungsfall, bei dem die SCEPman-Dokumentation empfiehlt, das SCEPman-CA-Zertifikat in den NTAuth-Store aufzunehmen, nämlich wenn Sie SCEPman Domain Controller-Zertifikate für die Kerberos-Authentifizierung ausstellen lassen wollen.

Intune-Gerätezertifikate

Gerätezertifikate könnten für Windows Hello for Business Certificate Trustverwendbar sein. Wenn Sie den AD-DNS-Namen zu Gerätezertifikaten hinzugefügt haben, um diese für Certificate Trust zu verwenden, könnten Sie betroffen sein. Dies erfordert ein Geräteobjekt sowohl in AAD als auch in AD. 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 zertifikatbasierten AD-Authentifizierung verwendet werden, wie RDP-Sitzungen zu Domänen-verbundenen Rechnern oder WLAN-Authentifizierung basierend auf NPS. Wenn Sie dies tun möchten, können Sie die Einstellung AppConfig:AddSidExtension verwenden, um SCEPman zu erlauben, Strong Certificate Mapping-Zertifikate zu erstellen. Benutzerzertifikate für zwischen AD und Entra ID synchronisierte Benutzer erhalten automatisch die Erweiterung mit der OID 1.3.6.1.4.1.311.25.2, um sie stark an AD-Benutzer zuzuordnen. Das Intune-Team plant, einen SAN-Wert hinzuzufügen um das starke Certificate Mapping zu implementieren. Sie können diese Methode auch als Alternative zur SID-Erweiterung verwenden.

DC-Zertifikate

Domain Controller-Zertifikate sind von der Schwachstelle nicht betroffen und daher grundsätzlich auch nicht vom Patch betroffen. Es kann vorkommen, dass DC-Zertifikate für Client-Authentifizierung verwendet werden, wofür sie zuvor erlaubt waren. Dies wird nicht mehr funktionieren, sobald Full Enforcement aktiviert ist. Suchen Sie nach Audit-Ereignissen nach dem Patchen, um herauszufinden, ob Sie betroffen sein könnten. In den meisten Fällen sollte dies kein Problem sein.

Angriffe mit SCEPman-Zertifikaten

Der Certifried-Angriff kann nur mit CA-Zertifikaten im NTAuth-Store durchgeführt werden. Standardmäßig ist dies beim SCEPman-CA-Zertifikat nicht der Fall. Wenn Sie also SCEPman verwenden, um Zertifikate über Intune anstelle von Microsoft Active Directory Certificate Services auszustellen, ist Ihre Umgebung wahrscheinlich immun gegen den Angriff. Wenn Ihr SCEPman jedoch Domain Controller-Zertifikate ausstellt, befindet sich Ihr SCEPman-CA-Zertifikat im NTAuth-Store und Sie sollten weiter lesen.

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

Intune-Benutzerzertifikate

Angenommen, ein Angreifer übernimmt ein AAD-Benutzerkonto, damit SCEPman ein Benutzerzertifikat ausstellt. Wie könnte der Angreifer SCEPman dazu bringen, ein für den Angriff verwendbares Zertifikat auszustellen?

Benutzerzertifikate enthalten normalerweise das 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 das EKU Smart Card Logon konfiguriert haben, kann das Zertifikat für die Authentifizierung verwendet werden, aber nur für das Konto im UPN. Der UPN stammt aus AAD und wird verifiziert, sodass der Angreifer keinen UPN eines Kontos in das Zertifikat bringen kann, das der Angreifer nicht ohnehin kontrolliert. Wenn Sie zusätzlich starke Zertifikatzuordnungverwenden, können Sie sicherstellen, dass Zertifikate nicht für ein anderes Konto funktionieren, falls sich der UPN ändert.

Intune-Gerätezertifikate

Nach unseren grundlegenden Empfehlungen enthalten Gerätezertifikate das EKU Client Authentication. Ihr SAN enthält einen URI-Eintrag, der für den Exploit nicht verwendbar ist. Sie können jedoch zusätzlich einen DNS-Namen zum SAN hinzufügen, z. B. DeviceName.contoso.com. Wenn Sie außerdem das SCEPman-CA-Zertifikat in den NTAuth-Store importiert haben, können diese Zertifikate verwendet werden, um sich lokal als Gerät mit demselben DNS-Namen zu authentifizieren. 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 bereits im AD existiert. Das ist übrigens nicht SCEPman-spezifisch und würde andere SCEP-Implementierungen wie NDES ebenso betreffen.

Daher sollten Sie keine DNS-Namen-Einträge basierend auf benutzerkontrollierten Daten wie dem Gerätenamen mit Domänennamen hinzufügen, 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 Eskalationsangriff zu verhindern. Sie könnten auch zwei separate SCEPman-Instanzen betreiben, eine für DC-Zertifikate und eine für Intune-Enrollment.

Jamf Pro Benutzer- und Gerätezertifikate

Zertifikate, die über Jamf Pro ausgestellt werden, haben das EKU Client Authentication. Wenn Sie unserer Dokumentation folgen, wird keine Art von Zertifikat 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 in das SAN hinzufügen oder sicherstellen, dass Sie den Full Enforcement-Modus in Ihrer AD-Domäne aktivieren.

Certificate Master-Zertifikate

Ab SCEPman Version 2.1 gibt es 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 das EKU Client Authentication, aber keinen DNS-SAN-Eintrag.

Benutzerdefinierte CSR-Anfragen sind frei konfigurierbar und können Authentifizierungszertifikate einschließen. Da jeder, der Zugriff auf die Certificate Master-Anwendung hat, ein solches Zertifikat ausstellen könnte, 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 Zugriffgruppe.

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

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

Domänencontroller-Zertifikate

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