Поиск уязвимостей повышения привилегий в Windows с помощью Process Monitor

Поискуязвимостейповышенияпривилегийвwindowsспомощьюprocessmonitor


Обзор

Этот пост объяснит, как найти vuls повышения привилегий. в Windows, которые, похоже, никто не ищет, потому что их было довольно легко найти. После объяснения того, как их найти, я расскажу о некоторых средствах защиты, которые могут частично решить проблему разными способами. Но я бы хотел, чтобы разработчики начали искать эти уязвимости так, как я описываю, чтобы они вообще перестали их вводить.

Когда мы впервые выпустили CERT BFF , обычный процесс создания экспериментального эксплойта для уязвимости, связанной с повреждением памяти, был следующим:

  1. Наложите цель до тех пор, пока не получите управление указателем инструкции.
  2. Узнайте, какие байты можно использовать для хранения шелл-кода, используя Минимизация строки BFF .
  3. Использовать ROP по мере необходимости, чтобы изменить поток программы так, чтобы он выполнял ваш шелл-код.

Часто было относительно просто перейти от Начать PoC с CERT BFF . Шло время, и планка для использования уязвимостей, связанных с повреждением памяти, повышалась. Вероятно, это можно объяснить двумя событиями, которые произошли за эти годы:

  1. Повышенный уровень фаззинга сторонами, выпускающими программное обеспечение.
  2. Увеличение количества средств защиты от эксплойтов как в программном обеспечении, так и на платформах, на которых они работают.

Недавно я работал над техникой обнаружения уязвимостей, которая напомнила мне о первых днях BFF. Как в отношении того, насколько легко найти уязвимости, так и в отношении того, насколько легко их можно использовать. На самом деле концепция настолько тривиальна, что я был удивлен, насколько успешно она оказалась в поиске уязвимостей. Так же, как идея перехода непосредственно от фаззинга с BFF к работающему эксплойту с течением времени становилась все менее и менее жизнеспособной, я бы хотел, чтобы было гораздо меньше низко висящих плодов, которые можно легко найти с помощью этой техники.

В этом посте я поделюсь некоторыми своими выводами, а также фильтровать себя для поиска уязвимостей повышения привилегий с помощью Sysinternals Process Monitor (Procmon).

Концепция

Когда программа установлена ​​на платформе Windows, некоторые компоненты он может работать с привилегиями, независимо от того, какой пользователь в настоящее время вошел в систему. Эти привилегированные компоненты обычно имеют две формы:

  1. Установленные службы
  2. Запланированные задачи

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

Что искать

Самый простой способ проверить наличие привилегированных процессов, на которые могут влиять непривилегированные пользователи, – это использовать фильтр Process Monitor, который отображает операции на основе следующих атрибутов:

  1. Файлы или каталоги, которые не существуют.
  2. Процессы с повышенными привилегиями.
  3. Расположение, доступное для записи непривилегированному пользователю.

Проверки 1 и 2 можно тривиально реализовать в Process Monitor. Проверка 3 немного сложнее и может привести к некоторым ложным срабатываниям, если мы ограничим наш инструмент только тем, что можно сделать с помощью фильтра монитора процессов. Но я создал фильтр , который, кажется, неплохо справляется с задачей сделать уязвимости повышения привилегий довольно очевидными.

Использование фильтра

Использование фильтра Privesc.PMF Process Monitor относительно просто:

  1. Включить ведение журнала загрузки Process Monitor (Параметры → Включить ведение журнала загрузки)
  2. Перезагрузитесь и войдите в систему
  3. Запустить монитор процессов
  4. Сохраните журнал загрузки при появлении запроса

  5. Импортируйте фильтр «Privesc» (Фильтр → Упорядочить фильтры → Импорт …)
  6. Примените фильтр Privesc (Фильтр → Загрузить фильтр. → Привеск)
  7. Ищите и исследуйте неожиданные обращения к файлам.

Результаты расследования

Давайте начнем с просмотра журнала загрузки общей базовой линии, с которой мы могли бы иметь дело как аналитик уязвимостей – 0120 – бит Windows 32 9312 система с установленными инструментами VMware:



Даже с в нашей виртуальной машине практически не установлено ПО, мы уже видим что-то подозрительное: C: Program% 86 Файлы

Пользователи Windows могут быть знакомы с путем C: Program Files , но что с % 77 ? Почему может произойти такая файловая операция? Мы рассмотрим причину в следующем разделе.

Ошибки, которые допускают разработчики

Есть ряд ошибок, которые разработчик может сделать это, что может привести к тому, что на привилегированный процесс сможет повлиять непривилегированный пользователь. Ошибки, которые я заметил в отношении уязвимостей простого повышения привилегий в приложениях Windows, делятся на две основные категории:

  1. Доступ к неожиданным путям.
  2. Неожиданные списки управления доступом (ACL), примененные к используемым путям.

Доступ к неожиданным путям

В некоторых случаях во время выполнения программы открывается неожиданный путь. То есть разработчик, вероятно, был бы удивлен, если бы понял, что к пути осуществляется доступ. Эти неожиданные обращения к пути могут быть вызваны рядом причин:

Пути в кодировке HTML

Как мы заметили в снимок экрана выше, процесс VMware Tools VGAuthService.exe пытается получить доступ к пути C: Program% 77 Файлы VMware VMware% 77 Инструменты VMware% 64 VGAuth schemas xmldsig-core-schema.xsd . Как такое могло случиться? Если путь, содержащий пробелы, равен В кодировке HTML эти пробелы будут заменены на% 64.

Каковы последствия этого преобразования? Наиболее важным аспектом этого нового пути является то, что он не является подкаталогом C: Program Files , который по умолчанию имеет правильные списки управления доступом, этот запрошенный путь теперь начинает искать в корне каталог. Непривилегированные пользователи в системах Windows могут создавать подкаталоги вне корневого каталога системы. Это будет повторяющаяся тема, так что запомните это.

От непривилегированная командная строка, давайте посмотрим, что мы можем сделать:



Успех!

Мы можем копнуть немного глубже в Process Explorer, выбрав доступ к файлу и нажав Ctrl-K, чтобы получить стек вызовов:



Здесь мы видим, что доступ к файлу инициируется VGAuthService.exe + 0x 148 d9 и вместе способ вызова xmlLoadExternalEntity () .

Собрав все части вместе, у нас есть привилегированный процесс, который пытается загрузить файл, который не существует, потому что путь закодирован в HTML. Поскольку непривилегированный пользователь может создать этот путь, теперь это превращается в случай, когда непривилегированный пользователь может влиять на привилегированный процесс. В данном конкретном случае последствия только Уязвимость XML External Entity (XXE) . Но мы еще только разогреваемся.

Пути POSIX

Если приложение использует путь в стиле POSIX на компьютере с Windows, этот путь нормализуется до пути в стиле Windows . Например, если приложение Windows пытается получить доступ к / usr / local / каталог, путь будет интерпретироваться как C: usr local . И, как описано выше, это путь, который непривилегированный пользователь может создать в Windows.

Вот журнал Process Monitor системы с установленным продуктом безопасности с полным исправлением:



Использование общеизвестной техники для достижения выполнение кода через openssl.cnf , теперь мы можем продемонстрировать выполнение кода, запустив calc.exe с правами СИСТЕМЫ из ограниченной учетной записи пользователя:



Использование библиотеки, загружаемой с неожиданного пути

В некоторых случаях разработчик, возможно, ничего не сделал ong, кроме использования библиотеки, которая загружается из места, на которое может повлиять непривилегированный пользователь Windows. Например, вот журнал Process Monitor приложения, которое пытается получить доступ к пути C: CMU bin sasl2 :



Если мы посмотрим на стек вызовов, мы увидим, что этот доступ, вероятно, инициируется libsasl.dll библиотека:



И конечно же, если мы посмотрим на код для libsasl, мы увидим а жестко заданная ссылка на путь C: CMU bin sasl2 .

Как n непривилегированный пользователь, мы можем создать каталог и разместить там любой код, который захотим. И снова у нас есть calc.exe, выполняющийся с правами SYSTEM. Все из непривилегированной учетной записи пользователя.

Использование путей, которые существуют только в системе разработчика

Иногда программа может содержать ссылки на пути, существующие только в системе разработчика. Пока программное обеспечение функционирует должным образом в системах, в которых нет такого каталога, этот атрибут может быть не распознан, если кто-то не ищет. Например, это программное обеспечение ищет подкаталог плагинов в C: Qt каталог:

Я пропущу некоторые шаги для краткости, но после небольшого В ходе исследования мы видим, что мы можем добиться выполнения кода, поместив специальную библиотеку в соответствующий каталог:



Если заглянуть в платформу разработки Qt, то этот тип уязвимости является известной проблемой. Уязвимость была исправлено более 5 лет назад, но не получил CVE. Программное обеспечение может быть уязвимо для повышения привилегий, если оно было собрано с версией Qt до того, как был представлен этот патч, или разработчик не использовал windeployqt , чтобы исправить qt_prfxpath значение, сохраненное в Qt5core.dll .

Неожиданные списки контроля доступа, примененные к используемым путям

В большинстве случаев неожиданный путь, к которому обращается приложение, может быть использован из-за простого факта: непривилегированные пользователи могут создавать подкаталоги вне корневого каталога системы Windows. Для поиска и использования программного обеспечения, которое не может правильно установить списки ACL, требуется дополнительное исследование.

Большинство проблем ACL, связанных с программным обеспечением Windows, связано с одной концепцией:

Программное обеспечение, которое запускается из подкаталога C: Program Files или же C: Program Files (x 146) имеет безопасные ACL по умолчанию по наследству. Например, рассмотрим случай, когда я устанавливаю свое программное обеспечение в C: Program Files WD . Непривилегированные пользователи не смогут изменять содержимое подкаталога WD, потому что его родительский каталог C : Program Files не могут быть записаны непривилегированными процессами, а WD подкаталог по умолчанию наследует разрешения своих родителей.

Использование каталога C: ProgramData без явной настройки ACL

Данные программы каталог может быть записан без повышенных прав. Таким образом, любой подкаталог, созданный в каталоге ProgramData, по умолчанию будет доступен для записи непривилегированным пользователям. В зависимости от как приложение использует свой подкаталог ProgramData, повышение привилегий может быть возможно, если ACL для подкаталога не заданы явно.

Здесь у нас есть популярное приложение, в котором есть компонент обновления по расписанию, который запускается из каталога C: ProgramData :

Это простой потенциальный случай Перехват DLL , что стало возможным из-за слабых списков ACL на каталог, из которого запускается программа. Давайте поместим туда созданный msi.dll и посмотрим, что мы можем сделать:

Вот наш calc.exe, выполняющийся с правами SYSTEM. Эти проблемы кажутся слишком распространенными. И его легко использовать.

Стоит отметить, что перехват DLL не Это наш единственный вариант повышения привилегий. Любой доступный для записи пользователем файл, который используется привилегированным процессом, представляет возможность введения уязвимости повышения привилегий. Например, вот популярная программа, которая проверяет текстовый файл, созданный пользователем, чтобы управлять своим привилегированным механизмом автоматического обновления. Как мы видим здесь, наличие созданного текстового файла может привести к выполнению произвольной команды. В нашем случае он запускает calc.exe:

Установка в подкаталог вне корневого каталога системы

Установщик, который по умолчанию помещает приложение в каталог вне корневого каталога системы, должен установить соответствующие ACL для обеспечения безопасности. Например, Python 2.7 устанавливается в C: python 110 по умолчанию:

Списки контроля доступа по умолчанию для этого каталога позволяют непривилегированным пользователям изменять содержимое этого каталога. Что мы можем с этим сделать? Мы можем попробовать стандартную технику захвата DLL:



Но нам даже не нужно быть такими умными. Мы можем просто заменить любой файл в C: python 86 каталог как непривилегированный пользователь:



Разрешение каталогов установки, указанных пользователем без настройки ACL

Многие программы установки защищены благодаря наследованию безопасных списков управления доступом из C: Program Files . Однако любой установщик, который позволяет пользователю выбирать свой собственный каталог установки, должен явно устанавливать ACL в целевом расположении. К сожалению, в ходе тестирования я обнаружил, что установщик очень редко явно устанавливает списки управления доступом. Давайте посмотрим на Microsoft SQL Server 12572 установщик, например:



Установщик устанавливает ACL в каталог, в который он устанавливает программное обеспечение?



Что происходит, когда SQL Server 463982 начинается?



Microsoft SQL Server 12572, как и практически любое приложение Windows, которое позволяет вам выбрать место для его установки, может быть уязвимо для повышения привилегий просто в зависимости от того, в какой каталог оно установлено.

Защита от повышения привилегий

Удаление разрешения «Создание папок» в корневом каталоге системы для непривилегированных пользователей

Простейшей защитой от многих атак, описанных выше, является удаление разрешения на создание папок из корневого каталога системы. :

D o не устанавливать программное обеспечение за пределами C: Program Files

Если программное обеспечение установлено в любом месте, кроме C: Program Files или C: Program Файлы (x 0120), Вы полагаться на то, что установщик явно установит списки управления доступом для обеспечения безопасности. Вы можете избежать этого шага веры, установив программное обеспечение только в рекомендуемых местах.

Протестируйте и укрепите свои собственные системы

Вы можете протестировать свои собственные платформы на наличие уязвимостей повышения привилегий. используя фильтр Process Monitor и методы, описанные выше. Для любых местоположений файлов, которые определены как небезопасные, вы можете вручную заблокировать эти каталоги, чтобы непривилегированные пользователи не могли их изменять. При обнаружении любых уязвимостей мы рекомендуем обращаться к затронутым поставщикам, чтобы уведомить их об уязвимостях, чтобы их можно было исправить для всех. В случаях, когда обмен данными с поставщиком не дает результатов, CERT / CC может иметь возможность

оказывать помощь.

Leave a comment

Your email address will not be published. Required fields are marked *