Sicherheitslücke: Mit acht Nullen zum Active-Directory-Admin
Die Sicherheitslücke Zerologon nutzt einen Fehler in Netlogon aus und involviert die Zahl Null auf kreative Weise - um Passwörter zu ändern.
Die Sicherheitsfirma Secura hat eine weitere kritische Sicherheitslücke in Microsofts Nutzerverwaltung Active Directory (AD) entdeckt: Zerologon. Ein Fehler in der kryptographischen Authentifizierung des von Active Directory genutzten Netlogon-Remote-Protokolls kann ein angreifendes System zu einem Domänen-Admin ernennen oder Zugriff auf einen Domänencontroller erhalten. Darüber wäre theoretisch der Zugriff auf Informationen innerhalb des Unternehmens möglich, die über AD-Accounts erreichbar sind. Die Sicherheitslücke ist deshalb unter CVE-CVE-2020-1472 als kritisch gelistet.
Microsoft selbst bietet seit Mitte August ein Sicherheitsupdate für Windows-Server-Betriebssysteme an. Es sollte dort direkt installiert werden.
Allerdings wird dort zunächst die RPC-Nutzung von Domänen-Controllern (DC) erzwungen. Damit nicht kompatible Geräte - typischerweise Clients mit älteren und nicht unterstützten Betriebssystemen - werden im Ereignisprotokoll des DC angezeigt. Für solche Geräte wird es zunächst eine Gruppenrichtlinie geben, die den Zugang zur Domäne weiterhin erlaubt. Diese Richtlinie muss allerdings manuell installiert werden. Erst im Februar 2021 wird Microsoft RPC auf allen Geräten erzwingen - es sei denn, sie wurden speziell mit der Gruppenrichtlinie zugelassen. Eine wirkliche Behebung des Problems ist demnach wohl nur durch Neuanschaffungen oder weitere Patches seitens der Drittanbieter möglich.
Secura hat auf Github auch ein Script veröffentlicht, mit dem ein Firmennetzwerk auf die Sicherheitslücke hin untersucht werden kann. Das Team hat zudem eine detaillierte Dokumentation als PDF veröffentlicht, welche die Vorgehensweise des Angriffs beschreibt.
Von einem Fehler zum Domänen-Admin
Für den Angriff wird die Funktion ComputeNetlogonCredential des Netlogon-Protokolls ausgenutzt, welche einen festgelegten 8-Bit-AES-Initialisationsvektor (IV) aus ausschließlich Nullen verwendet. ComputeNetlogonCredential verwendet AES-CFB8, um 8-Bit-Credentials in 16 Bit lange verschlüsselte Wörter umzuwandeln. Durch falsche Anwendung in Netlogon ist der IV für die Sicherheitslücke mitverantwortlich. Die Funktion verwendet nämlich keine zufallsgenerierten Vektoren, sondern festgelegte Werte.
Das Problem: Der Sicherheitsforscher Tom Tervoort hat entdeckt, dass der Parameter Clientcredential - Teil der Funktion ComputeNetlogonCredential - in einem aus 256 Fällen ebenfalls aus acht Nullen besteht, wenn Angreifende die Challenge, die zwischen Domänencontroller und -clients für eine Authentifizierung ausgetauscht wird, auf ausschließlich null setzen. Nach maximal 256 Brute-Force-Versuchen mit dem Call NetrServerAuthenticate3 kann sich das System in einer Domäne als Client authentifizieren, was laut dem Forscher etwa 3 Sekunden Rechenzeit entspricht.
Signing und Sealing umgehen
Bei aktiviertem Signing und Sealing, einer weiteren Sicherungsebene in der von Netlogon verwendeten NTLM-Authentifizierung, wäre hier allerdings Schluss, da nach dem Umgehen des ersten Authentifizierungsprozesses dafür ein anderes Schema genutzt wird. Allerdings sind Signing und Sealing für Clients im zuvor genutzten Aufruf NetrServerAuthenticate3 optional und werden standardmäßig vom Server auch ohne diese Maßnahme akzeptiert. Mit Hilfe eines Flags vom Angriff kann dieser Schritt einfach abgeschaltet und umgangen werden.
Aufrufe müssen zusätzlich einen Authentifizierer-Wert enthalten. Daher gibt das angreifende System vor, dass es sich am 1. Januar 1970 - dargestellt durch den Wert Null - anmeldet. Der Server überprüft nicht, ob es sich um das echte Datum handelt, um Probleme mit der Hardware-Uhr zu umgehen. Der Authentifizierungswert, der für eine erfolgreiche Authentifizierung am System benötigt wird, berechnet sich aus der zuvor genutzten Funktion ComputeNetlogonCredential und dem auf null gesetzten Zeitwert. Da ComputeNetlogonCredential(0) wie zuvor festgestellt ebenfalls wieder null ergibt, ist eine Anmeldung mit einem aus ausschließlich Nullen bestehendem Authentifizierer und Timestamp möglich.
Danach können weiterführende Methoden verwendet werden. Der Aufruf der Funktion NetrServerPasswordSet2 setzt etwa ein neues lokales Passwort für den entsprechenden Client - ohne das eigentliche Kontopasswort zu kennen. Diese Funktion verwendet nämlich erneut das schon ausgenutzte AES-CFB8 mit ausschließlich Nullen. Von dort aus kann ein leeres Passwort durch Nullen vergeben werden. Bei einer erneuten Anmeldung kennen Angreifer daher das Administrator-Passwort für das Active-Directory-Konto.
Das Resultat: Zugriff mit erweiterten Rechten auf dem lokalen Computer und die Möglichkeit, ein eigenes neues Passwort zu vergeben. Hier ist es bereits möglich, sich auf einem als Domänencontroller deklarierten System lokal anzumelden. Allerdings stimmt dann das lokale Passwort nicht mit den in der Active-Directory-Datenbank hinterlegten neuen Daten überein, was laut Tervoort zu unvorhersehbaren Nebeneffekten führt und etwa den DNS-Auflöser abstürzen lässt.
Mit Hilfe des auf Github verfügbaren Scripts Secretsdump.py lassen sich alle User-Hashwerte aus der Domain per Domain Replication Service Protocol extrahieren, einschließlich der Werte für Domänen-Administrator-Konten. Mit Hilfe einer Pass-the-Hash-Attacke ließe sich das neue Passwort in die lokale Registry des Domänencontrollers schreiben.
Hallo, ganz richtig: Das meint Domänen-Administratoren. Allerdings hätte das in der...
dass die NSA diese Lücke schon seit Jahrzehnten kennt und Microsoft auch. Ansonsten sehe...
Es steht alles auf einer im Artikel verlinkten MS-Seite. Die sollte man zumindest mal...