SandboxEscaper/PoC-LPE: що всередині?

Here is the alpc bug as 0day: https://t.co/m1T3wDSvPX I don’t fucking care about life anymore. Neither do I ever again want to submit to MSFT anyway. Fuck all of this shit.

— SandboxEscaper (@SandboxEscaper) August 27, 2018

На хабре вже є новина про цю уразливість, але, на жаль, без технічних деталей. Пропоную заглянути всередину опублікованого архіву (автор — 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:windowssystem32tasks. Ймовірно, цей метод призначений для запису DACL’а завдань, розташованих там. Але запис буде відбуватися відбувається після имперсонации. Однак, з деяких причин, реалізація методу так само перевіряє наявність .job-файлу в c:windowstasks і записує йому dacl назад без имперсонации. Оскільки користувач (навіть користувач в групі осіб) може створювати в цій директорії, файли, що ми просто можемо створити hardlink на будь-який інший файл, доступний нам на читання. Використовуючи такий hardlink, ми можемо примусити службу планувальника (исполняющейся з правами SYSTEM) записати довільний dacl назад (дивись другий параметр SchRpcSetSecurity) у файл по нашому вибору.

Таким чином: у будь-якого файлу, доступного на читання, можна змінити dacl назад, що дозволяє повністю його замінити.

Експлуатація уразливості

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

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

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

Друга проблема полягає в тому, що хоча ми можемо отримати контроль над безліччю файлів, запис у них часто неможлива, оскільки ці DLL вже кудись завантажені на виконання. Спроба запису dacl назад для завантаженого на виконання файлу викличе помилку розділяється доступу. Але вразливість можна використовувати і для інших типів файлів, які можуть бути кращою метою, ніж DLL.

Для експлуатації обраний файл C:WindowsSystem32DriverStoreFileRepositoryprnms003.inf_amd64_4592475aca2acf83Amd64printconfig.dll (ім’я директорії може відрізнятися, це враховано в PoC). Схоже цей файл відноситься до принтера XPS і не завантажений в службу друку за замовчуванням (може так вийти, що файл буде завантажений… але найчастіше це не так).

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

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

Демо

В архіві так само можна знайти відео з демонстрацією:
Прихований текст