[] WSL эксперименты. Часть 2
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, хабр. В преддверии старта курса «Administrator Linux. Professional» публикуем продолжение статьи про WSL эксперименты, которую написал наш эксперт — Александр Колесников.
Настало время для продолжения экспериментов с подсистемой 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
оригинал
Читать ещё:
===========
Источник:
habr.com
===========
Похожие новости:
- [Laravel] Laravel Jetstream. Зачем?
- Выпуск Red Hat Enterprise Linux 7.9 и Oracle Linux 7.9
- [JavaScript, Тестирование мобильных приложений, ReactJS] Моки не кусаются! Осваиваем мокинг с React Testing Library (перевод)
- [Настройка Linux, Open source, Python, *nix, Сетевые технологии] ipipou: больше чем просто нешифрованный туннель
- [Настройка Linux, Программирование, Разработка под Linux] Знакомимся с семафорами в Linux (перевод)
- [Управление продуктом] Как найти и описать платящий сегмент пользователей?
- [*nix, Настройка Linux, Системное администрирование] fork() может глюкануть: это важно (перевод)
- Ubuntu RescuePack, Live-дистрибутив для борьбы с компьютерными вирусами
- [Разработка веб-сайтов, Python, Django] Отношение один к одному: связывание модели пользователя с кастомной моделью профиля в Django (перевод)
- [SQL, Microsoft SQL Server, Администрирование баз данных] Шифрование в MySQL: хранилище ключей (перевод)
Теги для поиска: #_linux, #_wsl, #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:28
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, хабр. В преддверии старта курса «Administrator Linux. Professional» публикуем продолжение статьи про WSL эксперименты, которую написал наш эксперт — Александр Колесников.  Настало время для продолжения экспериментов с подсистемой 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:
 Похоже, что для взаимодействия файловых систем используется файл 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. Для проведения эксперимента необходимо выполнить следующие действия:
Результат представлен на картинке ниже:  Похоже, что ограничения файловой системы не позволяют просто расшарить любую директорию для просмотра. Таким образом, попытка подмены файла 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 сервером для атак на него. Использованные материалы:
 оригинал Читать ещё: =========== Источник: habr.com =========== Похожие новости:
Блог компании OTUS. Онлайн-образование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:28
Часовой пояс: UTC + 5