goSecurity BLOG

Kennen Sie das? Sie möchten einfach kurz was ausprobieren. Also installieren Sie einen Dienst auf einem Server, probieren das Ganze kurz aus und vergessen den Dienst, den Sie nur kurz testen wollten. Monate später ist der Server immer noch gleich konfiguriert. Das finden wir manchmal auch bei unseren Audits bei Kunden.

Kürzlich habe ich einen internen Penetration Test bei einem Kunden durchgeführt. Beim Test habe ich wie bei vielen Kunden einen Drucker mit Standardzugangsdaten im Netzwerk gefunden. Auf diesem Drucker war ein LDAP-Benutzer hinterlegt. Ich dachte wow, war es schon wieder so einfach. Nach einer kurzen Überprüfung musste ich feststellen, dass es sich nur um einen standard Domänenbenutzer handelte. Also stand ich wieder am Anfang.

Nach kurzer Überlegung kam ich zu dem Entschluss, dass ich versuchen wollte einen neuen Computer in der Domäne mit diesem Benutzer zu verbinden. Also nahm ich eine mit Windows 10 installierte VM und betrat die Domäne. Wenn nichts speziell konfiguriert ist, kann jeder Benutzer bis zu 10 Computer mit der Domäne verbinden. Jetzt hatte ich einen Windows 10 Client verbunden mit der Domäne, mit einem standard Domänenbenutzer (der LDAP-Benutzer vom Drucker) mit lokaler Administratorberechtigung.

Nach ein bisschen herumschnuppern fand ich heraus, dass ich Zertifikate über eine Public Key Infrastruktur (PKI) beantragen konnte. Hier sah ich meine Chance. Wenn die PKI nicht richtig konfiguriert ist und beispielsweise eine Zertifikatsvorlage für die Beantragung der Clientzertifikate vorhanden ist, kann über diese auch ein Zertifikat für eine Smartcard erstellt werden.

Das Zertifikat

Für diesen Blog habe ich den Fall im Lab nachgestellt. Wir haben jetzt einen Windows 10 Client, welcher mit der Domäne gotraining.lab verbunden ist. Auf diesem Client haben wir den Domänenbenutzer ldap@gotraining.lab, welcher Mitglied der lokalen Administratoren Gruppe ist. Weiter haben wir in der PKI eine Zertifikatvorlage, welche für die Client Authentifizierung zugelassen ist und bei der die zusätzlichen Felder Subject oder Subject Alternate Name geändert werden dürfen.

Mit diesem Benutzer öffnen wir Manage computer certifcates und gehen auf Request New Certificate. In unserem Fall können wir ein Zertifikat für eine Web-API beantragen, bei dem wir zusätzliche Informationen einpflegen müssen, um dieses Zertifikat zu beantragen.

In den Zusatzfeldern Subject geben wir einfach eine Webadresse als Common name ein und bei Alternative name erfassen wir den User principal name vom Domain Administrator (administrator@gotraining.lab). Wenn jemand das Zertifikat überprüft, wird dieser im ersten Moment nichts Auffälliges sehen, da es auf eine Webseite ausgestellt ist.

Das beantragte Zertifikat ist unter Personal\Certificates abgelegt und sieht wie folgt aus:

Nur wenn wir die Details im Zertifikat anschauen, sehen wir, dass der Domain Administrator als Subject Alternative Name hinterlegt ist. Dieses Zertifikat müssen wir jetzt nur noch exportieren.

Die Smartcard

Mit dem exportierten Zertifikat können wir nun eine Smartcard erstellen, welche wir für die Authentifizierung an Windows verwenden können. Dazu verwenden wir TpmVscMgr. Das ist der Befehl, um eine virtuelle Smartcard zu erstellen. Als nächstes importieren wir unser exportiertes Zertifikat auf die Smartcard.

Unsere Smartcard ist fertig. Jetzt können wir unseren Zugriff prüfen. Zuerst mit unserem LDAP-Benutzer.

Wie wir sehen, haben wir keinen Zugriff auf \\h2p-dc\c$. Jetzt können wir es noch mit unserer Smartcard versuchen.

Wir können auf \\h2p-dc\c$ zugreifen. Wir können uns aber auch mit runas.exe und psexec.exe direkt mit dem Server verbinden, anstatt nur auf ein Laufwerk zuzugreifen.

Warum funktioniert das?

Das liegt daran, das der Key Distribution Service (KDC) nicht prüft, ob die Enhanced Key Usage Erweiterung Smart Card Logon vorhanden ist. Jetzt denken Sie vermutlich, dass es sich um einen Fehler handelt. So ist es leider nicht. Dieses Verhalten wurde von Microsoft mit Windows Server 2008 bewusst integriert und ist in allen Windows Versionen bis heute vorhanden. Ziel war es, die Anmeldung mit anderen digitalen Zertifikaten, wie beispielsweise einem Personalausweis, zuzulassen. Da hier nicht sichergestellt werden konnte, dass die Zertifikate die richtigen Enhanced Key Usages aufweisen, wurde die Überprüfung einfach deaktiviert.

Es gibt zwar die Gruppenrichtlinie Allow Certificates with noch extended key usage certificate attribute (Computer Configuration\Administrative Tools\Windows Components\Smart Card), bei der Sie konfigurieren können, dass nur Zertifikate für die Smartcard Anmeldung zugelassen werden, welche die Enhanced Key Usage Erweiterung Smart Card Logon beinhalten. Dieses gilt jedoch nur für das Windows Login GUI. Somit reicht es, beispielsweise für Befehle mit runas, ein Zertifikat mit der Enhanced Key Usage Erweiterung Client Authentication für die Smartcard Anmeldung zu verwenden.

Fazit

Es ist mal wieder nicht nur ein Fehler, der zum Ziel führt, sondern eine Verkettung von mehreren.

Um sich vor so einem Angriff zu schützen, empfehlen wir Ihnen unteranderem folgende Massnahmen:

• Standardzugangsdaten auf allen Netzwerkgeräten, wie beispielsweise Drucker, zu ändern.
• Lokale Administrationsberechtigung auf einem Minimum halten.
• Add workstations to domain einschränken. Wenn die Standardbenutzer diese Berechtigung nicht benötigen, die Gruppe Authenticated Users entfernen.
  
  Spezielle Accounts, welche Computer zur Domäne hinzufügen dürfen, können die Berechtigung Create Computer Object über eine Delegierung auf der dazugehörigen OU erhalten.
• Bei allen Zertifikatsanforderungen, bei denen die zusätzlichen Felder Subject oder Subject Alternate Name konfiguriert werden können, CA certificate manager approval aktivieren. Dadurch müssen diese noch vor der Ausstellung genehmigt werden.

• EDITF_ATTRIBUTESUBJECTALTNAME2 auf der Zertifizierungsstelle deaktivieren. Dieses Attribut wird häufig auf der Zertifizierungsstelle aktiviert, um Subject Alternate Name für Webzertifikate zu erlauben. Bei dieser Einstellung wird es jedoch für den ganzen Server aktiviert und gilt somit für jedes Zertifikat. Wenn die Zertifizierungsstelle auch im NTAuth-Enterprise-Speicher vorhanden ist, ermöglicht ein solches Zertifikat die Smartcard Anmeldung.

  certutil -v -setreg Policy\Editflags -EDITF_ATTRIBUTESUBJECTALTNAME2

• Eigenständige Zertifizierungsstelle für Smartcard einrichten
• Microsoft Empfehlungen für eine sichere PKI-Infrastruktur beachten