Zertifizierungsstelle – Uwe Gradenegger

Wie das Absichern von Druckern zum Security-Desaster werden kann – und wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) diese verhindern kann

In der heutigen Zeit ist es unumgänglich, die Authentisierung von Geräten am Unternehmens-Netzwerk sowie administrative Schnittstellen zu schützen. In der Regel kommen hierbei auf digitale Zertifikate zum Einsatz.

Auch Drucker benötigen somit in der Regel digitale Zertifikate, um sicher betrieben werden zu können. Ab einer gewissen Anzahl von Geräten kommt man um eine automatische Zertifikatverteilung nicht mehr herum.

Manche Drucker-Hersteller bieten für die Zertifikatverteilung zentrale Management-Lösungen an.

Leider zeigt sich immer wieder, dass der sichere Umgang digitalen Zertifikaten viel Wissen, Erfahrung und Sorgfalt erfordert, was leider oft nicht gegeben ist.

Neue Sicherheitslücke ESC15 in Active Directory Certificate Services entdeckt – einfach umzusetzende Gegenmaßnahmen

Für welche Zwecke ein digitales Zertifikat verwendet werden darf, wird über die Zertifikaterweiterungen "Key Usage" und "Extended Key Usage" gesteuert. In der "Extended Key Usage" Zertifikaterweiterung werden die erweiterten Schlüsselverwendungen eingetragen, für welche das Zertifikat verwendet werden darf.

Es gibt jedoch bei von einer Microsoft Zertifizierungsstelle ausgestellten Zertifikaten noch eine weitere Zertifikaterweiterung namens "Anwendungsrichtlinien" (engl. "Application Policies"), die ebenfalls eine der Extended Key Usages Erweiterung sehr ähnliche Liste enthält.

Justin Bollinger von TrustedSec hat herausgefunden, dass es bei Offline-Zertifikatanforderungen gegen Zertifikatvorlagen der Schema-Version 1 möglich ist (ähnlich wie bei der Security Identifier Erweiterung), beliebige Application Policies im Zertifikatantrag mitzusenden, welche unverändert in das ausgestellte Zertifikat übernommen werden und anschließend für einen Angriff auf die Active Directory Gesamtstruktur verwendet werden können. Der Angriff wurde auf den Namen ESC15 getauft.

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 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 Angriffen 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 (zuvor bekannt unter dem Markennamen 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 Google Chrome und anderen Chromium-basierten Browsern (also auch Microsoft Edge) abgelehnt. Andere Browserhersteller haben diesen Ansatz schnell übernommen, sodass dieses Problem mittlerweile alle gängigen Browser 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.

Deutsch