Nach dem Absichern ist vor dem Absichern. Deshalb möchte ich heute das Thema “SMB” wieder aufgreifen. In unserem Blog: “SMB Relay Angriff” hat Ihnen Marius Hamborgstrøm aufgezeigt, was die Gefahren sind, wenn SMB-Pakete innerhalb eines Netzwerks nicht signiert sind. Marius zeigte auf, wie ein Angreifer SMB-Pakete abfangen oder umleiten kann, um diese danach entweder zu entschlüsseln oder diese weiterzuleiten, um eine Anmeldesession aufzubauen. Mit der richtigen Einstellung in den Gruppenrichtlinien, kann den Angreifern ein weiterer Angriffsvektor entzogen werden. Gehen wir jedoch davon aus, dass sich ein Angreifer bereits innerhalb unseres Netzwerks befindet, kann er nun zwar keine SMB-Anmeldungen mehr für sich verwenden, jedoch bleibt ein Problem bei SMB offen. Standardmässig ist das Protokoll unverschlüsselt!

Der Angriff

Wenn sich also ein Angreifer schon im Netzwerk befindet, kann er mit einfachen Mitteln wie einem ARP-Spoofing, die Datenpakete auf Layer-2-Ebene über sein Device leiten. Nehmen wir also an, ein mit all den Passwörtern überforderter Mitarbeitender hat auf seinem persönlichen Share eine Liste Namens mySecrets.txt mit seinen Passwörtern gespeichert…

… sieht der Angreifer mittels der MitM-Attacke den Inhalt der Datei, also auch die Passwörter.

Dies ist natürlich nur so bequem ersichtlich, da es sich bei der Datei um eine einfache Textdatei handelt, in welcher die Daten im Klartext gespeichert sind. Aber auch im Falle eines mit Passwörter versehenen Excels ist es für einen Angreifer nicht so schwierig, an die Passwörter zu gelangen.

Mit der Networksniffing Applikation WireShark können die Datenbytes exportiert werden. Dabei muss vorab zuerst das richtige Pakete ausgewählt werden, welches auf den Request (Read Request Len:xxxx Off:x File: [Filename]) folgt (Read Response).

In diesem Szenario, ist ein Excel mit dem Titel “passwords.xlsx”. Dass es sich bei der übertragenen Datei um ein XLSX handelt, sieht der Angreifer einerseits in der Request-Info, andererseits deutet der Anfang der Datei “[Content_Type].xml“ ebenfalls darauf hin.

Die entsprechend erstellte Excel-Datei kann wiederum mit der Office-Applikation geöffnet werden.

Nun haben Sie ja recht: Passwörter sollten weder in einer Text-, noch in einer unverschlüsselten Excel-Datei gespeichert werden. Nur ein Passworttresor ist die richtige Lösung – haben wir ja auch schon einmal empfohlen, siehe Ein Passwort für alles. Aber auch eine Passworttresor-Datenbank kann bei einem unverschlüsselten Protokoll abgefangen werden.

In unserem Beispiel handelt es sich um eine KeePass-Datenbank. Diese kann gleich einfach exportiert werden, wie ein Excel.

Nun steht der Angreifer nur noch vor der Herausforderung, an das Masterpasswort zu gelangen. Hier kann er verschiedene Methoden wählen, zum Beispiel einen Phishing-Angriff auf die IT-Abteilung. Wir wählen jedoch den Ansatz des brutalen drauf losschiessens, mittels einer Brute-Force-Attacke. Da der Angreifer nun im Besitz der Datei ist, kann er dies offline machen, mit soviel Anfragen wie er will, ohne dass ein IDS/IPS-System darauf reagieren könnte.

Als erstes muss er sich von der Datei den Hash des Masterpassworts ausstellen. Dies kann einfach mit einem Tool namens keepass2john gemacht werden.

Die Brute-Force-Attacke wird in unserem Beispiel mit der Applikation John durchgeführt. Als Wörterliste, welche bei einer Brute-Force-Attacke nie fehlen darf, habe ich mich für die 2021 erschienene rockyou2021 entschieden. Die Datei selbst ist 92 GB gross und beinhaltet 8.4 Billionen Passwörter.

In dieser Liste sind auch hochkomplexe Passwörter vorhanden, wie das bei meinem Test verwendete !#%&(_Ghjkl;Iop[]!#%&(_Ghjkl;Iuytre

Und so kommt der Angreifer auch in die Hände der IT-Passwörter und ist nun Herr der IT-Infrastruktur.

Doch dieser Blog wäre nicht von der goSecurity, wenn ich Ihnen nicht auch noch verraten würde, wie Sie sich davor schützen können.

Die Abwehr

Ausflug in die Geschichte

Als SMB 1.0 1984 erschienen ist, waren Sicherheitsüberlegungen noch gar nicht im Fokus. Es war halt eine andere Zeit. Zum Glück wird dieses veraltete Protokoll seit der Windows 10 und Server Version 1709 gar nicht mehr installiert. Und ich kann auch nur empfehlen, dies so zu belassen.

Eine Möglichkeit SMB zu verschlüsseln, kam erst 2012 mit der Version 3.0. Mit der Version 3.1.1 wurden neu die Ciphers AES-128-GCM und AES-128-CCM unterstützt, unter Windows 11 und Windows 2022 sogar AES-256-GCM und AES-256-CCM. Standardmässig wird gemäss Microsoft noch immer AES-128-GCM verwendet, da dies die beste Performance/Security-Balance bringt. Unter einem Windowssystem kann der verwendete Cipher jedoch auch geändert werden.

Set-SmbServerConfiguration -EncryptionCiphers "AES_256_GCM"

Aus Sicht der IT-Sicherheit, Stand 05. Juli 2023, genügt der Cipher AES-128-GCM jedoch vollkommen.

Umsetzung

Die Verschlüsselung des SMB-Protokolls kann auf einem Windowsserver auf zwei verschiedene Arten umgesetzt werden. Einerseits kann eingestellt werden, dass alle Freigaben eines SMB-Servers verschlüsselt sind. Dazu muss folgender Befehl ausgeführt werden.

Set-SmbServerConfiguration -EncryptData $true

Damit die Verschlüsselung aktiviert wurde, musste ich bei meiner Testumgebung den Service Server neu starten. Vermutlich hätte ein Reboot des Servers ebenfalls genügt.

Danach waren jegliche SMB-Verbindungen von und zum Server verschlüsselt.

Der zweite Ansatz beinhaltet, nicht den gesamten SMB-Server zu verschlüsseln, sondern nur einzelne Freigaben. Dies kann besonders in einer Migrationsphase von Vorteil sein. Der Befehl dazu wäre:

Set-SmbShare -Name "Name des Shares" -EncryptData $true

Ob ein Share verschlüsselt ist, kann mittels dem Command Get-SmbShare -Name "Name des Shares" | select EncryptData überprüft werden.

Nachdem ich nur die Freigabe Share verschlüsselt habe, wurden die Zugriffe auf die restlichen Freigaben ($IPC, Netlogon und Co.) mit dem unverschlüsselten SMB 2.1 aufgebaut.

Wichtig zu wissen ist, dass wenn auf der Stufe des SMB-Server (Set-SmbServerConfiguration) die Verschlüsselung aktiviert wurde, alle Freigaben immer betroffen sind. Dies auch wenn bei einer Freigabe expliziert nochmals der Befehl Set-SmbShare -Name "Name des Shares" -EncryptData $false ausgeführt wird.

Aus Sicht der IT-Sicherheit empfiehlt es sich natürlich immer, die Kommunikation des gesamten SMB-Servers zu verschlüsseln, damit nichts vergessen geht. Mit der Möglichkeit, nur einzelne Shares verschlüsselt ansprechbar zu machen, bietet Microsoft jedoch eine gute Alternative für das Handling mit teilweise noch veralteten Systemen im Netzwerk.

Kompatibilität

Auch von meinem Debiansystem konnte ich mit dem Linuxtool smbclient ohne Probleme mit dem verschlüsselten Share verbinden und Daten herunterladen. Die Kompatibilität ist also auch von einem Linuxclient gegeben.

Ebenfalls gibt es diverse SMB-Server, welche nicht auf Windowsbasis betrieben werden, welche die Verschlüsselung des SMB-Protokolls unterstützen. In meinem Testlab habe ich die Verschlüsselung auf einer Synology-NAS aktiviert.

Bei meinen Recherchen bin ich noch auf weitere SMB-Systeme gestossen, wie NetApp.

Falls Ihnen die Kompatibilität dennoch sorgen bereitet, kann für eine Übergangsphase unter einem Windowsserver auch definiert werden, dass auch Clients auf die Freigabe zugreifen können, welche nicht SMB 3.0 oder höher unterstützen. Dies jedoch nur wieder auf Stufe des gesamten SMB-Servers.

Set-SmbServerConfiguration --RejectUnencryptedAccess $false

Fazit

Aus meiner Sicht steht der Verschlüsselung unserer Shares nichts im Wege. Alle modernen System sind SMB 3.x kompatibel und lassen somit eine verschlüsselte SMB-Kommunikation zu. Und falls Sie dennoch ein altes System haben, welches Sie einfach nicht loswerden, kann dennoch mit den verschiedenen Einstellungen, welche besonders die Windows-SMB-Server bieten, der beste Pfad zwischen Sicherheit und Usability gefunden werden.

Auch beim Thema Performance sehe ich keine Einschränkung mehr, da unsere Rechner immer leistungsfähiger werden. Geben Sie somit der Verschlüsselung eine Chance, Sie können nicht enttäuscht werden.

Quellen

https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-security