© Oleksii Lishchyshyn / 123RF.com

WSL soll die Produktivität verbessern, indem Anwendungen und Dienstprogramme aus Linux in die Windows-Umgebung einfließen. Das wirkt sich jedoch zwangsläufig auch auf die Sicherheit aus. Unter Cyberkriminellen kursieren einige Taktiken, Techniken und Prozeduren, die sich WSL als Einfallstor zunutze machen.

Als Kompatibilitätsschicht erlaubt das Windows Subsystem for Linux (WSL), Linux-Binärdateien direkt unter Windows unverändert auszuführen. Anwenderinnen rufen mit WSL Prozesse in Linux von Windows aus auf und umgekehrt, greifen auf Dateien in beiden Betriebssystemen zu, nutzen gemeinsam Umgebungsvariablen und verknüpfen verschiedene Befehle miteinander.

Es gibt zwei WSL-Versionen [1], deren Architekturen sich erheblich unterscheiden: WSL1 bedient sich einer Übersetzungsschicht, die Linux-Systemaufrufe auf dem Windows-Kernel implementiert. Das lässt sich mithilfe von minimalen Pico-Prozessen und -Anbietern erreichen (»lxss.sys« und »lxcore.sys«), die ein Kernel-Modus-Treiber verwaltet. Auf dem WSL-Blog informiert Microsoft über weitere Einzelheiten zur Rolle und Geschichte der Pico-Prozesse [2]. Bei WSL2 wird der Quellcode des Linux-Kernels dagegen in einer virtuellen Maschine ausgeführt, deren Größe Windows je nach Nutzung dynamisch skaliert [3].

WSL befindet sich noch in der Anfangsphase, doch Microsoft entwickelt das Projekt aktiv weiter und ergänzt zusätzliche Funktionen wie jüngst die GUI-Unterstützung für eine vollständig integrierte Desktop-Erfahrung [4]. Das erklärte Ziel von WSL besteht darin, Nutzern das Verwenden ihrer bevorzugten Linux-Tools unter Windows zu ermöglichen. Das WSL lässt sich allerdings auch zu Angriffszwecken missbrauchen. Dazu greifen Cyberkriminelle auf diverse Taktiken, Techniken und Prozeduren (TTPs) zurück.

TTP 1: Dienstprogramme

Angreifer umgehen die eigentlich erforderliche Eingabe eines Sudo-Passworts, indem sie das Argument »-u root« an »wsl.exe« übergeben. Deshalb gelingt es ihnen unter WSL wesentlich leichter, Dienstprogramme zu installieren. Sie laden beliebige Tools herunter und setzen sie ein, um ihre Payloads auszuführen oder zu erstellen. Außerdem können Cyberkriminelle Repositories von Hacking-Distributionen hinzufügen, um über die Paketinstallation Tools zu implementieren.

Sehen wir uns ein einfaches Beispiel für diese Technik an. Dabei kommt die PowerShell zum Einsatz, die sich interessanterweise auch unter Linux installieren lässt (Abbildung 1). Noch dazu können Sie das Tool einfach aus dem Microsoft-eigenen Repository herunterladen. Das offenkundige Problem bei dieser Technik besteht darin, dass »pwsh« unter Linux ausgeführt wird. Entsprechend stehen einige Cmdlets nicht zur Verfügung, zum Beispiel die für das Common Information Model (CIM) und die Windows Management Instrumentation (WMI). Angreifer können jedoch von WSL aus mit der PowerShell Remote-Befehle ausführen oder die PowerShell über SSH verwenden, um auf Windows-spezifische Cmdlets zuzugreifen. Dadurch umgehen sie zudem die PowerShell-Skript-Protokollierung.

Abbildung 1: Die PowerShell läuft zwar unter Linux, was allerdings unter anderem das Problem fehlender Cmdlets mit sich bringt.

Die wahre Stärke dieser Angriffstechnik zeigt sich jedoch woanders: Hacker können modulare Lader entwickeln, die sich vollständig in WSL befinden. Anschließend nutzen sie die Interoperabilität aus, um Windows-Module auszuführen, die sie für ihre Ziele benötigen. Tatsächlich verschwindet der Lader auf diese Weise komplett vom Radar der meisten Sicherheitslösungen. Bereits seit einigen Jahren tauchen immer wieder Cyberangriffe auf, die sich genau diesen Umstand zunutze machen [5]. Das ist also ein weiteres Instrument im Arsenal der Angreifer, das die Cyberabwehr jetzt berücksichtigen muss.

Diese TTP einzudämmen fällt häufig schwer, da es sich beim Installieren von Dienstprogrammen grundsätzlich um einen legitimen Anwendungsfall handelt. Trotzdem lassen sich potenziell böswillige Aktivitäten identifizieren, indem Sie beispielsweise Perimeterlösungen mit einer Anomalieerkennungsfunktion einsetzen. Dazu gehören das Identifizieren des Zugriffs auf Hacking-Repositories und die Überprüfung, ob der betreffende Host einen legitimen Anwendungsfall dafür aufweist.

TTP 2: Angriffs-Distro einschleusen

Um eigene Distributionen in WSL zu installieren, stehen Angreifern zwei Wege offen: Entweder importieren sie eine TAR-Datei oder installieren die Distribution direkt aus dem Microsoft Store. Grundsätzlich kann es sich um beliebige Linux-Varianten handeln, die nicht aus dem offiziellen Microsoft Store stammen müssen. Alternativ erstellt der Angreifer ein eigenes Linux-Derivat für WSL mit bekannten Bedrohungen und Tools [6].

Der Befehl aus Listing 1 bindet eine Distribution in WSL ein. Über den Microsoft Store können Sie derzeit eine ganze Reihe von Linux-Spielarten beziehen (siehe Kasten “Distributionen im Microsoft Store”). Dabei fällt auf, dass die beliebte Penetration-Testing-Distribution Kali Linux sich ebenfalls im Store findet. Das bedeutet, dass sich jeder Windows-Rechner mit WSL in der IT-Umgebung potenziell in einen Kali-Rechner verwandeln lässt. Mit Win-KeX bietet Kali unter WSL2 eine vollwertige Desktop-Oberfläche [7]. Zudem hat Microsoft eine Vorschau der WSL2-Unterstützung für das Ausführen von Linux-GUI-Anwendungen veröffentlicht [8].

PS> wsl --import Distro \ Installationsort Datei

Das Entschärfen eines solchen Angriffs würde weitgehend auf Systemrichtlinien beruhen, die das Aktivieren der für die Installation von WSL erforderlichen Funktionen verweigern. Dürfen Benutzer WSL verwenden, kann sich der Admin auf Befehlszeilenerkennungen verlassen, um potenziellen Installationsaktivitäten auf die Spur zu kommen.

TTP 3: Ausführung umleiten

Das Windows-Dienstprogramm »doskey.exe« [9] dient dazu, den Befehlszeilenverlauf aufzurufen, die Befehlszeile zu bearbeiten und Makros zu erstellen. Spannend ist dabei, dass Makros hier Vorrang vor der »PATH«-Systemvariablensuche haben. Daher setzen Cyberkriminelle sie ein, um den Ausführungsprozess zu unterbrechen.

Makros sind jedoch instanzgebunden. Damit sie über alle »CMD«-Instanzen hinweg bestehen bleiben, müssen Sie eine Makrodefinitionsdatei erstellen und sie je nach verwendeter Windows-Version dem »AutoRun«-Wert unter einem der beiden Schlüssel aus Listing 2 hinzufügen. Alternativ lassen sich Makros mit dem Befehl aus Listing 3 exportieren. Das Umleiten der Ausführung auf Linux kann zur Persistenz über gepatchte Binärdateien führen.

HKEY_CURRENT_USER\Software\Microsoft\Command Processor
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor

PS> doskey.exe /macros > Datei

Sehen wir uns ein solches Szenario mit SSH-Umleitung an. Windows nutzt OpenSSH, der dafür nötige Client ist in Windows 10 vorinstalliert [10]. Selbst wenn SSH fehlt, kann der Angreifer wie in Abbildung 2 gezeigt ein SSH-Makro erstellen und an WSL umleiten. Dann erreicht er Persistenz, indem er die Makros exportiert und anschließend die erforderlichen Registry-Änderungen vornimmt.

Abbildung 2: Auch ohne SSH lassen sich dafür Makros erstellen und an WSL umleiten.

Linux hat mehrere SSH-Backdoors [11]. Zu den beliebten Hintertüren zählt die Universal SSH Backdoor, die SSH und die zugehörigen Bibliotheken patcht, um SSH-Anmeldungen mit einem vom Angreifer festgelegten Passwort zu ermöglichen. Die gepatchte SSH-Binärdatei zeichnet außerdem die Benutzernamen, Kennwörter und IP-Adressen aller eingehenden und ausgehenden SSH-Anfragen als Klartext in Log-Dateien auf. Sobald sich ein Windows-Anwender mit SSH bei einem Remote-Computer anmeldet, liegen seine Anmeldedaten offen und werden in WSL protokolliert. Anschließend nutzen Angreifer diese Anmeldeinformationen für laterale Bewegungen.

Bestehende Sicherheitslösungen sollten auf den Einsatz von »doskey.exe« und die entsprechenden Änderungen in der Registrierung reagieren. Eine gepatchte Binärdatei lässt sich jedoch nicht so einfach auf Anhieb erkennen. Dazu müsste der Verteidiger eine Prüfung der installierten Komponenten (»rpm -Va«) innerhalb der WSL-Distributionen ablaufen lassen. Eine andere Methode besteht darin, beliebte Community-Tools wie Rootkit Hunter einzusetzen, um möglicherweise bösartigen Code zu identifizieren.

Threat Hunting bei WSL

Zunächst einmal wirkt das Einsetzen von WSL in einer Umgebung generell verdächtig, wenn es nicht zu den dort normalerweise genutzten Entwicklerwerkzeugen gehört. Sie sollten die Umgebung auf Befehlszeilen überwachen, in denen »wsl.exe« und »bash.exe« vorkommen. Daneben kann das Nutzen von DISM oder PowerShell zum Aktivieren von WSL- oder Virtualisierungsfunktionen auf Angriffsverhalten hindeuten.

Sysadmins können WSL-Bedrohungen mithilfe von Richtlinien für optionale Funktionen eindämmen. Sie sollten Virtualisierung und WSL mit dem PowerShell-Cmdlet »Disable-WindowsOptionalFeature« oder dem Dienstprogramm DISM deaktivieren. Darüber hinaus können Admins die Aufgabe Windows Features aktivieren oder deaktivieren ausblenden, indem sie den Wert »NoWindowsFeatures« in den Registry-Pfaden aus Listing 4 auf »1« setzen. Zu guter Letzt senkt das Protokollieren und Überprüfen von Prozessen durch Tools wie Endpoint Detection and Response (Abbildung 3) ebenfalls potenzielle Risiken.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Programs
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Programs

Abbildung 3: Mithilfe von Endpoint Detection and Response (EDR) lässt sich die Bedrohung durch WSL-Schwachstellen eindämmen.

Fazit

Das Windows Subsystem for Linux ist eine nützliche Technologie, die die Produktivität verbessern soll, indem sie Anwendungen und Dienstprogramme aus verschiedenen Distributionen in die Windows-Umgebung integriert. Ein solch umfangreiches Projekt beeinflusst jedoch zwangsläufig auch die Sicherheit. Da sich die Angreifer für WSL interessieren, um nach neuen TTPs Ausschau zu halten, müssen sich die Verteidiger entsprechend schützen. (csi/jlu)