Windows im Visier: Der Zerologon-Angriff

Der Angriff durch Zerologon nutzt eine Schwachstelle des Netlogon Remote Protokolls (NRPC) bei der Client- und Server-Domainauthentifizierung. Diese erfolgt mittels einer modifizierten AES-Verschlüsselung.

Der Prozess für den Aufbau einer Netlogon-Session geschieht in den folgenden Schritten:

1. 1. 1. Sowohl der Client als auch der Server berechnen und erzeugen einen 8-stelligen zufällig generierten Schlüssel, eine sogenannte Challenge.
      2.  Beide Challenges werden zwischen Client und Server ausgetauscht, daraus generieren Client und Server jeweils einen Sessionschlüssel. Hierfür werden beide Challenges mit dem shared-secret kombiniert, anschließend mittels Schlüsselableitung der Sessionschlüssel erzeugt.
      3. Der Client nutzt den Sessionschlüssel, um einen client credential zu berechnen.
      4. Der Server berechnet den gleichen credential-Wert erneut und vergleicht diese. Sofern beide credentials übereinstimmen, ist die Vertrauenswürdigkeit gewährleistet.

Während des Handshakes wird ausgehandelt, ob der nachfolgende Datenverkehr verschlüsselt wird.

Um den client credential zu berechnen wird eine protokoll-spezifizierte Funktion namens ComputeNetlogonCredential genutzt. Diese Funktion nimmt einen 8-Byte großen Input entgegen und führt eine Transformation mit dem shared-secret aus. Es entsteht ein gleich großer Output.

Es bestehen zwei Versionen dieser Funktion, von denen die eine auf 2DE (gilt als unsicher) und die andere auf AES basiert (als sicher geltend).

Die AES-Variante wird bei der Authentifizierung verwendet, enthält jedoch die Schwachstelle, die Zerologon ein Einfallstor bietet.

Weiterhin verschlüsselt AES mittels CFB8 (8-Bit cipher Feedback) jedes Byte des Klartextes, sodass ein 16 Byte großer Initialisierungvektor (IV) dem Klartext vorangestellt wird. Dann werden auf die ersten 16 Bytes des IVs+Klartext AES angewandt.

Die Schwachstelle entsteht, weil der IV fix ist und immer 16 Nullbytes hat. Das spricht gegen die AES-CFB8 Sicherheitsvorschrift, die besagt, dass der IV Wert zufällig generiert sein muss.

Der Angreifer kann den Klartext des Passwortes auf 8 Nullen setzen. Hierbei ergibt sich eine Besonderheit: In einem von 256 Fällen, in denen die ersten 8-Bytes Nullen enthalten und mittels AES-CFB8 verschlüsselt werden, entsteht ein Produkt, das lediglich aus Nullen besteht. Dieser genullte Ciphertext ermöglicht also in einem von 256 Fällen eine erfolgreiche Authentifizierung.

Es werden der Netlogon Protocol Passwortstruktur entsprechend 516-Bytes, die aus Nullen bestehen, an den Server übertragen. Hierdurch lässt sich das Passwort für jeden Computer in der Domain auf 0 stellen und somit auf diese zuzugreifen.

Auf diese Weise geschieht die Änderung im Active Directory (AD), d.h das Zielsystem behält sein ursprüngliches lokales Passwort.

Wie wirkt sich das auf den Windows Administrator aus?

Der betroffene Computer kann sich nicht mehr im AD authentifizieren und nur manuell erneut synchronisiert werden, was in einer Denial of Service Attacke (DDoS) resultiert. Dennoch hat der Hacker Privilegien innerhalb der Domain.

Dem Angreifer ist es mittels öffentlich verfügbaren Tools möglich, alle NTLM-Hashes (inklusive Domainadmin Hashes) von Benutzern in der Domain zu extrahieren. Demzufolge kann er sich damit am Domain Controller (DC) authentifizieren und diesen übernehmen. Der Angreifer hat jetzt volle Kontrolle über die Domäne. Potenzielle Konsequenzen sind nicht einzugrenzen.

Wer ist von dieser Schwachstelle betroffen?

Betroffen sind Windows Server, die seit August 2020 nicht mehr gepatcht wurden.

Proof of Concept

Für die beschriebene Schwachstelle haben wir innerhalb unserer Red-Team-Testumgebung ein Testszenario erstellt. Wir konnten den im Testszenario erzeugten Datenverkehr untersuchen und die gewonnen Erkenntnisse in die SOC-Erkennungsalgorithmen integrieren.

Im nächsten Schritt wurde in der Testumgebung mit dem Skript https://github.com/zer010bs/zeroscan/blob/master/zerologon_tester-mod.py eine gefälschte Authentifizierung durchgeführt. Durch eine erfolgreiche Authentifizierung im AD konnten wir die Systempasswörter innerhalb dieser Domäne ändern.

Die entsprechenden Hashes konnten wir mit dem secretdump-Skript extrahieren und im AD der Domäne das Domänenpasswort ändern, das sich im lokalen Register des DCs befand.

Nach Abschluss des Testszenarios wurden die durch das SOC erlangten Informationen verifiziert und es konnte eine mehrfache Detektion bestätigt werden.

• Mehr Informationen zu Zerologon auf bsi.bund.de