Хабрахабр

[Перевод] Обход контроля учетных записей (UAC) путем пародирования доверенных директорий

Эксперт по информационной безопасности Дэвид Уэллс (David Wells) опубликовал способ обхода контроля учетных записей UAC в Windows 10
Всем привет!

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

UAC Primer

Есть несколько исключений, которые будут «автоматически» повышать привилегии исполняемого файла, не вызывая запроса UAC, в обход UAC (к большому удивлению!). Когда пользователь, входящий в группу «Администраторы», хочет запустить приложение, требующее повышенных привилегий, то UAC отображает соответствующий запрос и пользователю, являющемуся членом группы «Администраторы», потребуется подтвердить действие Однако, этот запрос UAC не возникает для ВСЕХ административно исполняемых файлов в Windows. Этот подход использовался в предыдущих методах обхода 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: Правильно подписанные

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

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

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

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

Рисунок 3

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

Обход UAC

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть