Angriffe auf Microsoft Zertifizierungsstellen können auf das Ausnutzen von Berechtigungen auf Zertifikatvorlagen abzielen. In vielen Fällen müssen Zertifikatvorlagen konfiguriert werden, dem Antragsteller das Recht einzuräumen, beliebige Identitäten beantragen zu können. Dies kann zur Übernehme der Identitäten von Active Directory Konten und in Folge zur Erhöhung von Rechten durch den Angreifer führen. Angriffe dieser Art werden in der Security Szene These als "ESC1" bezeichnet.
„Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) Angriffe gegen den ESC1 Angriffsvektor verhindern kann“ weiterlesenSchlagwort: Subject Alternative Name (SAN)
Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) Angriffe gegen die ESC6 und ESC7 Angriffsvektoren erkennen und verhindern kann
In der vermeintlich guten Absicht, damit die Ausstellung solcher Zertifikatanforderungen mit einem SAN möglich zu machen, raten leider viel zu viele Anleitungen dazu, auf der Zertifizierungsstelle das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 zu aktivieren.
Aktiviert man dieses Flag, wird eine sehr große Angriffsfläche geboten, da nun jeder Antragsteller die Zertifizierungsstelle anweisen kann, Zertifikate mit beliebigen Inhalten auszustellen. Diese Art von Agriffen ist in der Security-Szene als ESC6 und ESC7 bekannt.
„Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) Angriffe gegen die ESC6 und ESC7 Angriffsvektoren erkennen und verhindern kann“ weiterlesenWie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) dabei helfen kann, Szenarien mit Microsoft Intune und anderen Mobile Device Management (MDM) Systemen abzusichern
Unternehmen verwenden Mobile Device Management (MDM) Produkte um mobile Geräte wie Smartphones, Tablet-Computer oder Desktopsysteme über das Internet (Over-the-Air, OTA) zu verwalten, zu konfigurieren und zu aktualisieren.
Gängige Mobile Device Management Produkte sind:
- Microsoft Intune
- VMware Workspace One (previously known as AirWatch)
- Ivanti MobileIron UEM
- Jamf Pro
- Baramundi Enterprise Mobility Management
- BlackBerry Enterprise Mobility Suite
- Sophos Mobile Control
- SOTI MobiControl
Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) eingehende Zertifikatanträge reparieren kann, um sie RFC-konform zu machen
Beginnend mit Version 58 hat Google beschlossen, im Chrome Browser die Unterstützung für den Subject Distinguished Name von Webserver-Zertifikaten zu entfernen und stattdessen nur noch Zertifikate mit Subject Alternative Name zu akzeptieren.
Seit diesem Moment werden Webserver-Zertifikate ohne Subject Alternative Name in Form eines dNSName von Chrome abgelehnt. Andere Browserhersteller haben diesen Ansatz schnell übernommen, sodass dieses Problem mittlerweile alle gängigen Browser (auch Microsoft Edge) betrifft.
„Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) eingehende Zertifikatanträge reparieren kann, um sie RFC-konform zu machen“ weiterlesenDNS-Namen automatisch in den Subject Alternate Name (SAN) ausgestellter Zertifikate eintragen – mit dem TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services (ADCS)
Google ist mit dem Chromium Projekt und darauf basierenden Produkten wie Google Chrome und Microsoft Edge dazu übergegangen, das im Jahr 2000 verabschiedete RFC 2818 zu erzwingen und Zertifikaten nicht mehr zu vertrauen, welche dieses nicht mehr erfüllen.
Für uns ist folgender Satz von großer Brisanz:
„DNS-Namen automatisch in den Subject Alternate Name (SAN) ausgestellter Zertifikate eintragen – mit dem TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services (ADCS)“ weiterlesenIf a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead
https://tools.ietf.org/html/rfc2818
Den Subject Alternative Name (SAN) eines Zertifikats vor dessen Ausstellung verändern – aber sicher!
In Netz kursieren leider viel zu viele Anleitungen (auch die großen Player sind hiervon nicht ausgenommen, nicht einmal Microsoft selbst oder der Großmeister Komar), welche fatalerweise empfehlen, dass das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 auf der Zertifizierungsstelle gesetzt werden sollte – angeblich damit man in der Lage wäre, für manuell gestellte Zertifikatanforderungen Zertifikate mit Subject Alternative Name (SAN) Erweiterung ausstellen zu können.
Leider ist diese Vorgehensweise nicht nur unnötig, sie hat auch einige unangenehme Nebenwirkungen, welche einem Angreifer im schlechtesten Fall dazu verhelfen können, die gesamte Active Directory Gesamtstruktur zu übernehmen.
„Den Subject Alternative Name (SAN) eines Zertifikats vor dessen Ausstellung verändern – aber sicher!“ weiterlesenGrundlagen: Namenseinschränkungen (Name Constraints)
Namenseinschränkungen sind ein Teil des X.509 Standard und im RFC 5280 beschrieben. Sie sind ein Werkzeug, das im Rahmen der qualifizierten Subordinierung eingesetzt werden kann, um den Gültigkeitsbereich eines Zertifizierungsstellenzertifikats feingranular zu steuern.
„Grundlagen: Namenseinschränkungen (Name Constraints)“ weiterlesenVon Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann
Nachfolgend möchte ich eine der breiten Öffentlichkeit vielleicht nicht unbedingt bekannte hochgefährliche PKI-Konfiguration vorstellen, die so in Unternehmensnetzwerken wahrscheinlich recht häufig angetroffen werden kann.
Ich zeige auf, wie durch Ausnutzung verschiedener unglücklicher Umstände in der Windows-PKI eine Erhöhung von Rechten, ausgehend von bloßem Netzwerkzugang bis hin zur vollständigen Übernahme des Active Directory möglich ist.
Der initiale Angriffspunkt ist in diesem Beispiel der Registrierungsdienst für Netzwerkgeräte (NDES).
„Von Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann“ weiterlesenGrundlagen: Konfigurationsdatei für die Zertifizierungsstelle (capolicy.inf)
Die capolicy.inf beinhaltet grundlegende Einstellungen, die vor der Installation einer Zertifizierungsstelle festgelegt werden können oder sollten. Vereinfacht ausgedrückt kann man sagen, dass keine Zertifizierungsstelle ohne sie installiert werden sollte.
„Grundlagen: Konfigurationsdatei für die Zertifizierungsstelle (capolicy.inf)“ weiterlesenSignieren von Zertifikaten unter Umgehung der Zertifizierungsstelle
Immer wieder kommt in Diskussionen zur Sicherheit einer Zertifizierungsstelle auf, dass ein Missbrauch der Zertifizierungsstelle durch deren Sicherheitseinstellungen eingedämmt werden könnte.
Dass die Integrität einer Zertifizierungsstelle jedoch unmittelbar an ihr Schlüsselmaterial gebunden ist und sie somit durch dieses auch kompromittiert werden kann, ist auf den Ersten Blick nicht offensichtlich.
Muss man sich die Zertifizierungsstellen-Software als eine Art Management um das Schlüsselmaterial herum vorstellen. Die Software bietet beispielsweise eine Online-Schnittstelle für die Zertifikatbeantragung an, kümmert sich um die Authentifizierung der Antragsteller, um die automatisierte Durchführung von Signaturoperationen (Ausstellen von Zertifikaten und Sperrlisten) und deren Protokollierung (Zertifizierungsstellen-Datenbank, Auditprotokoll, Ereignisprotokoll).
Signaturoperationen benötigen jedoch nichts weiter als den privaten Schlüssel der Zertifizierungsstelle. Nachfolgend wird anhand eines Beispiels aufgezeigt, wie ein Angreifer, wenn er Zugang zum privaten Schlüssel der Zertifizierungsstelle erhält, Zertifikate erzeugen und ausstellen kann, ohne dass die Zertifizierungsstellen-Software und deren Sicherheitsmechanismen dies mitbekommen würden.
Mit einem solchen Zertifikat wäre es im schlechtesten Fall sogar möglich, die Active Directory Gesamtstruktur unerkannt zu übernehmen.
„Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle“ weiterlesenZertifikatbeantragung für Windows-Systeme über den Registrierungsdienst für Netzwerkgeräte (NDES) mit Windows PowerShell
Möchte man Windows-Systeme mit Zertifikaten ausrüsten, welche nicht die Möglichkeit haben, direkt mit einer Active Directory integrierten Zertifizierungsstelle zu kommunizieren, oder die sich gar überhaupt nicht in der gleichen Active Directory Gesamtstruktur befinden, bleibt in den meisten Fällen nur die manuelle Installation von Zertifikaten.
Seit Windows 8.1 / Windows Server 2012 R2 befindet sich jedoch ein integrierter Client für das Simple Certificate Enrollment Protocoll (SCEP) an Bord. Serverseitig wird SCEP über den Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) in der Microsoft-PKI seit Windows Server 2003 implementiert.
Eine besonders interessante Eigenschaft von SCEP ist, dass das Protokoll eine Erneuerung eines Zertifikats unter Angabe eines bereits vorhandenen erlaubt. Was läge also näher, als diese Schnittstelle zu verwenden? Was noch fehlt, ist eine entsprechende Automatisierung über die Windows PowerShell.
„Zertifikatbeantragung für Windows-Systeme über den Registrierungsdienst für Netzwerkgeräte (NDES) mit Windows PowerShell“ weiterlesenDetails zum Ereignis mit ID 30 der Quelle Microsoft-Windows-NetworkDeviceEnrollmentService
| Ereignisquelle: | Microsoft-Windows-NetworkDeviceEnrollmentService |
| Ereignis-ID: | 30 (0x1E) |
| Ereignisprotokoll: | Application |
| Ereignistyp: | Fehler |
| Symbolischer Name: | EVENT_MSCEP_FAIL_ADD_ALT |
| Ereignistext (englisch): | The Network Device Enrollment Service cannot add an alternative subject name extension to the certificate request (%1). %2 |
| Ereignistext (deutsch): | Der Zertifikatanforderung kann vom Registrierungsdienst für Netzwerkgeräte keine Erweiterung für einen alternativen Antragstellernamen hingezufügt werden (%1). %2 |
Details zum Ereignis mit ID 21 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center
| Ereignisquelle: | Microsoft-Windows-Kerberos-Key-Distribution-Center |
| Ereignis-ID: | 21 (0x80000015) |
| Ereignisprotokoll: | System |
| Ereignistyp: | Warnung |
| Ereignistext (englisch): | The client certificate for the user %1\%2 is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they’re attempting to use for smartcard logon. The chain status was : %3 |
| Ereignistext (deutsch): | Das Clientzertifikat für den Benutzer %1\%2 ist nicht gültig. Das Ergebnis war ein Fehler bei der Smartcard-Anmeldung. Wenden Sie sich an den Benutzer, um weitere Informationen über das Zertifikat zu erhalten, das für die Smartcard-Anwendung verwendet werden soll. Kettenstatus: %3 |
Konfigurieren einer Zertifikatvorlage für Domänencontroller
Auch bei einer vermeintlich simpel zu konfigurierenden Zertifikatvorlage für Domänencontroller gibt es einiges zu beachten.
„Konfigurieren einer Zertifikatvorlage für Domänencontroller“ weiterlesenDen Network Device Enrollment Service (NDES) für die Verwendung mit einem Alias konfigurieren
Nachfolgend wird beschrieben, welche Schritte erforderlich sind, um den Registrierungs dienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) für die Verwendung mit einem Alias zu konfigurieren.
Mit dem Begriff Alias ist gemeint, dass der Dienst nicht mit dem Namen des Servers, auf welchem er installiert ist, aufgerufen wird, sondern mit einem hierbon unabhängigen, generischen Namen. Die Verwendung eines Alias ermöglicht, dass der Dienst zu einem späteren Zeitpunkt auf ein anderes System umgezogen werden kann, ohne dass die neue Adresse allen Teilnehmern mitgeteilt werden muss.
„Den Network Device Enrollment Service (NDES) für die Verwendung mit einem Alias konfigurieren“ weiterlesen
Deutsch 
English