Привет, Хабр. В преддверии старта курса «Administrator Linux. Professional» публикуем продолжение статьи про WSL эксперименты, которую написал наш эксперт — Александр Колесников.
Настало время для продолжения экспериментов с подсистемой WSL; первую часть статьи можно посмотреть здесь. В этой части будут представлены более сложные примеры атак, главная задача проводимых экспериментов — проверить, как работает атака и актуальна ли она на момент написания статьи для Windows 10, версии 2004.
В прошлой части статьи мы выяснили, что обмен данными между файловыми системами при использовании технологии WSL осуществляется за счет новых драйверов в ядре операционной системы Windows. На первый взгляд такая архитектура весьма логична, но возникает вопрос — как это работает со стороны ОС Linux? Для того, чтобы это выяснить, изучим init файл внутри дистрибутива Linux, который эмулируется в Windows.
Запустим bash и выполним команду strings над файлом /init. Вывод командной строки частично представлен ниже:
На картинке видно, что вывод команды содержит строки с префиксом
Что такое «9P» и откуда оно взялось?
В 1980 году компания Bell Labs разработала операционную систему «Plan 9». Особенностью этой ОС является возможность объединения нескольких вычислительных систем в одну ОС. Так же в этой операционной системе существует своя концепция понятий «процесс», «устройство» и «файловая система». Для тех, кто хочет изучить особенности Plan 9, предлагаю заглянуть сюда. Нас же интересует реализация файловой системы, которая была предложена данной ОС.
Файловая система реализовывалась за счет протокола, который был назван 9P. Этот протокол предполагает клиент-серверное взаимодействие, причем данные могут быть отправлены посредством обычного сетевого оборудования и не требуется специализированного интерфейса для взаимодействия. В операционных системах Linux так же может быть использован сокет. На данный момент протокол переименован в 9P2000.
Таким образом, можно предположить, что WSL 1 использует этот протокол или его модификацию для работы с файловыми системами. Как это работает?
Проведем небольшое исследование, целью которого будет поиск сетевого интерфейса (в нашем случае — сокета) для взаимодействия файловых систем Windows и Linux:
Похоже, что для взаимодействия файловых систем используется файл
Похоже, что перед нами сокет, который может быть использован для коммуникации между Windows и Linux. Из документации подсистемы WSL мы знаем, что во взаимодействии участвует драйвер
Попробуем удалить файл
Судя по всему, действительно невозможно пользоваться файловой системой Linux из Windows без файла fsserver. Но где же 9P? Для ответа на этот вопрос достаточно сохранить лог ProcMon в XML формате и провести поиск по файлу — «9P» или «P9». В итоге получаем путь к файлу «
Похоже, что разработчики постоянно путают «9P» и «P9»…
Можно ли провести подмену
Для проведения эксперимента необходимо выполнить следующие действия:
Результат представлен на картинке ниже:
Похоже, что ограничения файловой системы не позволяют просто расшарить любую директорию для просмотра. Таким образом, попытка подмены файла
Подсистема WSL 2 так же, как и первая версия WSL, наследует все плюсы и минусы файловой системы Plan 9. Однако теперь полноценное ядро Linux работает как отдельная операционная система, отделенная от Windows средой виртуализации. Исследование возможных уязвимостей в имплементации этой архитектуры могут занять еще несколько десятков статей. Начнем с малого — давайте попытаемся написать сканер для Plan 9 с целью поиска открытых портов на стороне Linux. В качестве базового будем использовать вот этот код.
Основные изменения в коде касаются вводимых значений. Для того, чтобы можно было проводить сканирование, необходимо получить список GUID от работающих версий WSL. GUID используется для доступа к среде Hyper-V, он необходим для создания сокета типа SOCKADDR_HV. На рисунке ниже представлена часть командной строки, которая необходима:
Далее, чтобы просканировать порты, необходимо использовать шаблонный GUID для гостевой Linux —
Полученный сканер может помочь идентифицировать открытые порты для сетевого взаимодействия с Hyper-V контейнером. Результат работы сканера можно использовать для попыток соединения с P9 сервером для атак на него.
Настало время для продолжения экспериментов с подсистемой WSL; первую часть статьи можно посмотреть здесь. В этой части будут представлены более сложные примеры атак, главная задача проводимых экспериментов — проверить, как работает атака и актуальна ли она на момент написания статьи для Windows 10, версии 2004.
WSL 1: файловая система
В прошлой части статьи мы выяснили, что обмен данными между файловыми системами при использовании технологии WSL осуществляется за счет новых драйверов в ядре операционной системы Windows. На первый взгляд такая архитектура весьма логична, но возникает вопрос — как это работает со стороны ОС Linux? Для того, чтобы это выяснить, изучим init файл внутри дистрибутива Linux, который эмулируется в Windows.
Запустим bash и выполним команду strings над файлом /init. Вывод командной строки частично представлен ниже:
На картинке видно, что вывод команды содержит строки с префиксом
N4p9fs*. Похоже, что и в первой версии WSL используется P9 протокол для взаимодействия. Немного подправим вывод:
Что такое «9P» и откуда оно взялось?
P9 файловая система
В 1980 году компания Bell Labs разработала операционную систему «Plan 9». Особенностью этой ОС является возможность объединения нескольких вычислительных систем в одну ОС. Так же в этой операционной системе существует своя концепция понятий «процесс», «устройство» и «файловая система». Для тех, кто хочет изучить особенности Plan 9, предлагаю заглянуть сюда. Нас же интересует реализация файловой системы, которая была предложена данной ОС.
Файловая система реализовывалась за счет протокола, который был назван 9P. Этот протокол предполагает клиент-серверное взаимодействие, причем данные могут быть отправлены посредством обычного сетевого оборудования и не требуется специализированного интерфейса для взаимодействия. В операционных системах Linux так же может быть использован сокет. На данный момент протокол переименован в 9P2000.
Таким образом, можно предположить, что WSL 1 использует этот протокол или его модификацию для работы с файловыми системами. Как это работает?
Linux<->Windows: файловая система
Проведем небольшое исследование, целью которого будет поиск сетевого интерфейса (в нашем случае — сокета) для взаимодействия файловых систем Windows и Linux:
- На Windows машине запустим ProcMon из набора инструментов SysInternals;
- атем запустим
explorer.exe, в адресной строке необходимо прописать\\wsl$\Debian(Ubuntu-18.04). Как только открывается директория, выключаем слежение за событиями и нажимаем в ProcMon последовательность клавиш Ctrl+T. Нас интересует первая операция CreateFile, добавим в фильтр.
Так же стоит добавить фильтр событий по процессу init — процесс, который запускается для настроек ресурсов для WSL. Пример вывода можно увидеть на картинке ниже:
Похоже, что для взаимодействия файловых систем используется файл
fsserver нулевого размера, который используется для операций ввода-вывода. 
Похоже, что перед нами сокет, который может быть использован для коммуникации между Windows и Linux. Из документации подсистемы WSL мы знаем, что во взаимодействии участвует драйвер
lxcore.sys. Заглянем в call stack операции CreateFile в ProcMon:
Попробуем удалить файл
fsserver в ОС Linux. Теперь попробуем открыть в explorer.exe на стороне Windows директорию \\wsl$\Debian:
Судя по всему, действительно невозможно пользоваться файловой системой Linux из Windows без файла fsserver. Но где же 9P? Для ответа на этот вопрос достаточно сохранить лог ProcMon в XML формате и провести поиск по файлу — «9P» или «P9». В итоге получаем путь к файлу «
p9rdr.sys»:
Похоже, что разработчики постоянно путают «9P» и «P9»…
Plan 9 Intercept: атака
Можно ли провести подмену
fsserver? Так как в качестве протокола взаимодействия используется 9P, попробуем «угнать» сокет. Для проведения эксперимента был выбран 9P сервер Diod, который можно найти здесь. Его нужно скачать в операционную систему Linux и собрать, следуя инструкциям из Readme. Для проведения эксперимента необходимо выполнить следующие действия:
- В командной строке Windows ввести команду
bash. - Запустить P9 сервер на файле, который можно найти в директории LocalState установленного дистрибутива в WSL:
diod -n -f -d3 -e /tmp/doesnotexist -l /mnt/c/Users//AppData/Local/Packages/TheDebianProject.DebianGNULinux_76v4gfsz19hv4/LocalState/fsserver
Открыть в explorer UNC путь\\wsl$\Debian
Результат представлен на картинке ниже:
Похоже, что ограничения файловой системы не позволяют просто расшарить любую директорию для просмотра. Таким образом, попытка подмены файла
fsserver не удалась.Plan 9: WSL 2
Подсистема WSL 2 так же, как и первая версия WSL, наследует все плюсы и минусы файловой системы Plan 9. Однако теперь полноценное ядро Linux работает как отдельная операционная система, отделенная от Windows средой виртуализации. Исследование возможных уязвимостей в имплементации этой архитектуры могут занять еще несколько десятков статей. Начнем с малого — давайте попытаемся написать сканер для Plan 9 с целью поиска открытых портов на стороне Linux. В качестве базового будем использовать вот этот код.
Основные изменения в коде касаются вводимых значений. Для того, чтобы можно было проводить сканирование, необходимо получить список GUID от работающих версий WSL. GUID используется для доступа к среде Hyper-V, он необходим для создания сокета типа SOCKADDR_HV. На рисунке ниже представлена часть командной строки, которая необходима:
Далее, чтобы просканировать порты, необходимо использовать шаблонный GUID для гостевой Linux —
{????????-facb-11e6-bd58-64006a7986d3} — первая часть GUID используется как шестнадцатеричное представление порта. Напишем scanner.exe для поиска корректного значения открытого порта через GUID и получаем следующий результат:
Полученный сканер может помочь идентифицировать открытые порты для сетевого взаимодействия с Hyper-V контейнером. Результат работы сканера можно использовать для попыток соединения с P9 сервером для атак на него.
Использованные материалы
- docs.microsoft.com/en-us/sysinternals
- www.tiraniddo.dev/2019/07/digging-into-wsl-p9-file-system.html
