November 19, 2024
Kritische Lücke bei Palo Alto Networks: Patches und CISA-Warnungen Die neuste schwerwiegende Sicherheitslücke in Produkten von Palo Alto Networks hat
Die Abkürzung NTLM steht für New Technology LAN Manager, dabei handelt es sich um ein von Microsoft entwickeltes und bereitgestelltes Authentifizierungsverfahren anhand eines Challenge-Response-Mechanismus.
Die erste NTLM Version, welche im Jahr 1993 erstmals veröffentlicht wurde, ist mittlerweile als NTLMv1 bekannt. Diese Version sollte nicht mehr verwendet werden. Bereits fünf Jahre später, also 1998, veröffentlicht Microsoft die heute üblicherweise verwendete Version NTLMv2.
NTLMv2 ist in Netzwerken noch häufig verbreitet, insbesondere da ältere Dienste und Protokolle nicht deaktiviert werden, kommt dieses zum Einsatz. Falls die Netzwerkinfrastruktur und die verwendeten Systeme es zulassen, sollte dies durch neuere Protokolle wie z.B Kerberos ersetzt werden!
Im Kontext des Themas NTLM gibt es immer wieder Verwirrung in der Unterscheidung der Begrifflichkeiten.
NT-Hash: Der NT-Hash (Windows NT), ist gemeinsam mit dem LM-Hash (LAN Manager), in der SAM-Datenbank (Security Accounts Manager) zu finden. Gegen diesen können Angriffe zum Cracken der Hashe laufen oder er kann für pass-the-hash Angriffen verwendet werden.
NTLM: Von Microsoft bereitgestelltes Authentifizierungsprotokoll. Dies wurde mittlerweile durch Kerberos abgelöst. NTLM existiert in zwei Versionen, der älteren NTLMv1 auch bekannt als Net-NTLMv1 und der Version NTLMv2 bzw. Net-NTLMv2. Wobei auch die neuere Version nicht mehr als Stand der Technik angesehen werden kann und dort, wo möglich durch Nachfolgelösungen z.B. Kerberos ersetzt werden sollte.
NTLMv2 verwendet ein Challenge-Response-Verfahren, um den anfragenden Netzteilnehmer zu authentifizieren. Dazu findet folgende Kommunikation zwischen Client und Server statt:
Sollte es einem Angreifer gelingen, einen NTLMv2 Hash zu erhalten, kann er versuchen diesen zu cracken und das Passwort zu erhalten oder sich zwischen die Kommunikation von Client und Server „schalten“ und Informationen zu (veränderten) Anfragen abzufangen. Wie dies möglich ist, haben wir in den Beiträgen LLMNR, NetBIOS oder auch IPv6 beschrieben.
Zur Veranschaulichung der Angriffsmöglichkeiten wurde eine Laborumgebung aufgebaut, darin befinden sich:
Zur Durchführung der nachfolgend beschriebenen Szenarien, muss das Netzwerk so konfiguriert sein, dass IPv6 aktiv ist und keine automatische Filterung von Paketen erfolgt (in virtuellen Umgebungen muss dies ggf. aktiv eingestellt werden).
Zusätzlich zeigte sich, dass in dieser Labor-Umgebung auf dem Domain-Controller die Active Directory-Zertifikatsdienste zum Nachstellen für den Relay auf LDAPS installiert und eingerichtet werden müssen.
Im ersten Angriff-Szenario erfolgt ein Relay der NTLM Authentifizierung zu SMB. Dazu nutzen wir das Windows Verhalten bei der Namensauflösung. Wenn im Client nach einer Freigabe gesucht wird, welche der bekannte DNS nicht auflösen kann, erfolgt die Abfrage mittels alternativer (Vorgänger-)Protokolle, z.B. LLMNR.
Diese Abfrage kann vom Angreifer abgefangen werden, der sich als entsprechender Server ausgibt und die Anfrage verändert weiterreicht. Denn ein NTLM-Hash beinhaltet keinerlei Angaben zu Ziel oder Absender. In unserem Fall erfolgt eine Abfrage der Sicherheitskontenverwaltung (SAM – Security Account Manager) zur Ausgabe aller lokal auf dem System abgelegten Passwort-Hashs der vorhandenen Benutzer:
Vor dem Start des responders sind in der Konfiguration die Optionen SMB und http zu deaktivieren. Der Responder lauscht auf dem Interface eth0.
Ntlmrelayx soll eine Weiterleitung an die IP 192.168.5.5 vornehmen, in diesem Falle der lokale Windows 10 Client. Der Dump der SAM-Daten ist Standardverhalten des Tools für SMB.
Die Ausgabe zeigt die entsprechenden LM- bzw. NT-Passwort Hashs der Nutzer, darunter z.B. Administrator und myUser. Diese Hashes können nun zu Offline-Angriffen auf die Passwörter mittels Brute-Force genutzt oder zur Authentifizierung in Windows-Domänen genutzt werden.
Im nächsten Beispiel erfolgt eine Weiterleitung mittels IPv6 an LDAP. Dadurch kann durch einen unautorisierten Benutzer ohne Berechtigungen im AD eine Abfrage von Domäneninformationen erfolgen. Der Angriff erfolgt mittels mitm6 und ntlmrelayx.
Anschließend genügt es, wenn ein User auf dem Windows10-Client den Browser öffnet. Denn im Standardverhalten sucht dieser zuerst nach bereitgestellten Proxykonfigurationen, welche der Angreifer mittels mitm6 abfängt. Das Standardverhalten von ntlmrelayx bei einer Weiterleitung zu ldap ist die Abfrage von Domäneninformationen, welche im lokalen Verzeichnis abgelegt werden.
Zuletzt wird die Anfrage mittels LDAPS weitergeleitet. Der Versuchsaufbau ist dabei der gleiche wie im letzten Szenario, allerdings soll ntlmrelayx nun eine Verbindung zu LDAPS herstellen und dabei einen PC anlegen. Diesen könnten wir anschließend für weitere Angriffe verwenden.
Die beste Vorgehensweise zur Verhinderung der genannten Angriffe ist die entsprechend, sichere Konfiguration des Netzwerks bzw. der beteiligten Komponenten. Einige Möglichkeiten, welche auch vor den beschriebenen Angriffen schützen, wurden bereits in unseren bisherigen Beiträgen vorgestellt, dazu zählen etwa „IPv6 – Man in the Middle“ oder „LLMNR Poisoning“. Darüber hinaus verhindern die folgenden Maßnahmen die Möglichkeit, die oben gezeigten Angriffe erfolgreich auszuführen.
Bei der Paket-Signierung wird jedes versendetes Paket mit einer Signatur versehen, diese ermöglicht es Client und Server festzustellen, dass dieses nicht verändert wurde. Es schützt jedoch nicht davor, dass Pakete mitgelesen werden können. Signierung darf hier nicht mit Verschlüsselung verwechselt werden.
Bei SMBv2 wird beispielsweise unter Berücksichtigung der gesamten Nachricht ein entsprechender Hash mittels HMAC-SHA256 berechnet.
Die SMB-Signierung dient als Authentizitäts- und Integritäts-Merkmal für SMB-Pakete, die beim Ressourcenzugriff innerhalb des Active Directories genutzt werden. Client und Server signieren dabei die SMB-Pakete bei der Kommunikation, so dass verhindert werden kann, dass SMB-Pakete verändert oder weitergeleitet werden. (Details unter https://www.prosec-networks.com/blog/smb-server-message-block-protokoll/)
Eine entsprechende Signierung wird dabei erst ab Version SMBv2 empfohlen, da die Paketgröße bei SMBv1 so gering ist, dass es hier zu Performanceproblemen kommen kann. Weiterhin ist bei der Konfiguration darauf zu achten, dass die Signierung erzwungen (required) wird und diese nicht nur erwünscht bzw. ermöglicht (enabled) wird.
Die SMB Signierung kann durch GPOs an Servern und Clients konfiguriert werden. Wie immer wird auch an dieser Stelle geraten, dies in entsprechenden Teststellungen vor der Umsetzung zu prüfen!
Empfohlene Einstellungen:
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Aktiviert
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Deaktiviert
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Aktiviert
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Deaktiviert
Analog zur Signierung mittels SMB, kann eine Signierung auch für LDAP eingestellt werden. LDAP-Signing versieht die LDAP-Verbindung mit einer digitalen Signatur.
Die Einstellung erfolgt ebenfalls mittels GPO auf dem Domänencontroller für Server und Client:
LDAP-Signaturanforderung für den Server (GPO):
Computer -> Richtlinien -> Windows Einstellungen -> Sicherheitseinstellungen -> lokale Richtlinien -> Sicherheitsoptionen -> “Domänencontroller: Serversignaturanforderungen für LDAP-Server“ aktivieren
LDAP-Signaturanforderung für den Clients, mittels DC Gruppenrichtlinie (GPO):
Computer -> Richtlinien -> Windows Einstellungen -> Sicherheitseinstellungen -> lokale Richtlinien -> Sicherheitsoptionen -> “ Netzwerksicherheit: LDAP-Clientsignierungsanforderungen –“ Aktivieren
Ein fehlendes Channelbinding erlaubt es Authentifizierungen an LDAPS weiterzuleiten.
Beim Channelbinding wird ein Hash des Zertifikats (des Servers gebildet) und an das normale Paket angehangen. Der Server führt denselben Schritt durch und überprüft dann den Hash seines Zertifikats mit dem Hashwert der dem LDAPS Paket angehangen wurde.
Im März 2020 veröffentlichte Microsoft entsprechende Updates, um Channelbinding zu nutzen.
Hinweis: In der oben genannten Test-Umgebung müssen die Updates entsprechend installiert werden, da Channelbinding ansonsten nicht verfügbar ist.
– An Domain Controllern kann das Channel Binding über die Aktivierung der Gruppenrichtlinie „Domänencontroller: Anforderungen an das LDAP-Serverkanal-Bindungstoken“ konfiguriert werden. Diese befindet sich in der Gruppenrichtlinienverwaltung unter dem Pfad Computer > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen
– Die Richtlinie muss auf die Option „Immer“ konfiguriert werden und die Richtlinie muss aktiviert werden.
Hinweis: Ob LDAP Signing und Channelbinding aktiv sind, kann einfach mittels LdapRelayScan https://github.com/zyn3rgy/LdapRelayScan.git überprüft werden. Zur Überprüfung von LDAP Signing muss ein valider Domänen Nutzer verwendet werden.
Der direkte Angriff kann nur schwer erkannt werden, da die Nutzung der beschriebenen Protokolle zum Standardverhalten im Netzwerk gehört. Eine Möglichkeit der Erkennung ist die Überwachung der Geräte im Netzwerk auf den dem Angriff zugrundeliegenden Protokolle (z.B.) LLMNR. Antworten auf diese Anfragen kommen in der Regel nicht von den im Netz vorhandenen Systemen, Details dazu unter: https://www.prosec-networks.com/blog/llmnr-poisoning/
Ebenso kann diese Erkennung in der Firewall konfiguriert werden. Die Antworten, die der Angreifer in oben vorgestellten Szenarien sendet, sollten nur von bekannten und autorisierten System erfolgen (LLMNR, wpad). Erfolgt im Netzwerk eine Antwort einer dazu nicht definierten IP, so kann der Angreifer dadurch ermittelt werden.
Wird durch die im letzten Abschnitt beschriebenen Methoden ein Angriff erkannt, so sollten sie möglichst viele Informationen zu diesem erlangen. Anschließend sollte das entsprechende Gerät gesperrt werden.
Zusätzlich sollten alle vorhandenen Protokolle nach Aktivitäten dieser IP durchsucht werden. Dazu zählen neben den Logs der Firewalls und Netzwerkgeräte, insbesondere die Ereignisprotokolle der Domänencontroller.
IT-Grundschutz-Kompendium:
OPS.1.1.3: Patch- und Änderungsmanagement
NET.1.2: Netzmanagement
ISO27001:
A.12.4.1 Ereignisprotokollierung
A.13.1 Netzwerksicherheitsmanagement
Kritische Lücke bei Palo Alto Networks: Patches und CISA-Warnungen Die neuste schwerwiegende Sicherheitslücke in Produkten von Palo Alto Networks hat
Chinesische Hacker nutzen T-Mobile und andere US-Telekommunikationssysteme für umfangreichere Spionagekampagne Das riesige US-Telekommunikationsunternehmen T-Mobile hat bestätigt, dass es zu den
Die Herausforderung von Berechtigungen und nicht-menschlicher Identitäten – Warum die Verwaltung von Anmeldeinformationen länger dauert, als Sie denken Mit den
