SecCore Essentials - SMB Security

Zusammenfassung

Dieser Blogeintrag zeigt Probleme auf, die entstehen können wenn Sicherheitseinstellungen für das Server Message Block (SMB) Protokoll nicht korrekt vorgenommen wurden. Um dieses SecCore Essential zu implementieren, müssen die folgenden Punkte umgesetzt werden:

• SMBv1 global deaktivieren¹
• SMB Signing muss auf allen Client- und Serversystemen erzwungen werden²
  • GPO Einstellung Microsoft network client: Digitally sign communications (always) auf Enabled
  • GPO Einstellung Microsoft network server: Digitally sign communications (always) auf Enabled

Einleitung

Das Server Message Block Protokoll ist ein Netzwerkfreigabeprotokoll, das vorwiegend von Microsoft Windows Systemen eingesetzt wird. SMB wird hauptsächlich zum Austausch von Dateien verwendet, es können jedoch auch Befehle über dieses Protokoll ausgeführt werden (sogenannte Remote Code Execution), sofern administrative Berechtigungen bestehen.

Jedes Microsoft Windows Betriebssystem hat sowohl einen SMB Client (um auf Dateien zuzugreifen) als auch einen SMB Server (um Dateien freizugeben) eingebaut und aktiviert. Diese Tatsache macht SMB ein lohnenswertes Ziel für einen Angriff, da es fast überall verfügbar ist. Es eignet sich besonders gut für Lateral Movement, bei dem von einem System zum nächsten gesprungen wird.

Häufige Angriffsvektoren

Der folgende Abschnitt gibt einen Überblick über Angriffe auf das SMB-Protokoll.

SMBv1

SMBv1 ist die erste Version des SMB Protokolls, welches bereits 1983 eingeführt wurde und alle notwendigen Funktionen wie Datei- und Druckerfreigabe abdeckte. Heutzutage gilt es aufgrund mehrerer kritischer Schwachstellen³ als starkes Sicherheitsrisiko. Microsoft selbst hat SMBv1 bereits als veraltet eingestuft und empfiehlt, dieses auf allen Systemen zu deaktivieren⁴.

SMB Signing

SMB Signing ist ein Sicherheitsfeature, welches Kommunikation über das SMB-Protokoll digital signiert. Dies verhindert effektiv Man-in-the-Middle Angriffe wie NTLM Relaying. Wurde SMB Signing nicht konfiguriert, kann SMB-Datenverkehr in einem Netzwerk abgefangen und verändert werden.

Dies funktioniert deshalb, weil das SMB Protokoll die Payload (zum Beispiel auf welche Datei zugegriffen werden soll) nicht verschlüsselt oder signiert. Wird also eine Authentifizierung von einem Client abgefangen, kann diese mit einer gänzlich anderen Payload kombiniert und auch auf ein anderes Zielsystem weitergeleitet werden.

SMB Signing kann sowohl für den SMB-Client als auch den SMB-Server aktiviert werden und sollte für beide stets erzwungen werden².

SMB Gastzugriff

Der SMB Gastzugriff ermöglicht es, ohne Authentifizierung auf freigegebenen Ressourcen zuzugreifen. Es handelt sich hierbei um ein Legacy-Feature, welches in alten Microsoft Windows Netzwerken verwendet wurde, um Dateien einfacher austauschen zu können ohne eine Domäne zu benötigen.

Diese Einstellung erlaubt es jedoch jedem System im Netzwerk, Informationen und Dateien aus SMB-Freigaben auszulesen und sollte daher nicht mehr verwendet werden.

Angriffsszenario

Dieser Abschnitt demonstriert, wie fehlendes SMB Signing dazu führen kann, Anmeldungen von einem Computer zu einem anderen weiterzuleiten und auf diesem auf Dateien zuzugreifen und beliebige Befehle auszuführen.

Das Angriffsszenario wurde wie folgt aufgebaut:

• SMB-Signing wird auf keinem System erzwungen
• Eine gültige Authentifizierung wurde bereits von einem anderen System abgefangen
  • Wie dies erreicht werden kann wird in unserem Network Protocols Essential Blogeintrag beschrieben

Das Netzwerk besteht in diesem Szenario aus drei Systemen:

Zur einfacheren Veranschaulichung ist das Angriffssystem ein GNU/Linux Computer mit Netzwerkzugang. Der Angriff kann jedoch ohne weiteres auf einem kompromittierten Microsoft Windows System, beispielsweise mithilfe von PowerShell durchgeführt werden.

Der Server SRV1.lab.local fungiert hierbei als Quellsystem, welches eine Authentifizierung an das Angriffssystem sendet. Der Server SRV2.lab.local wird das Ziel der Weiterleitung darstellen.

Mithilfe des Tools ntlmrelayx.py⁵ können Anmeldungen abgefangen und weitergeleitet werden. Dabei ist es auch möglich, die Payload zu verändern. Es kann im Hintergrund ausgeführt werden und sammelt sämtliche Anmeldeversuche über das SMB Protokol (sowie weitere). Wird eine erfolgreiche Anmeldung abgefangen, so wird diese sofort an das definierte Zielsystem weitergeleitet:

ntlmrelayx.py -t 192.168.30.137 -smb2support -socks

Um eine Anmeldung des SRV1.lab.local Systems erfolgreich abfangen zu können, werden verschiedene Besonderheiten in Netzwerkprotokollen ausgenutzt. Wie dies funktioniert übersteigt jedoch den Umfang dieses Blogeintrags. Es kann im Network Protocols Essential Angriffspfad nachgelesen werden. Stattdessen wird das Angriffssystem 192.168.30.130 direkt von SRV1.lab.local aufgerufen:

Dies löst eine Anmeldung vom System SRV1.lab.local (192.168.30.134) als der Account t1claire@lab.local zum Angriffssystem aus, welche abgefangen und an SRV2.lab.local (192.168.20.137) weitergeleitet wird: Um die Berechtigungen von t1claire@lab.local zu überprüfen, kann der socks Befehl innerhalb der ntlmrelayx.py Konsole verwendet werden: Dadurch dass die abgefangene Anmeldung lokale Administratorrechte auf SRV2.lab.local besitzt, können alle Dateien ausgelesen, beliebige Befehle ausgeführt oder lokale Anmeldedaten mit Tools wie secretsdump.py⁶ ausgelesen werden: Nachdem der lokale Administrator-Hash erlangt wurde, kann SRV2.lab.local vollständig kompromittiert werden, indem Befehle über das Netzwerk mit NetExec⁷ ausgeführt werden:

Gegenmaßnahmen

Der beschriebene Angriffspfad kann durch die Konfiguration der Maßnahmen in der Zusammenfassung verhindert werden. Es kann zwar eine Anmeldung vom System SRV1.lab.local abgefangen, allerdings nicht an SRV2.lab.local weitergeleitet werden, da der SMB-Server die digitale Signatur der Anmeldung verlangt und überprüft: