PSPKI Audit – Wieso man seine PKI analysieren sollte
5931
post-template-default,single,single-post,postid-5931,single-format-standard,bridge-core-3.0.1,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-28.7,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-6.9.0,vc_responsive

PSPKI Audit – Wieso man seine PKI analysieren sollte

Nachdem unsere letzten Blogartikel eher allgemeine Infrastruktur-Themen (Benutzeranlage, Server Deployment) behandelten, möchten wir uns dieses Mal wieder verstärkt einem Sicherheitsthema widmen. In nahezu jeder IT-Infrastruktur befindet sich eine Zertifizierungsstelle, die Zertifikate z.B. für SSL, Code Signing oder SmartCard Anmeldungen ausstellt. Viele unserer Kunden setzen eine Microsoft-basierte Certification Authority (CA) bzw. Public Key Infrastructure (PKI) ein. CA-Dienste sind schnell installiert und in wenigen Schritten hat man die CA so konfiguriert, dass sie bereits Zertifikate ausstellen kann. Aber – Hand aufs Herz – wer versteht eine PKI Hierarchie und die gesamten Konfigurationen wirklich vollständig und würde sich als Experte bezeichnen? Unsere Erfahrung ist vielmehr, dass PKI-Strukturen fast überall vorhanden sind, aber sehr stiefmütterlich behandelt werden und oftmals veraltete oder fehlerhafte Konfigurationen enthalten.

Wir möchten in diesem Artikel potenzielle Angriffspfade, ausgehend von CA Diensten, beschreiben und vor allem darauf eingehen, wie man diese Schwachstellen erkennt und beseitigt.

Die Grundlage bietet das herausragende Whitepaper von SpecterOps, das hier verlinkt und beschrieben ist: https://posts.specterops.io/certified-pre-owned-d95910965cd2

Hintergrund

Bereits im Juni 2021 veröffentlichte Will Schroeder einen Post mit dem Namen  Certified Pre-Owned, in dem er beschreibt, dass er in den letzten Monaten intensiv in die Welt der PKIs eingetaucht ist und einige Schwachstellen gefunden hat. Im Wesentlichen sind drei Komponenten für uns wichtig:

An dieser Stelle möchten wir nur kurz auf die gefunden Schwachstellen eingehen. Würden wir diese ausführlich dokumentieren, könnten wir wahrscheinlich pro Schwachstelle einen eigenen Blogartikel schreiben. Zudem gibt es, wie oben bereits erwähnt, mit dem Blog von Will Schroeder und dem Whitepaper bereits ausführliche Informationen, die wirklich sehr in die Tiefe gehen. Dennoch ist es wichtig zu verstehen, wie ein potenzieller Angriff funktioniert.

Fangen wir zunächst mit der Bedrohungslage an. Mit den gefundenen Schwachstellen ist es möglich, sich als jeder beliebige Benutzer oder als jedes beliebige System in einer Active Directory Domäne auszugeben! Das schließt also auch hoch privilegierte Konten wie Domain Admins oder ähnliches mit ein. Wir haben es hier also, ähnlich wie bei Pass-the-Hash oder Pass-the-Ticket Angriffen, mit einer sehr ernsten Bedrohungslage zu tun. Kurz gesagt, kann sich ein Angreifer ein beliebiges Zertifikat ausstellen und sich z.B. als Domain Admin ausgeben. Ist man es bisher gewohnt gewesen, bei einem Verdacht z.B. sein Kennwort zu ändern, ist bei diesem Angriff das Passwort des Nutzers vollkommen egal. Wir benötigen nur ein gültiges Zertifikat und unabhängig davon, ob der Benutzer sein Kennwort bereits geändert hat, können wir uns mittels Zertifikat authentifizieren.

Damit ein Angriff ausgeführt werden kann, müssen allerdings einige Voraussetzungen erfüllt sein. Man ist jedoch überrascht, wie oft man Kundenumgebungen findet, in denen die Voraussetzungen erfüllt sind.

Nicht jedes Zertifikatstemplate ist für unsere Zwecke geeignet. Es muss eines der folgenden Verwendungszwecke enthalten:

    • Client Authentication
    • PKINIT Client Authentication
    • Smart Card Logon
    • Any Purpose
    • SubCA

 

Für einige Angriffspfade wird zudem ein Subject Alternative Name benötigt. Ob dieser erlaubt ist, ist ebenfalls im Zertifikatstemplate eingestellt. Allerdings kann man diese Einstellung auch „zentral“ konfigurieren und somit für alle Templates vorgeben. Dazu später mehr.

Abschließend benötigt mein Benutzer oder System natürlich auch noch Enrollment-Berechtigungen auf das entsprechende Template. Das liest sich erst einmal als hohe Hürde, aber in vielen Umgebungen ist es durchaus üblich, nahezu jedem Benutzer E-Mail oder Smart Card Zertifikate auszurollen. Oder man denke an den Applikationsverantwortlichen, der ggf. ein Web Server Zertifikat für seine Applikation benötigt.

Neben einem Angriff über Zertifikatstemplates, beschreibt SpecterOps ebenso Angriffspfade, in denen Teile oder die gesamte CA übernommen werden können. Wenn ich die CA verwalten kann, könnte ich mir eben auch ein entsprechendes Template generieren und einen Angriff durchführen.

Wie bereits erwähnt, möchten wir jedoch nicht zu tief in die einzelnen Angriffe eintauchen. Wer sich dafür interessiert, kann sich detailliert mit dem Whitepaper auseinandersetzen. Wir möchten den Fokus eher auf das Verhindern dieser Angriffswege legen und führen an dieser Stelle nur die einzelnen Pfade mit einer kurzen Beschreibung auf. Übrigens, die Bezeichnungen ESC<Nummer> sind aus dem Blog bzw. dem Whitepaper der SpecterOps. Ihr könnt also gezielt nach diesen suchen, solltet ihr weitere Informationen benötigen.

Aus unserer Sicht kann man die Bedrohung so zusammenfassen, dass ein Angreifer über Fehlkonfigurationen Kontrolle über Templates oder CA Einstellungen erhält und sich damit Zertifikate ausstellen kann, die für weitere Angriffe genutzt werden können. Bedenkt man, dass Zertifikate auch ihre Gültigkeit behalten, wenn ein Account sein Passwort ändert, ist das ein spannender und effektiver Weg für einen Angreifer, sich in einem Unternehmen auszubreiten und seine Rechte kontinuierlich zu erweitern.

Mit der bisherigen Beschreibung möchten wir ein grundlegendes Verständnis über die verschiedenen Angriffsmöglichkeiten sicherstellen. Solltet ihr nicht jeden Angriff verstehen, ist das unserer Meinung nach nicht weiter schlimm. Wer möchte, kann das viel zitierte Whitepaper lesen und knietief in die Materie einsteigen. Viel wichtiger ist jedoch, dass wir anerkennen, dass es hier ein To-Do gibt und die eigene PKI Struktur dringend überprüft werden sollte.

Die gute Nachricht ist, es gibt bereits Werkzeuge, die einem die Analyse vereinfachen. Auf diese wollen wir im nächsten Abschnitt genauer eingehen.

Wie kann ich meine PKI überprüfen?

Wir werden nun also die CA prüfen und auf die Ergebnisse eingehen. Doch mit welchem Tool macht man das eigentlich?

Specter Ops veröffentlichte zusammen mit dem Whitepaper  ein Toolkit, mit dem alle beschriebenen Angriffswege (ESC1-8) geprüft werden können. Das Toolkit basiert auf dem Projekt PSPKI und nennt sich PSPKIAudit. Das Tool ist recht schnell erklärt, es gibt zwei Module, die für uns interessant sind.

      1. Invoke-PKIAudit – Audits the current Forest’s AD CS settings, primarily analyzing the CA server and published templates for potential privilege escalation opportunities.
      2. Get-CertRequest – Examines a CA’s issued certificates by querying the CA’s database. Primary intention is to discover certificate requests that may have abused a certificate template privilege escalation vulnerability. In addition, if a user or computer is compromised, incident responders can use it to find certificates the CA server had issued to the compromised user/computer (which should then be revoked).

Mit Invoke-PKIAudit kann man also die aktuelle CA Konfiguration und die vorhandenen Zertifikatstemplates auf die Angriffswege ESC1-8 prüfen. Get-CertRequest prüft wiederum alle Zertifikate, die von der CA ausgestellt wurden. Hier ist allerdings etwas Aufwand bei der Analyse einzuplanen, dazu aber gleich mehr.

Schauen wir uns zunächst einmal an, was Invoke-PKIAudit für Findings anzeigt. Die Screenshots sind aus einer Testumgebung. In der Realität kann der Output wesentlich größer sein. Das ist abhängig von der Anzahl an Zertifikatstemplates in der Umgebung.

Zunächst wird die CA Konfiguration überprüft und in unserem Beispiel sehen wir, dass unsere CA Konfiguration für die Angriffswege ESC6 und ESC8 offen ist.

ESC6 beschreibt einen Angriff über das CA Flag „EDITF_ATTRIBUTESUBJECTALTNAME2”. Wie oben bereits kurz erklärt, ermöglicht dieses Flag, dass ein Angreifer bei jedem beliebigen Zertifikatsrequest einen Subject Alternate Name angeben kann. Ob dies im Template erlaubt ist oder nicht, spielt hier keine Rolle, da die CA Konfiguration dies bereits erlaubt. Wie immer ist es extrem von den lokalen Gegebenheiten abhängig, wie man mit diesem Umstand nun umgeht. Sicher ist nur, es sollte nicht so bleiben. In unseren Kundeneinsätzen führen wir viele Gespräche mit unseren Kunden und versuchen zunächst die Gesamtlage zu überblicken, bevor wir eine finale Entscheidung treffen und das Problem aus der Welt schaffen. Wir sehen keinen wichtigen Grund, dieses Flag bei einer CA zu konfigurieren. Wenn ich SANs für gewisse Zertifikate zwingend benötige, kann ich das auch im betreffenden Zertifikatstemplate konfigurieren. Alternativ, oder auch ergänzend, hilft dies bei eigentlich allen Angriffen auch die Manager Approval Konfiguration. Das bedeutet, dass Zertifikate erst ausgestellt werden, wenn ein CA Manager den Request angesehen und explizit erlaubt hat. Das ist je nachdem, wie viele Zertifikate solch eine CA ausstellt, ein gewisser Aufwand, aber sicher einer der besten Hebel, die wir zur Verfügung haben.

Im nachfolgenden Screenshot sehen wir übrigens auch, dass ein Template, welches keinen SAN erlaubt, trotzdem verwundbar ist:

Misconfiguration ist in diesem Fall leer, aber ganz oben im Bild wird auf das Flag hingewiesen und auf eine potentielle Verwundbarkeit.

Zusätzlich zu ESC6 sehen wir im Screenshot aber auch noch ESC8 als möglichen Angriffsweg. ESC8 beschreibt einen NTLM Relay Angriff auf die http Endpunkte einer CA. Wer nicht genau weiß, was ein NTLM Relay Angriff genau ist, kann sich hier schlau machen. Endpunkte einer CA können die Rolloutschnittstelle certsrv, der CES/CEP Dienst, der für Cross-Forest Zertifikate benötigt wird oder die NDES Schnittstelle sein. Um sich gegen ESC8 zu schützen, sind unserer Meinung nach nur zwei Wege möglich. Entweder kann man den Dienst ganz abschalten, oder man stellt von http auf https um. Jetzt ist dies nicht ohne weiteres möglich. Zumindest gibt es ein paar Szenarien, in denen z.B. https nicht möglich wäre. Aus unserer Erfahrung bietet es sich an, nochmals genau zu prüfen, welche Zertifikate wo benötigt werden und ob das aktuelle Verfahren zur Zertifikatsverteilung nicht grundsätzlich angepasst werden kann.

In unserem Test wurden weitere Templates als verwundbar kategorisiert. Hier wird es ehrlicherweise etwas knifflig und ein pauschales Urteil ist hier schwer zu fällen. Wir möchten damit verdeutlichen, dass es durchaus Sinn ergibt, das genaue Vorgehen intensiv zu beraten. Nachfolgend sehen wir ein Template, das laut PSPKIAudit für ESC1 verwundbar ist.

Hier kommen im Wesentlichen vier Themen zusammen.

      1. Low-Priv user haben Zugriff auf dieses Template. In diesem Fall die Domain User. Ggf. könnte man diese Gruppe kleiner fassen, vermutlich ist aber genau das der Zweck, dass wir das Template großflächig verteilen möchten.
      2. Das Template steht auf „Supply in the request“, was bedeutet, dass der Antragssteller jeden beliebigen Subject konfigurieren kann. Hier könnte man ggf. die Informationen aus dem AD automatisch zusammenbauen. Das erscheint uns bei einem solchen Zertifikat vermutlich am besten.
      3. Client Auth und Smart Card Logon sind hier EKUs, die zur Domain Authentication verwendet werden können. Genau wie bei den Low Priv Usern würden wir deshalb davon ausgehen, dass genau das der Zweck ist – nämlich SmartCard Zertifikate auszurollen. Die EKUs zu entfernen, ist also vermutlich keine Option. Ggf. kann dann aber umso mehr Punkt 2 helfen.
      4. Zusätzlich gibt es kein Manager approval – das wäre eine weitere Sicherheit, da ein Manager zunächst prüft, ob ungewünschte Angaben (z.B. einen high priv User als Subject) im Request enthalten sind. Da die Nutzergruppe mit Domain User sehr groß ist, würde das allerdings einen hohen Aufwand bedeuten.

Das ESC1 Beispiel verdeutlicht, wieso es so schwierig ist, hier angemessen zu reagieren. Die regelmäßige Überprüfung von bereits ausgestellten Zertifikaten kann hier ebenfalls helfen, dazu weiter unter mehr.

Im nächsten Screenshot möchten wir noch kurz auf ESC4 eingehen. Man glaubt es vielleicht nicht, aber genau diesen Fehler haben wir schon recht oft in realen Umgebungen gesehen.

ESC4 bedeutet, dass durch eine fehlerhafte ACL Unberechtigte das Template verändern könnten und z.B. SANs erlauben. Hier stört uns die Berechtigung „FullControll“ für die Gruppe Authenticated User. Diese Fehlkonfiguration kommt meistens in „historisch gewachsenen“ Umgebungen vor, in denen sich niemand richtig traut, bestehende Einstellungen zu hinterfragen und anzupassen. Authenticated User benötigen definitiv kein Full Controll Recht auf ein Zertifikatstemplate. Diese Berechtigung muss schlicht entfernt werden. Genauso übrigens auch das Write Recht.

Wir hoffen, mit diesen Ausführungen einen ersten Einstieg in das Thema vereinfacht zu haben. Wenn wir bei einer CA Analyse unterstützen sollen, könnt ihr einfach auf uns zukommen – wir helfen gerne 😊.

Abschließend möchten wir noch auf die Fragestellung eingehen, ob in der Vergangenheit bereits verdächtigte Zertifikate ausgestellt wurden.

Sind bereits verdächtige Zertifikate vorhanden?

Mit dem Command Get-Certrequest wird jedes Zertifikat, das von der entsprechenden CA ausgestellt wurde, ausgegeben und muss analysiert werden. Es gibt hier keinen Automatismus, sondern man muss die Zertifikate selbst überprüfen. Deswegen bietet es sich an, die Ergebnisse in einer CSV zu speichern. Damit lässt sich die spätere Analyse durch entsprechende Scripts ggf. vereinfachen. Nachfolgend ein Beispiel-Output aus unserer Testumgebung.

Ist das erste und zweite Zertifikat noch unauffällig, stellen wir beim dritten fest, dass ein SAN definiert ist. Unter anderem ist der SAN administrator@test-teal.internal definiert. Der Requestor Name war aber cea.t0.CertUser. Diese Abweichung sollte uns zumindest dazu veranlassen, genau zu hinterfragen, wieso diese Konfiguration benötigt wird. Vermutlich wäre das aber ein mehr als verdächtiges Zertifikat, das umgehend gesperrt werden sollte. Grundsätzlich empfehlen wir, darauf zu achten, ob Requestor und Subject/SAN zusammenpassen. Wenn nein, muss es erklärbar sein, ansonsten sollte das Zertifikat gesperrt werden. Je nachdem, wie viele Zertifikate die CA ausgestellt hat, ist die Prüfung entsprechend aufwendig, sollte aber dennoch gemacht werden.

 

Unser Fazit

Unser Fazit nach der Veröffentlichung der Schwachstellen letztes Jahr ist, dass sich ein PKI Audit durchaus lohnt. Neben den oben beschriebenen Schwachstellen finden wir immer wieder Optimierungsmöglichkeiten, die wir mit unseren Kunden gemeinsam umsetzen. Das Gute ist, dass es mit PSPKIAudit bereits ein Werkzeug gibt, das Administratoren nutzen können. Zugegeben, mit dem Thema PKI muss man sich trotzdem beschäftigen, aber dafür gibt es ja z.B. diesen Blog Artikel 😊.

LATEST POSTS

  • Nachdem wir bei diversen weiteren Kunden PAW Konzepte entwickeln und umsetzen durften, sehen wir den Zeitpunkt gekommen, einzelne Aspekte weiter zu detaillieren und unsere Erfahrungen bei der praktischen ...

  • Vor rund 1,5 Jahren haben wir bei Teal unser Trainee-Programm gestartet und bisher in drei Halbjahresabständen insgesamt sechs Trainees zu IT-Security-Experten ausgebildet oder sind kurz davor. Ab August beginnt unser vierter Lauf und zwei neue Kollegen starten...

  • Wofür steht Zero Trust? Warum wird dieses Konzept zunehmend wichtiger? Was ist bei der Umsetzung zu beachten? Und spielt Systemhärtung hier eine Rolle? Dies und mehr klärt dieser Ratgeber...