Zertifizierungsstelle – Uwe Gradenegger

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) Angriffe gegen den ESC1 Angriffsvektor verhindern kann

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 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) 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) beim Etablieren digitaler Signaturprozesse im Unternehmen helfen kann

Viele Unternehmen möchten heutzutage auf papierlose Prozesse setzen, um interne Genehmigungs- und Signaturprozesse zu beschleunigen. In Zeiten, in denen die meisten Mitarbeiter von Zuhause aus arbeiten hat dies noch einmal zusätzlich an Bedeutung gewonnen.

Obwohl die Microsoft Zertifizierungsstelle in der Lage ist, automatische Zertifikatausstellungsprozesse umzusetzen, sind ihre Möglichkeiten, hierbei Einfluss auf den Zertifikatinhalt zu nehmen stark limitiert.

Das TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services (AD CS) erlaubt das Definieren erweiterter Regeln für den Subject Distinguished Name und auch den Subject Alternative Name ausgestellter Zertifikate.

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.

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)

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:

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

Grundlagen: Deltasperrlisten

Um ausgestellte Zertifikate vor Ende ihrer Gültigkeitsdauer aus dem Verkehr ziehen zu können, werden Zertifikatsperrlisten (engl. "Certificate Revocation List", CRL) eingesetzt.

Hierbei handelt es sich um eine signierte Liste der Seriennummern von Zertifikaten, die von der Zertifizierungsstelle widerrufen wurden. Die Sperrliste hat ein (in der Regel wenige Tage kurzes) Ablaufdatum und wird von der zugehörigen Zertifizierungsstelle in regelmäßigen Abständen neu ausgestellt und signiert.

Zertifikatsperrlisten können bei einem hohen Volumen widerrufener Zertifikate eine beträchtliche Größe erreichen (als Faustregel kann man mit ca. 5 Megabyte pro 100.000 Einträgen rechnen). Der regelmäßige Download großer Zertifikatsperrlisten durch die Teilnehmer kann eine große Netzwerklast erzeugen. Um dieses Problem zu adressieren gibt es das Konzept der Deltasperrlisten.

Rückbau einer Active Directory integrierten Zertifizierungsstelle (Enterprise CA)

Anleitungen für den Aufbau und die Inbetriebnahme von IT-Diensten gibt es sehr viele. Meistens wird jedoch die dazugehörige Anleitung für die Außerbetriebnahme vergessen.

Nachfolgend wird beschrieben wie eine ins Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) korrekt außer Betrieb genommen wird.

Nachträgliche Archivierung privater Schlüssel

Für die Veschlüsselung von E-Mail Nachrichten verwenden Unternehmen üblicherweise den Secure / Multipurpose Internet Message Extensions (S/MIME) Standard und stellen ihren Benutzern hierfür entsprechende Zertifikate zur Verfügung.

Ein wichtiger Aspekt hierbei ist, dass die privaten Schlüssel der Benutzer – im Gegensatz zu den ansonsten meist verwendeten Signaturzertifikaten – zentral gesichert werden sollten. Eingehende Nachrichten sind für einen bestimmten privaten Schlüssel verschlüsselt und können nur von diesem auch wieder entschlüsselt werden. Somit muss unbedingt eine Sicherung dieser Schlüssel vorliegen – auch für die Synchronisierung auf mobile Endgeräte ist dies unabdingbar. Hierfür bieten die Microsoft Active Directory Certificate Services die Funktion der Archivierung privater Schlüssel (engl. Private Key Archival).

Was aber, wenn die Archivierung der privaten Schlüssel nicht eingerichtet wurde, und Benutzer bereits entsprechende Zertifikate beantragt haben?

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln

Im Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle" habe ich beschrieben, wie sich ein Angreifer, der im Besitz administrativer Rechte auf der Zertifizierungsstelle ist, unter Umgehung der Zertifizierungsstellen-Software, also unter direkter Verwendung des privaten Schlüssels der Zertifizierungsstelle, ein Anmeldezertifikat für administrative Konten der Domäne erzeugen kann.

Im vorigen Artikel habe ich das PSCertificateEnrollment Powershell Modul verwendet, um das Vorgehen zu demonstrieren. Microsoft liefert mit certreq und certutil allerdings bereits ab Werk perfekt geeignete Pentesting-Werkzeuge direkt mit dem Betriebssystem mit.

Die Installation eines neuen Zertifizierungsstellen-Zertifikats schlägt fehl mit Fehlercode "ERROR_INVALID_PARAMETER"

Folgendes Szenario angenommen:

Für eine untergeordnete Zertifizierungsstelle wird ein neues Zertifizierungsstellen-Zertifikat beantragt und von der übergeordneten Zertifizierungsstelle ausgestellt.
Der Subject Distinguished Name (Subject DN) ist identisch zu dem des vorigen Zertifizierungsstellen-Zertifikats.
Dennoch schlägt die Installation des Zertifizierungsstellen-Zertifikats mit folgender Fehlermeldung fehl:

An error was detected while configuring Active Directory Certificate Services.
The Active Directory Certificate Services Setup Wizard will need to be rerun to complete the configuration.
The new certificate subject name does not exactly match the active CA name.
Renew with a new key to allow minor subject name changes: The parameter is incorrect. 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER).

Zeichenkodierung im Subject Distinguished Name von Zertifikatanforderungen und ausgestellten Zertifikaten

Üblicherweise ist die Kodierung von Zeichen und Zeichenketten in Zertifikaten kein Thema, welches die Nutzer einer PKI groß interessiert. Es gibt jedoch Fälle, in welchen die Standardeinstellungen der Zertifizierungsstelle nicht die gewünschten Ergebnisse liefern.

Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für Microsoft Active Directory Certificate Services

Als Betreiber einer Zertifizierungsstelle ist man (unter Anderem) für die Identifikation der Antragsteller und die Bestätigung der beantragten Identitäten verantwortlich. Dass diese Aufgabe gewissenhaft und fehlerfrei ausgeführt wird, ist der zentrale Grundpfeiler für das Vertrauen, dass der Zertifizierungsstelle eingeräumt wird. Namhafte Firmen sind bereits an dieser Aufgabe gescheitert, mussten in Folge von Falschausstellungen sogar Insolvenz anmelden und/oder wurden durch die großen Player am Markt empfindlich bestraft.

In vielen Fällen sind wir als (Microsoft-)PKI-Betreiber in Unternehmen (ungeachtet der damit einhergehenden Qualität) in der Lage, unsere Aufgabe der eindeutigen Identifikation eines Antragstellers an das Active Directory zu delegieren. In vielen Fällen müssen wir unsere Zertifizierungsstelle(n) aber auch anweisen, einfach alles auszustellen, was beantragt wird.

Die Partition des Hardware Security Moduls (HSM) läuft voll

Folgendes Szenario angenommen:

Eine Zertifizierungsstelle verwendet ein Hardware Security Modul (HSM).
Die Partition des Hardware Security Moduls füllt sich über die Lebenszeit der Zertifizierungsstelle mit immer mehr Schlüsseln.
Bei SafeNet Hardware Security Modulen kann dies sogar dazu führen, dass die Partition voll läuft. In Folge dessen werden die Ereignisse 86 und 88 der Zertifizierungsstelle protokolliert.

Deutsch