Новый обход контроля учетных записей (UAC) на Windows

Всем привет!

Во время исследований некоторых новых методов обхода службы контроля учетных записей (UAC) я открыл совершенно новый метод обхода UAC на момент написания этой статьи. Стоит отметить, что Microsoft не считает UAC границей безопасности, однако мы до сих пор сообщаем о разных багах в Microsoft и я хочу поделиться подробностями найденной мной уязвимости тут. Этот метод был успешно протестирован на ОС Windows 10 Build 17134. До того, как я погружусь в подробности моей находки, я сначала представлю Вам небольшое пояснение по работе самой службы UAC.

UAC Primer

Когда пользователь, входящий в группу «Администраторы», хочет запустить приложение, требующее повышенных привилегий, то UAC отображает соответствующий запрос и пользователю, являющемуся членом группы «Администраторы», потребуется подтвердить действие Однако, этот запрос UAC не возникает для ВСЕХ административно исполняемых файлов в Windows. Есть несколько исключений, которые будут «автоматически» повышать привилегии исполняемого файла, не вызывая запроса UAC, в обход UAC (к большому удивлению!). Эта отдельная группа избранных надежных исполняемых файлов проходит дополнительные проверки безопасности системой, чтобы убедиться, что на самом деле эти файлы достоверны, поэтому информационные злоумышленники обычно не злоупотребляют данной функцией. Этот подход использовался в предыдущих методах обхода UAС и будет основой моего нового метода обхода. Однако, есть несколько лазеек, которые нам нужно воспользоваться, чтобы наша атака удалась. Давайте рассмотрим требования, которые должны соблюдаться, если мы хотим, чтобы наш исполняемый файл был «автоматически повышен в привилегиях». Для этого я покажу несколько картинок дисассемблируемой библиотеки appinfo.dll (служба AIS, обрабатывающая запросы на повышение привилегии — один из основных компонентов UAC).

Требование 1: Файл сконфигурирован для автоматического повышения привилегий

Когда возникает запрос на повышение привилегий для программы, то в службе AIS (appinfo.dll) выполняется вызов RPC с целевым исполняемым путем, переданным в качестве аргумента. Затем эта служба будет сопоставлять целевое исполняемое содержимое файла для чтения. В манифесте исполняемого файла делается попытка прочитать значение для получения ключа «autoElevate» (если он существует).

Рисунок 1 – Чтение манифеста исполняемого файла для получения значения ключа «autoElevate».

Если значение получено и это «Истина», то файл будет считаться как с «автоматическими» повышаемыми привилегиями исполняемым файлом, который будет запускаться с повышением привилегий и не вызывать диалоговое окно службы UAC (при условии, что оно передало следующие требования, упомянутые ниже).

Рисунок 2 — вызов «bsearch» для проверки имени исполняемого файла в списке исполняемых файлов «auto elevating»

Некоторые из этих жестко запрограммированных в системе файлов в белом списке:

‘cttunesvr.exe’, ‘inetmgr.exe’, ‘migsetup.exe’, ‘mmc.exe’, ‘oobe.exe’, ‘pkgmgr.exe’, ‘provisionshare.exe’, ‘provisionstorage.exe’, ‘spinstall.exe’, ‘winsat.exe’

Требование 2: Правильно подписанные

Предполагается, что второе условие для «автоматического» повышения привилегии после отправки запроса в UAC, это выполнение проверки подписи с помощью «wintrust! WTGetSignatureInfo».

Это означает, что злоумышленник не сможет просто создать свой собственный нужный для «автоматического» повышения привилегий манифест или исполняемый файл и добиться успеха, поскольку бинарный файл злоумышленника, скорее всего, будет неправильно подписан, и, вероятно, также не будет выполняться последнее требование — исполнение из надежного каталога\директории.

Требование 3: Исполнение из надежного каталога\директории

Последнее требование для получения «автоматического» повышения привилегий заключается в том, что целевой исполняемый файл находится в «доверенном каталоге», например «C: \ Windows\System32». На Рисунке 3 показано, что служба AIS выполняет эту проверку пути с запросом на повышение, в этом случае одним из путей, считающихся «доверенным», является «C:\Windows\System32».

Рисунок 3

Название этой статьи «Обход контроля учетных записей (UAC) путем пародирования доверенных директорий», поэтому Вы, вероятно, сможете легко догадаться, что будет дальше.

Обход UAC

Как упоминалось ранее в разделе UAC Primer, автопривилегированность (обход UAC) будет выполняться для исполняемых файлов, которые:

1. Сконфигурированы для получения «автоматического» повышения привилегий
2. Правильно подписаны
3. Запускаются из надежного каталога («C:\Windows\System32»)

Appinfo.dll (AIS) использует API RtlPrefixUnicodeString, чтобы проверить, соответствует ли исполняемый путь файла с «C:\Windows\System32\» для проверки одного из доверенных каталогов. Это довольно железобетонная проверка, учитывая ее сравнение с каноническим местом расположения файла.

Поэтому, для организации обхода этой проверки я создаю каталог под названием «C:\Windows \» (обратите внимание на пробел после «Windows»). Конечно, с помощью этого действия все еще нельзя пройти проверку RtlPrefixUnicodeString, и я также упомяну, что это несколько недопустимое (или, по крайней мере, «недружелюбное») имя каталога, поскольку Windows не разрешает ставить пробелы в конце имени при создании каталога (попробуйте).

Однако, используя API CreateDirectory и добавив «\\? \» к имени каталога, которое я хочу создать, мы можем обойти некоторые из этих правил фильтрации имен и отправить запрос на создание каталога непосредственно в файловую систему.

Это приводит к созданию неудобного каталога, который счастливо сосуществует в файловой системе наряду с реальным «C:\Windows\» (за исключением тех случаев, когда Вы пытаетесь что-либо сделать с ним в Проводнике Windows).

Теперь, когда у нас есть каталог «C: \Windows \», мы можем создать в нем каталог «System32» и скопировать туда один из подписанных, исполняемых файлов (у которого разрешено системой «автоматическое» повышение привилегий) из реального каталога «C:\Windows\System32».

Для этого я скопировал «winSAT.exe» (один из файлов в белом списков исполняемых файлов Windows с разрешённом системой возможности «автоматического» повышения привилегий).

Когда мы попытаемся запустить этот файл из нашего нового каталога «C:\Windows \System32\ winSAT.exe», он будет проходить через следующие API (см. Рис. 6) в appinfo.dll перед выполнением проверки доверенного каталога. Это важно, и основа того, почему этот обход работает.

Рисунок 6

Когда этот неудобный путь с пробелом отправляется в AIS для запроса на повышение привилегий, путь передается в GetLongPathNameW, который преобразует его обратно в «C:\Windows\System32\winSAT.exe» (пробел удален).

Отлично!

Теперь это строка, в которой прошла проверка достоверного каталога (используя RtlPrefixUnicodeString) для остальной части проверки.

Красота моего решения заключается в том, что после проверки доверенного каталога выполняется этот преобразованный путь, который потом освобождается, а остальные проверки (и окончательный запрос на повышение привилегий) выполняются с оригинальным названием исполняемого каталога (с дополнительным пробелом).

Это позволяет пройти все другие проверки и приводит к тому, что appinfo.dll принимает мою копию winSAT.exe как с «автоматическим» повышением привилегий (так как она правильно подписана и добавлена в белый список для «автоматического» повышения привилегий).

Чтобы на самом деле использовать вредоносный код, я просто скопировал поддельную WINMM.dll (импортированную winSAT.exe) в своем текущем каталоге «C:\Windows \System32\» для локального захвата dll. Полную концепцию можно увидеть на рисунке ниже.

Рисунок 7.

→ Ссылка на Github

by it_ha