Главная » Хабрахабр » [Перевод] SandboxEscaper/PoC-LPE: что внутри?

[Перевод] SandboxEscaper/PoC-LPE: что внутри?

На хабре уже есть новость об этой уязвимости, но, к сожалению, без технических деталей. Предлагаю заглянуть внутрь опубликованного архива (автор — SandboxEscaper).

Под катом расположен перевод документа-описания, находящегося в архиве.

Описание уязвимости

Служба Task Scheduler (планировщик задач) имеет RPC-интерфейс (доступный через транспорт ALPC), поддерживающий метод SchRpcSetSecurity.

Так выглядит прототип этого метода:

long _SchRpcSetSecurity( [in][string] wchar_t* arg_1, //Task name [in][string] wchar_t* arg_2, //Security Descriptor string [in]long arg_3);

Задачи, созданные планировщиком задач, создают соответствующую директорию/файл в c:\windows\system32\tasks. Вероятно, этот метод предназначен для записи DACL'а задач, расположенных там. Но запись будет происходить происходит после имперсонации. Однако, по некоторым причинам, реализация метода так же проверяет наличие .job-файла в c:\windows\tasks и записывает ему DACL без имперсонации. Поскольку пользователь (даже пользователь в группе гостей) может создавать в этой директории файлы, мы просто можем создать hardlink на любой другой файл, доступный нам на чтение. Используя такой hardlink, мы можем заставить службу планировщика (исполняющейся с правами SYSTEM) записать произвольный DACL (смотри второй параметр SchRpcSetSecurity) в файл по нашему выбору.

Таким образом: у любого файла, доступного на чтение, можно сменить DACL, что позволяет полностью его перезаписать.

Эксплуатация уязвимости

Эта уязвимость дает нам действительно сильный примитив! Основная проблема заключается в том, что после установки (по умолчанию) многие важные файлы могут быть модифицированы только пользователем TrustedInstaller (но не пользователем SYSTEM).

Просто запустите:
./enumerate.ps1 >output.txt В архиве присутствует powershell-скрипт для перечисления файлов, которые вы можете контролировать.

Вы можете контролировать файлы Program Files и, если ваш целевой файл используется администратором/другим пользователем, перезаписанные вами файлы могу быть запущены с требуемыми привилегиями. В системе есть много целей.

Попытка записи DACL для загруженного на исполнение файла вызовет ошибку разделяемого доступа. Вторая проблема заключается в том, что хотя мы можем получить контроль над множеством файлов, запись в них часто невозможна, поскольку эти DLL уже куда-то загружены на исполнение. Но уязвимость можно использовать и для других типов файлов, которые могут быть лучшей целью, чем DLL.

Похоже этот файл относится в принтеру XPS и не загружен в службу печати по умолчанию (может так получиться, что файл уже будет загружен… но чаще всего это не так). Для эксплуатации выбран файл C:\Windows\System32\DriverStore\FileRepository\prnms003.inf_amd64_4592475aca2acf83\Amd64\printconfig.dll (имя директории может различаться, это учтено в PoC).

Такой вектор атаки (hijacking) может быть легко применен для чего-то получше. А когда мы запустим задание на печать с использованием XPS-принтера, сервис загрузит эту DLL, которую мы можем предварительно переписать. Я могу попытаться найти лучшие варианты… просто дайте мне знать.

Новая версия не удаляет старую, а значит нет гарантии, что FindFirstFile (используемый в PoC) найдет актуальную директорию. Замечание: На старом ноутбуке, где Windows 10 работает уже несколько лет, есть две директории prnms003.inf_amd64_*. Поэтому вы можете расширить код, перезаписав все найденные printconfig.dll или проверить атрибут последней записи в файл и выбрать более новый.

Демо

В архиве так же можно обнаружить видео с демонстрацией:

Скрытый текст


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Мир! Труд! iOS! Да здравствует оффер за 1 день

Мы рады анонсировать hiring event для iOS-разработчиков в московском офисе FunCorp. Всё просто: участник присылает нам тестовое задание до 13 мая, затем мы объявляем результаты участников и приглашаем авторов лучших решений к нам в офис 24 мая (где, собственно, и ...

Wi-Fi 6: что у 802.11ax внутри

В данном случае антенна — это уже не просто «железка», а сочетание аппаратной части и алгоритма выбора конфигурации. Очевидно, что технология MU-MIMO 8×8 должна поддерживаться устройством, а эффективность формирования отдельных пространственных лучей зависит от используемых производителями решений, в частности, направленных ...