goSecurity BLOG

Bei vielen unserer Audits finden wir Dateifreigaben mit zu wenig eingeschränkten Berechtigungen. Teilweise haben sogar nicht authentifizierte Benutzer auf Freigaben Ändern-Rechte. Dass es nicht optimal ist, dass nicht authentifizierte Benutzer überhaupt eine Berechtigung auf Dateifreigaben haben, ist den meisten Kunden klar. Was für eine Auswirkung es haben kann, jedoch nicht.

Der Zugriff auf Dateifreigaben erfolgt unter Windows mit dem SMB-Protokoll. Die Kommunikation ist in der Regel unverschlüsselt und die Authentifizierung erfolgt mit NTLMv2. Es handelt sich hier nicht um den NTLM-Hash aus dem Security Account Manager (lokale Maschine) oder aus der NTDS.dit (Active Directory), sondern um den Net-NTLMv2-Hash. Net-NTLM-Hashes werden für die Netzwerkauthentifizierung verwendet (sie werden von einem Challenge/Response-Protokoll abgeleitet) und basieren auf dem NT-Hash des Benutzers. Mit dem Net-NTLMv2-Hash kann zwar kein klassischer Pass-The-Hash-Angriff durchgeführt werden, es gibt jedoch andere Möglichkeiten.

Gelingt es einem Angreifer, sich in die Kommunikation einzuklinken, kann dieser die Netzwerkauthentifizierung verwenden, um sich auf einem anderen System zu authentifizieren. Es ist also nicht nötig, die Hashes zu knacken. Diese können direkt auf ein anderes System weitergeleitet werden.

Im folgendem Szenario möchte ich Ihnen die Auswirkung von falsch konfigurierten Berechtigungen in Verbindung mit dem SMB-Protokoll aufzeigen.

Szenario

Auf dem Fileserver befindet sich eine Freigabe ohne Einschränkungen. Der Hacker legt eine SCF-Datei (Shell Command File) auf dieser Freigabe ab. Greift ein Netzwerkbenutzer jetzt auf diese Freigabe zu, führt das System automatisch diese Datei aus. Durch das Ausführen dieser Datei greift das System auf einen SMB-Share, welchen es nicht gibt, oder direkt auf den Hacker-Client. Dieser fängt die Authentifizierung ab und leitet diese auf ein anderes System weiter.

Für unser Szenario haben wir folgende Systeme

Vorbereitungen

Um den Angriff durchzuführen, verwenden wir das Metasploit Framework. Um eine Rückverbindung (Reverse Shell) zu bekommen, wird Impacket NTLMRelayx verwendet.Und eine SCF-Datei wird verwendet, um die Netzwerkauthentifizierung abzufangen und umzuleiten.

Metasploit Payload und Listener erstellen

Mit msfvenom, ein Tool aus dem Metasploit Framework, erstellen wir eine exe-Datei, welche eine Rückverbindung (Reverse Shell) zu unserem Hacker-Client erstellt.

Als nächstes erstellen wir einen Metasploit-Listener (handler.rc), damit wir die Verbindung von der exe-Datei empfangen können.

SCF-Datei (Shell Command File)

Um das Opfer auf unseren Hacker-PC zu locken, erstellen wir eine SCF-Datei (@info.scf). Diese fordert das System auf, ein Icon über den UNC-Pfad \\192.168.80.129\gose.ico abzurufen, wenn die Ordner-Freigabe geöffnet wird.

Angriff

Nachdem alles vorbereitet ist, können wir den Angriff starten. Zuerst kopieren wir die info.scf auf die Dateifreigabe (192.168.80.100).

Anschliessend starten wir den Metasploit-Listener auf dem Hacker-Client (192.168.80.129). Dieser wartet jetzt auf unsere Reverse Shell.

Und zum Schluss starten wir Impacket NTLMRelayx auf dem Hacker-Client (192.168.80.129). Mit dem Parameter -t geben wir ein Ziel an, zu dem die Authentifizierung umgeleitet werden soll und mit -e die Datei, die auf das System ausgeführt werden soll (unsere Reverse Shell).

Greift nun das Opfer 1 (192.168.80.101) auf die Dateifreigabe zu, liest das System die @info.scf und authentifiziert sich an unserem Hacker-Client (192.168.80.129).

Das NTLMRelayx-Skript fängt die Authentifizierung ab und sendet sie direkt an unser Opfer 2 (192.168.100.128). Nach dem Authentifizieren kopiert das Skript unsere exe-Datei auf das Opfer-System und führt diese aus.

Beim Ausführen unserer exe-Datei wird eine Reverse Shell zu unserem Kali-Client (192.168.80.129) hergestellt. Und wir haben vollen Zugriff auf das System.

Erweiterter Angriff

Beim obigen Angriff sind wir darauf angewiesen, dass der Benutzer explizit auf die Freigabe zugreift. Um die Erfolgsaussichten zu verbessern, kann noch ein sogenannter Responder verwendet werden. Dieser antwortet auf alle möglichen Anfragen im Netzwerk. Versucht beispielsweise ein Opfer eine Freigabe auf einem Server zu öffnen, welches es nicht gibt, antwortet der Responder auf dem Hacker-Client und das Opfer verbindet sich mit ihm. Damit es in unserem Fall funktioniert, setzen Sie SMB, HTTP und HTTPS in der Konfigurationsdatei auf „Off“.

Anschliessend kann der Responder und das NTLMRelayx-Skript wie oben beschrieben am Hacker-Client (192.168.80.129) gestartet werden.

Greift nun das Opfer 1 (192.168.80.101) auf eine Freigabe auf einem Server zu, welche es nicht gibt, gibt sich der Hacker-Client (192.168.80.129) als diesen aus.

Dabei teilt der Hacker-Client (192.168.80.129) dem Opfer 1 (192.168.80.101) mit, dass der Server DONTEXIST unter seiner eigenen IP-Adresse (192.168.80.129) erreichbar ist.

Das Ergebnis ist gleich wie oben. Das Opfer 1 authentifiziert sich am Hacker-Client (192.168.80.129), der Hacker-Client leitet die Authentifizierung an Opfer 2 (192.168.80.128) und dieser führt wieder unsere exe-Datei aus.

Als Ergebnis haben wir wieder eine Reverse Shell mit vollem Zugriff auf Opfer 2 (192.168.80.128).

Die Reverse Shell ist nur ein Beispiel. Grundsätzlich können alle Befehle ausgeführt werden, welche der authentifizierte Benutzer ausführen kann.

Schutzvorkehrungen

Wie bei allem in der IT-Security, gibt es mehrere Ansatzpunkte, um sich gegen so einen Angriff zu schützen.

Unprivilegierter Benutzer-Account

Fangen wir mal bei der Berechtigung des Benutzers an. Wird nur mit einem unprivilegierten Benutzer gearbeitet, kann dieser nicht ohne weiteres auf die Standard Freigaben (ADMIN$, C$) zugreifen oder jeden Befehl auf dem System ausführen. Wie bei folgendem Bild ersichtlich ist, kann sich der unprivilegierte Benutzer authentifizieren. Ein Zugriff auf die Standard Freigaben hat dieser aber nicht.

Antivirenlösung

Auf jedem System gehört eine Antivirenlösung installiert. Ist eine Antivirenlösung installiert, wird es schon wesentlich schwieriger eine Reverse Shell zu erstellen, die nicht erkannt wird.

Freigabeberechtigung

Erstellen Sie ein Freigabe- und Berechtigungssystem. Schränken Sie den Zugriff auf die Freigaben so weit wie möglich ein. Geben Sie nur Schreib-Rechte, wenn diese wirklich benötigt werden. Sind die Berechtigungen auf einer Freigabe richtig gesetzt, kann nicht ohne weiteres eine Datei auf die Freigabe gelegt werden.

SMB-Signierung

Und zum Schluss haben wir die umgeleitete Netzwerkauthentifizierung. Werden SMB-Pakete signiert, können diese nicht mehr für einen SMB-Relay-Angriff verwendet werden.

Hierzu gibt es vier wichtige Security Options (Computer Configuration\Polices\Windows Settings\Security Settings\Local Policies/Security Options). Diese können an jedem System über die Local Policies oder mittels Gruppenrichtlinien konfiguriert werden. Standardmässig sind die „Microsoft network server“-Richtlinien nur für Domain Controller gesetzt.

Jedes Windows System hat eine SMB-Client- sowie einen SMB-Server-Dienst. Greift das Windows System auf Ressourcen (Ordner oder Drucker) eines anderen Systems, wird der Workstation-Dienst (SMB-Client) verwendet. Werden Ressourcen vom System für andere freigegeben, wird der Server-Dienst (SMB-Server) verwendet.

Verbindet sich nun ein SMB-Client mit einem SMB-Server, wird verhandelt, ob SMB-Signaturen verwendet werden sollen oder nicht.

Die „Microsoft network client“-Richtlinien steuern das Verhalten des Workstation-Dienstes. Und die „Microsoft network server“-Richtlinien steuern das Verhalten des Server-Dienstes.

Wir empfehlen Ihnen, alle vier Richtlinien für alle Systeme zu setzen. So wird dem Workstation- sowie dem Server-Dienst die digitale Signierung vorgeschrieben.

Hinweis:

Werden „always“- und „if client agrees“-Richtlinien gleichzeitig definiert, überwiegen die „always“-Richtlinien.

Beachten Sie auch, dass diese Einstellungen bedacht konfiguriert werden müssen. Gibt es Nicht-Microsoft-SMB-Implementierungen, wie beispielsweise SAMBA, kann es zu Problemen kommen.

Ist die SMB-Signierung aktiviert, wird die Authentifizierung zwar durchgeführt, einen Zugriff bekommt der Hacker aber nicht.