Содержание этого поста в блоге было написано Ником Пауэрсом (@zyn3rgy) и Стивеном Флоресом (@0xthirteen) и представляет собой письменную версию контента, представленного на Defcon30 .
Поскольку барьер для начального доступа постоянно растет, мы потратили некоторое время на изучение потенциально менее известных вариантов вооружения для развертываний ClickOnce. Вот несколько препятствий, которые мы хотели бы преодолеть, внедрив эти варианты вооружения:
- Установить/запустить приложение без прав администратора
- Файл(ы) с хорошей репутацией, используемые во время выполнения
- Обтекаемый, требуется минимальное взаимодействие с пользователем
- Простота повторного запуска реализаций выполнения
В конечном счете, мы хотим взять относительно распространенную технику начального доступа, известную как ClickOnce, и расширить ее для наступательного варианта использования, злоупотребляя доверием сторонних приложений.
Обзор ClickOnce и текущее вооружение
«ClickOnce — это технология развертывания, позволяющая создавать самообновляющиеся приложения для Windows, которые можно устанавливать и запускать с минимальным взаимодействием с пользователем» — MSDN
ClickOnce — это средство для установки и обновления приложений .NET. Развертывания могут быть опубликованы с помощью различных вариантов (например, общие сетевые файловые ресурсы, устаревшие носители [CD-ROM] и веб-страницы). Мы сосредоточимся на методе публикации развертываний на веб-странице. Легальные приложения существуют и используют развертывания ClickOnce для установки или обновления программного обеспечения, такого как Chrome (ранее), Fidelity и других.
Развертывания ClickOnce основаны на манифестах, которые отформатированы очень специфическим образом. Как и в приложениях .NET, необходимо учитывать различные типы манифестов. Существует три типа манифестов, с которыми следует ознакомиться при обсуждении развертываний ClickOnce.
> Манифесты развертывания ClickOnce
- *.application — это расширение файла
- Ссылается на манифест приложения ClickOnce для развертывания.
- Файл APPREF-MS будет указывать на это (если используется)
> Манифесты приложения ClickOnce
*.exe.manifest — это расширение файла
- Указывает зависимости для развертывания (указывает версию .NET, которая будет использоваться).
- Выполняет проверку целостности манифеста развертывания
- Ссылки на зависимости и другие файлы для доставки
> Манифесты встроенных приложений и сборок
- Манифест приложения также может называться неуправляемым или слитным манифестом.
- Манифест сборки также можно назвать управляемым манифестом.
- Во время выполнения ClickOnce сравнивает это
Приложения ClickOnce можно развернуть на клиенте, посетив манифест развертывания *.application с помощью браузера. Процесс загрузки и выполнения стандартного развертывания ClickOnce требует, чтобы конечный пользователь использовал браузер Microsoft Edge или Internet Explorer. Альтернативой требованию целевого пользователя получить доступ к вашему манифесту развертывания из Edge или Internet Explorer может быть использование APPREF-MS. При создании файла *.appref-ms требуется кодировка UTF-16 LE. Файл appref-ms будет использоваться, если конечный пользователь использует что-то вроде Chrome или Firefox для доступа к приложению.
ПРИМЕЧАНИЕ. Перед переходом на целевую страницу можно выполнить простую проверку пользовательского агента, чтобы определить, должен ли входящий запрос указывать на стандартный манифест развертывания или на файл appref-ms.
Сборка хоста, указанная в манифесте, будет порождена как дочерний процесс «dfsvc.exe», который обрабатывает функциональность развертывания ClickOnce, импортированную из «System.Deployment.dll». Содержимое манифеста приложения ClickOnce будет указывать, какие зависимости и другие ресурсы будут доставлены в процессе развертывания. Содержимое развертывания в конечном итоге будет сохранено в:
C:\Users\%USERNAME%\AppData\Local\Apps\2.0\<randomstring>
После того как пользователь согласится запустить приложение, манифест развертывания будет искать в манифесте приложения ClickOnce все файлы, которые необходимо загрузить.
В манифесте будут находиться различные фрагменты информации, очень похожие на манифесты приложений .NET. Он будет содержать все файлы и зависимости, необходимые для правильного выполнения развертывания.
Процесс dfsvc выполнит серию HTTP-запросов на загрузку и сохранит ее в указанном выше местоположении %LocalAppData% .
В некоторых сценариях пользователи могут захотеть взаимодействовать с приложениями ClickOnce, но не используют Microsoft Edge или Internet Explorer. Можно создать файл appref-ms, который будет действовать аналогично LNK или файлу ярлыка, который будет содержать URL-адрес манифеста развертывания и некоторую другую информацию.
Во время процесса, прежде чем произойдет загрузка, DLL System.Deployment будет использоваться для выполнения различных проверок и обеспечения правильного выполнения приложения ClickOnce. Важно отметить одну важную проверку — приложение .NET и идентификаторы развертывания ClickOnce, настроенные в сборке и манифестах развертывания.
Обычно при создании полезной нагрузки начального доступа и использовании ClickOnce вы проходите через процесс написания ее в среде IDE, такой как Visual Studio, и создаете приложение ClickOnce. Так как же выглядит стандартное выполнение развертывания ClickOnce с использованием только что созданного приложения .NET?
Текущие точки давления ClickOnce на вооружение
Как видно из первой демонстрации, у нас есть несколько проблем. Например, был запущен Microsoft SmartScreen. Это связано с тем, что сборка, которая в конечном итоге выполнялась с нашим произвольным кодом, была скомпилирована недавно и никогда раньше не отображалась в SmartScreen. Репутация Microsoft SmartScreen может основываться на ряде факторов, таких как хэш главной сборки или сертификат, используемый для подписи сборки.
Достижение выполнения произвольного кода в контексте приложения, которое видно и которому доверяют продукты Microsoft SmartScreen или EDR, может снизить вероятность предотвращения. Такие решения, как контроль приложений или предотвращение внесения в белый список, могут быть примечательны при рассмотрении того, как мы хотим выполнять наш код, особенно во время первоначальных попыток доступа. Сертификат подписи кода с расширенной проверкой (EV) можно использовать для немедленного получения репутации SmartScreen, но процесс проверки и цена увеличивают входной барьер. Когда используются сертификаты для подписи кода, возникают дополнительные проблемы с атрибуцией.
Как правило, развертывание ClickOnce может быть утомительным, чтобы убедиться, что «все звезды сошлись» для успешного развертывания. Часто люди считают ClickOnce утомительным для успешного развертывания и большим количеством требований к конфигурации. Мы надеемся, что в следующих двух разделах описываются важные поля в манифестах ClickOnce, на которых следует сосредоточиться, чтобы помочь воспроизвести эти методы.
Защита точек давления ClickOnce при использовании оружия
Если законные приложения .NET используют ClickOnce, и мы можем надежно загружать или перехватывать эти приложения .NET, почему бы просто не заблокировать существующее развертывание? Существующее развертывание, которое уже имеет, скажем, действующую подпись кода EV и репутацию SmartScreen?
ПРИМЕЧАНИЕ. Мы создадим резервную копию зависимости развертывания ClickOnce, а не самой сборки хоста. Мы поддерживаем действительную подпись, связанную с этой хост-сборкой.
Выявление существующих развертываний ClickOnce может быть таким же простым, как использование нескольких методов дублирования поисковой системы (или использование инструмента ClickonceHunter, который будет рассмотрен позже). В этом процессе можно использовать несколько инструментов (например, dnSpy, reshacker, mage, sigcheck и т. д.).
Нам нужно определить возможности загрузки неопубликованных приложений для зависимостей целевой сборки .NET, которую будет выполнять развертывание ClickOnce. Мы ищем любой способ перехватить поток выполнения вскоре после точки входа приложения. Часто этот процесс состоит из использования dnSpy для декомпиляции целевой сборки .NET, чтобы понять поток выполнения достаточно, чтобы определить возможность боковой загрузки.
Как только будет определена идеальная DLL для бэкдора, используйте dnSpy, чтобы добавить свой код в целевую DLL. На этом этапе манифесты ClickOnce выбранного вами развертывания необходимо будет настроить, чтобы они прошли проверку целостности. Если вы не можете определить идеальную возможность неопубликованной загрузки в существующих путях кода, вам могут помочь такие методы, как внедрение AppDomainManager или злоупотребление десериализацией .NET.
Изображение ниже является кратким примером того, как будет выглядеть неопубликованная загрузка существующего подписанного развертывания ClickOnce. Во-первых, мы находим развертывание ClickOnce, опубликованное в Интернете, загружаем его и проверяем, что сборка, которую выполняет развертывание, соответствует нашим потребностям (действительная подпись кода, репутация SmartScreen и т. д.):
Далее мы рассмотрим ссылки в подписанной сборке .NET, которую мы хотим загрузить. Некоторые библиотеки DLL, которые использует сборка, не имеют строгого имени, что может быть полезно в определенных ситуациях:
Используя DnSpy, чтобы начать с точки входа целевой сборки .NET, мы следуем коду до первого вызова метода «SetDpiAwareness()». Эта функция существует в ранее идентифицированных библиотеках DLL:
Мы наблюдаем за кодом в этом методе и проверяем, существует ли он в зависимости от DLL (а не в сборке хоста .NET):
Здесь можно добавить дополнительный код, который мы хотели бы загрузить для развертывания ClickOnce. Для проверки концепции мы просто создадим блокнот и пригласим MessageBox:
На этом этапе dnSpy может добавить ваши изменения в промежуточный язык (IL), и у вас будет скрытая зависимость от целевого приложения ClickOnce. Теперь самое время протестировать и убедиться, что дополнительный код, который вы добавили, правильно выполняется при запуске хост-сборки .NET.
ПРИМЕЧАНИЕ. Ранее мы считали, что предварительным условием является нацеливание только на библиотеки DLL без строгого имени. Мы обнаружили, что это не является обязательным требованием, поскольку изменение библиотеки DLL не изменяет значение PublickeyToken библиотеки DLL. Значение PublickeyToken относится к хэшу встроенного манифеста сборки, а не к самому коду. Если манифест не изменен, значение PublickeyToken остается прежним и все равно будет успешно загружено.
Теперь, когда у нас есть неопубликованное подписанное приложение .NET, которое является частью существующего развертывания ClickOnce, наш последний шаг к функционирующему развертыванию — настроить два манифеста ClickOnce таким образом, чтобы проверки целостности, происходящие во время развертывания, не завершались сбоем. Вот несколько советов, которые, надеюсь, ускорят процесс:
- publicKeyToken — это значение является обязательным, но его можно обнулить, заменив значение 16 нулями.
- <hash> — этот блок является необязательным и может быть удален или пересчитан (пример: openssl -dgst -binary -sha1 Program.exe.manifest |openssl enc -base64)
- <publisherIdentity> — включается, если манифесты были подписаны, но является необязательным и может быть удалено
Следует отметить, что изменение существующего манифеста ClickOnce заключается в том, что если манифест был подписан действительным сертификатом, то внесение этих изменений нарушит эту целостность. Разница для конечного пользователя минимальна, и многие законные развертывания ClickOnce вообще не подписывают свои манифесты. У нас по-прежнему есть контроль над приглашением, наблюдаемым целевым пользователем, таким как «Имя» и «От». Подписанный и неподписанный выглядят примерно так, как показано на изображении ниже:
Итак, возникает вопрос: действительно ли нам нужен сертификат для подписи кода, чтобы эффективно использовать развертывания ClickOnce в качестве оружия?
Расширение прошлых существующих развертываний ClickOnce
Количество опубликованных развертываний ClickOnce, легко идентифицируемых с помощью дублирования, ограничено. Это не новая технология и не самая популярная для развертывания и обновления приложений .NET. Мы предвидели это как потенциальную проблему и стремились найти способ взять любую идеальную сборку .NET, определить возможность загрузки неопубликованных приложений и превратить ее в новое развертывание ClickOnce. Как оказалось, это было возможно при соблюдении нескольких условий.
1. Поле <assemblyIdentity> в манифесте встроенного приложения не должно существовать, или весь манифест встроенного приложения не должен существовать (подробнее об этом чуть позже).
2. В настройках UAC нельзя установить значение «requireAdministrator» или «highestAvailable».
Сборки .NET, отвечающие этим предварительным требованиям, могут быть относительно легко использованы в качестве оружия с бэкдором для развертывания ClickOnce. Библиотека System.Deployment DLL содержит код, проверяющий удостоверение сборки, которое находится во встроенном манифесте приложения. Эта проверка перекрестно ссылается на удостоверение манифеста приложения, чтобы убедиться, что значения удостоверения совпадают. На изображении ниже показано, каким будет идентификатор по умолчанию манифеста встроенной сборки, если он присутствует.
Как видите, идентификатор содержит две части информации: версию и имя. На рисунке ниже показано, что содержится в манифесте развертывания для значения идентификатора. Если вы посмотрите на разницу, то увидите значение CPUArchitecture.
Значение « processorArchitecture» — это обязательное значение, которое должно присутствовать для удостоверения сборки в манифесте развертывания.
Эти два значения проверяются друг против друга, чтобы убедиться, что удостоверения сборок совпадают. Если значение удостоверения по умолчанию присутствует во встроенном манифесте сборки, произойдет сбой, поскольку отсутствует значение «processorArchitecture». Поэтому этот тип сборки невозможно использовать в качестве приложения ClickOnce для наших целей. Изменение этого значения потребует изменения сборки узла выполнения нашего кода, что приведет к потере всех преимуществ действительной подписи кода или репутации в Microsoft SmartScreen.
К счастью, существует множество сборок, у которых нет идентификатора в манифесте приложения. В следующем разделе мы покажем, как идентифицировать эти сборки, а пока на рисунке ниже показано, как выглядит встроенный манифест, когда удостоверение по умолчанию не задано, а вместо него в процессе сборки использовался нестандартный манифест.
Второе обязательное условие — в настройках UAC не обязательно должно быть указано значение «Администратор» или «Максимально доступный». Еще одна проверка System.Deployment DLL — поиск настроек UAC и возврат ошибок, если установлены запрещенные значения.
Если информация UAC существует или для нее задано значение asInvoker, сборка будет работать как развертывание ClickOnce.
Поскольку мы создаем приложения ClickOnce с нуля, нам придется создавать новые манифесты, в отличие от нашей предыдущей модификации существующих манифестов ClickOnce. У Microsoft есть утилита, которая используется для этой конкретной задачи, которая называется Manifest Generation and Editing Tool (Mage). Microsoft делает два разных инструмента, которые можно использовать: MageUI и Mage. Mage — это инструмент командной строки, входящий в состав Windows SDK, и именно его мы рассмотрим в рамках этой статьи.
После того, как вы пройдете процесс определения сборки .NET, которая может быть реализована как развертывание ClickOnce, вам потребуется создать структуру каталогов сборки, зависимостей и дополнительных файлов. Как упоминалось ранее, с помощью Mage необходимо создать два манифеста — манифест развертывания и манифест приложения. Манифест приложения можно создать с помощью следующей команды:
Далее вам нужно будет создать манифест развертывания. Это можно сделать с помощью следующей команды:
Аргумент ProviderUrl — это место, где будет размещен манифест развертывания, поскольку основной метод, который мы рассматриваем, — это веб-приложения. После создания манифестов вы увидите, что с помощью Mage создаются некоторые значения подписи. Как и то, что было рассмотрено при редактировании существующих манифестов, эти значения не всегда требуются и могут быть удалены. Если в общее развертывание будут внесены какие-либо изменения, подписи будут признаны недействительными, и их придется создавать повторно, что может привести к ненужному устранению неполадок. Как упоминалось ранее, эти значения таковы:
- <publicKeyToken> , требуется, но может быть обнулено 16 нулями
- Блок <hash> может быть вообще удален и не обязателен
- Блокировка идентификации издателя может быть полностью удалена
Теперь, когда мы идентифицировали существующую подписанную сборку .NET, которую можно развернуть как приложение ClickOnce, мы можем выполнить те же действия с бэкдором, что и в другом методе. Мы будем следовать путям кода, определять вызываемые библиотеки DLL и размещать наш код внутри этих библиотек DLL. Наконец, мы можем создать манифесты с помощью Mage и готовы к развертыванию.
Идентификация сборок .NET и приложений ClickOnce
До сих пор мы рассмотрели типы приложений, которые можно использовать в качестве оружия, и теперь мы хотим обнаружить потенциальные цели. Мы выпустили два инструмента, которые помогут в обнаружении существующих приложений ClickOnce и сборок .NET, которые можно использовать для ClickOnce.
> ClickonceHunter
- ищет в Интернете существующий опубликованный код ClickOnce
- Google dorks, Github и другие
> AssemblyHunter
- Ищет пути к файлам или файлы и ищет заданные критерии (подпись, идентификационная информация, архив, UAC и т. д.)
-Помогает определить целевые приложения для вооружения
ClickonceHunter автоматизирует то, что можно сделать вручную с помощью Google или других связанных поисков.
В то время как ClickonceHunter просматривает Интернет в поисках существующих приложений, AssemblyHunter будет рекурсивно искать в локальных файловых системах сборки, соответствующие критериям обычной сборки .NET для развертывания в качестве приложения ClickOnce.
Используя AssemblyHunter, мы можем быстро идентифицировать сборки в файловой системе хоста и искать значения, которые будут нам полезны.
AssemblyHunter показывает сборки, которые можно превратить в оружие
AssemblyHunter также покажет нам бесполезные для нас сборки, если мы захотим их увидеть.
Возможности обнаружения и предотвращения
Основным преимуществом для защитников, которые хотят идентифицировать вредоносные развертывания ClickOnce, является то, что ClickOnce обычно не используется во многих корпоративных средах. Защитники могут оценивать свою среду, чтобы узнать, насколько они распространены, и принять решение об обнаружении или предотвращении. При выявлении или предотвращении злонамеренного использования ClickOnce следует обратить внимание на следующие моменты:
> Мониторинг активности процесса dfsvc.exe
- Мониторинг активности дочерних процессов (например, дочерние процессы с неподписанными загрузками модулей)
- Необходимая базовая активность ClickOnce для внесения в белый список приложений с допустимыми вариантами использования в бизнесе.
-
Мониторинг активности, связанной с dfshim.dll (также можно использовать для запуска развертываний ClickOnce)
> Оценить телеметрию ETW, связанную с выполнением развертывания ClickOnce.
- Помните об ETW или значении конфигурации .NET <etwEnable>.
> Базовые каталоги установки ClickOnce по умолчанию
%LOCALAPPDATA%\Apps\2.0\<строка>
> Базовый уровень приложений, которые никогда не подключались к Интернету
> Отключите все установки ClickOnce из Интернета, но разрешите их из других зон доверия.
- Возможные варианты: Включено, AuthenticodeRequired и Отключено.
- Зоны включают: MyComputer, LocalIntranet, TrustedSites, Internet, UntrustedSites.
- Чтобы отключить установку из Интернета: \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel — Internet
isabled
> Если развернуто решение Application Control
- Предотвратить загрузку ненадежных библиотек DLL
Если выполнение приложения ClickOnce из Интернета отключено с помощью ключей реестра, упомянутых выше, пользователь получит приглашение, которое не дает ему возможность запустить приложение.
Итог
Исходя из всего, что было рассмотрено, мы рассматриваем ClickOnce как одну из лучших возможностей для начального доступа. Есть еще много областей для изучения и дополнительный потенциал для наступательных вариантов использования. Несколько человек, которым мы хотим выразить благодарность и которые подготовили почву для проделанной работы, это Ли Кристенсен ( @tifkin_ ), чье исследование этой техники было бы невозможным без него, Кейси Смит ( @subTee ) для предыдущего .NET исследование и Уильям Берк ( @0xF4B0 ) за предыдущее исследование ClickOnce .
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://posts.specterops.io/less-sm...konce-for-trusted-code-execution-1446ea8051c5
Поскольку барьер для начального доступа постоянно растет, мы потратили некоторое время на изучение потенциально менее известных вариантов вооружения для развертываний ClickOnce. Вот несколько препятствий, которые мы хотели бы преодолеть, внедрив эти варианты вооружения:
- Установить/запустить приложение без прав администратора
- Файл(ы) с хорошей репутацией, используемые во время выполнения
- Обтекаемый, требуется минимальное взаимодействие с пользователем
- Простота повторного запуска реализаций выполнения
В конечном счете, мы хотим взять относительно распространенную технику начального доступа, известную как ClickOnce, и расширить ее для наступательного варианта использования, злоупотребляя доверием сторонних приложений.
Обзор ClickOnce и текущее вооружение
«ClickOnce — это технология развертывания, позволяющая создавать самообновляющиеся приложения для Windows, которые можно устанавливать и запускать с минимальным взаимодействием с пользователем» — MSDN
ClickOnce — это средство для установки и обновления приложений .NET. Развертывания могут быть опубликованы с помощью различных вариантов (например, общие сетевые файловые ресурсы, устаревшие носители [CD-ROM] и веб-страницы). Мы сосредоточимся на методе публикации развертываний на веб-странице. Легальные приложения существуют и используют развертывания ClickOnce для установки или обновления программного обеспечения, такого как Chrome (ранее), Fidelity и других.
Развертывания ClickOnce основаны на манифестах, которые отформатированы очень специфическим образом. Как и в приложениях .NET, необходимо учитывать различные типы манифестов. Существует три типа манифестов, с которыми следует ознакомиться при обсуждении развертываний ClickOnce.
> Манифесты развертывания ClickOnce
- *.application — это расширение файла
- Ссылается на манифест приложения ClickOnce для развертывания.
- Файл APPREF-MS будет указывать на это (если используется)
> Манифесты приложения ClickOnce
*.exe.manifest — это расширение файла
- Указывает зависимости для развертывания (указывает версию .NET, которая будет использоваться).
- Выполняет проверку целостности манифеста развертывания
- Ссылки на зависимости и другие файлы для доставки
> Манифесты встроенных приложений и сборок
- Манифест приложения также может называться неуправляемым или слитным манифестом.
- Манифест сборки также можно назвать управляемым манифестом.
- Во время выполнения ClickOnce сравнивает это
Приложения ClickOnce можно развернуть на клиенте, посетив манифест развертывания *.application с помощью браузера. Процесс загрузки и выполнения стандартного развертывания ClickOnce требует, чтобы конечный пользователь использовал браузер Microsoft Edge или Internet Explorer. Альтернативой требованию целевого пользователя получить доступ к вашему манифесту развертывания из Edge или Internet Explorer может быть использование APPREF-MS. При создании файла *.appref-ms требуется кодировка UTF-16 LE. Файл appref-ms будет использоваться, если конечный пользователь использует что-то вроде Chrome или Firefox для доступа к приложению.
ПРИМЕЧАНИЕ. Перед переходом на целевую страницу можно выполнить простую проверку пользовательского агента, чтобы определить, должен ли входящий запрос указывать на стандартный манифест развертывания или на файл appref-ms.
Сборка хоста, указанная в манифесте, будет порождена как дочерний процесс «dfsvc.exe», который обрабатывает функциональность развертывания ClickOnce, импортированную из «System.Deployment.dll». Содержимое манифеста приложения ClickOnce будет указывать, какие зависимости и другие ресурсы будут доставлены в процессе развертывания. Содержимое развертывания в конечном итоге будет сохранено в:
C:\Users\%USERNAME%\AppData\Local\Apps\2.0\<randomstring>
После того как пользователь согласится запустить приложение, манифест развертывания будет искать в манифесте приложения ClickOnce все файлы, которые необходимо загрузить.
В манифесте будут находиться различные фрагменты информации, очень похожие на манифесты приложений .NET. Он будет содержать все файлы и зависимости, необходимые для правильного выполнения развертывания.
Процесс dfsvc выполнит серию HTTP-запросов на загрузку и сохранит ее в указанном выше местоположении %LocalAppData% .
В некоторых сценариях пользователи могут захотеть взаимодействовать с приложениями ClickOnce, но не используют Microsoft Edge или Internet Explorer. Можно создать файл appref-ms, который будет действовать аналогично LNK или файлу ярлыка, который будет содержать URL-адрес манифеста развертывания и некоторую другую информацию.
Во время процесса, прежде чем произойдет загрузка, DLL System.Deployment будет использоваться для выполнения различных проверок и обеспечения правильного выполнения приложения ClickOnce. Важно отметить одну важную проверку — приложение .NET и идентификаторы развертывания ClickOnce, настроенные в сборке и манифестах развертывания.
Обычно при создании полезной нагрузки начального доступа и использовании ClickOnce вы проходите через процесс написания ее в среде IDE, такой как Visual Studio, и создаете приложение ClickOnce. Так как же выглядит стандартное выполнение развертывания ClickOnce с использованием только что созданного приложения .NET?
Текущие точки давления ClickOnce на вооружение
Как видно из первой демонстрации, у нас есть несколько проблем. Например, был запущен Microsoft SmartScreen. Это связано с тем, что сборка, которая в конечном итоге выполнялась с нашим произвольным кодом, была скомпилирована недавно и никогда раньше не отображалась в SmartScreen. Репутация Microsoft SmartScreen может основываться на ряде факторов, таких как хэш главной сборки или сертификат, используемый для подписи сборки.
Достижение выполнения произвольного кода в контексте приложения, которое видно и которому доверяют продукты Microsoft SmartScreen или EDR, может снизить вероятность предотвращения. Такие решения, как контроль приложений или предотвращение внесения в белый список, могут быть примечательны при рассмотрении того, как мы хотим выполнять наш код, особенно во время первоначальных попыток доступа. Сертификат подписи кода с расширенной проверкой (EV) можно использовать для немедленного получения репутации SmartScreen, но процесс проверки и цена увеличивают входной барьер. Когда используются сертификаты для подписи кода, возникают дополнительные проблемы с атрибуцией.
Как правило, развертывание ClickOnce может быть утомительным, чтобы убедиться, что «все звезды сошлись» для успешного развертывания. Часто люди считают ClickOnce утомительным для успешного развертывания и большим количеством требований к конфигурации. Мы надеемся, что в следующих двух разделах описываются важные поля в манифестах ClickOnce, на которых следует сосредоточиться, чтобы помочь воспроизвести эти методы.
Защита точек давления ClickOnce при использовании оружия
Если законные приложения .NET используют ClickOnce, и мы можем надежно загружать или перехватывать эти приложения .NET, почему бы просто не заблокировать существующее развертывание? Существующее развертывание, которое уже имеет, скажем, действующую подпись кода EV и репутацию SmartScreen?
ПРИМЕЧАНИЕ. Мы создадим резервную копию зависимости развертывания ClickOnce, а не самой сборки хоста. Мы поддерживаем действительную подпись, связанную с этой хост-сборкой.
Выявление существующих развертываний ClickOnce может быть таким же простым, как использование нескольких методов дублирования поисковой системы (или использование инструмента ClickonceHunter, который будет рассмотрен позже). В этом процессе можно использовать несколько инструментов (например, dnSpy, reshacker, mage, sigcheck и т. д.).
Нам нужно определить возможности загрузки неопубликованных приложений для зависимостей целевой сборки .NET, которую будет выполнять развертывание ClickOnce. Мы ищем любой способ перехватить поток выполнения вскоре после точки входа приложения. Часто этот процесс состоит из использования dnSpy для декомпиляции целевой сборки .NET, чтобы понять поток выполнения достаточно, чтобы определить возможность боковой загрузки.
Как только будет определена идеальная DLL для бэкдора, используйте dnSpy, чтобы добавить свой код в целевую DLL. На этом этапе манифесты ClickOnce выбранного вами развертывания необходимо будет настроить, чтобы они прошли проверку целостности. Если вы не можете определить идеальную возможность неопубликованной загрузки в существующих путях кода, вам могут помочь такие методы, как внедрение AppDomainManager или злоупотребление десериализацией .NET.
Изображение ниже является кратким примером того, как будет выглядеть неопубликованная загрузка существующего подписанного развертывания ClickOnce. Во-первых, мы находим развертывание ClickOnce, опубликованное в Интернете, загружаем его и проверяем, что сборка, которую выполняет развертывание, соответствует нашим потребностям (действительная подпись кода, репутация SmartScreen и т. д.):
Далее мы рассмотрим ссылки в подписанной сборке .NET, которую мы хотим загрузить. Некоторые библиотеки DLL, которые использует сборка, не имеют строгого имени, что может быть полезно в определенных ситуациях:
Используя DnSpy, чтобы начать с точки входа целевой сборки .NET, мы следуем коду до первого вызова метода «SetDpiAwareness()». Эта функция существует в ранее идентифицированных библиотеках DLL:
Мы наблюдаем за кодом в этом методе и проверяем, существует ли он в зависимости от DLL (а не в сборке хоста .NET):
Здесь можно добавить дополнительный код, который мы хотели бы загрузить для развертывания ClickOnce. Для проверки концепции мы просто создадим блокнот и пригласим MessageBox:
На этом этапе dnSpy может добавить ваши изменения в промежуточный язык (IL), и у вас будет скрытая зависимость от целевого приложения ClickOnce. Теперь самое время протестировать и убедиться, что дополнительный код, который вы добавили, правильно выполняется при запуске хост-сборки .NET.
ПРИМЕЧАНИЕ. Ранее мы считали, что предварительным условием является нацеливание только на библиотеки DLL без строгого имени. Мы обнаружили, что это не является обязательным требованием, поскольку изменение библиотеки DLL не изменяет значение PublickeyToken библиотеки DLL. Значение PublickeyToken относится к хэшу встроенного манифеста сборки, а не к самому коду. Если манифест не изменен, значение PublickeyToken остается прежним и все равно будет успешно загружено.
Теперь, когда у нас есть неопубликованное подписанное приложение .NET, которое является частью существующего развертывания ClickOnce, наш последний шаг к функционирующему развертыванию — настроить два манифеста ClickOnce таким образом, чтобы проверки целостности, происходящие во время развертывания, не завершались сбоем. Вот несколько советов, которые, надеюсь, ускорят процесс:
- publicKeyToken — это значение является обязательным, но его можно обнулить, заменив значение 16 нулями.
- <hash> — этот блок является необязательным и может быть удален или пересчитан (пример: openssl -dgst -binary -sha1 Program.exe.manifest |openssl enc -base64)
- <publisherIdentity> — включается, если манифесты были подписаны, но является необязательным и может быть удалено
Следует отметить, что изменение существующего манифеста ClickOnce заключается в том, что если манифест был подписан действительным сертификатом, то внесение этих изменений нарушит эту целостность. Разница для конечного пользователя минимальна, и многие законные развертывания ClickOnce вообще не подписывают свои манифесты. У нас по-прежнему есть контроль над приглашением, наблюдаемым целевым пользователем, таким как «Имя» и «От». Подписанный и неподписанный выглядят примерно так, как показано на изображении ниже:
Итак, возникает вопрос: действительно ли нам нужен сертификат для подписи кода, чтобы эффективно использовать развертывания ClickOnce в качестве оружия?
Расширение прошлых существующих развертываний ClickOnce
Количество опубликованных развертываний ClickOnce, легко идентифицируемых с помощью дублирования, ограничено. Это не новая технология и не самая популярная для развертывания и обновления приложений .NET. Мы предвидели это как потенциальную проблему и стремились найти способ взять любую идеальную сборку .NET, определить возможность загрузки неопубликованных приложений и превратить ее в новое развертывание ClickOnce. Как оказалось, это было возможно при соблюдении нескольких условий.
1. Поле <assemblyIdentity> в манифесте встроенного приложения не должно существовать, или весь манифест встроенного приложения не должен существовать (подробнее об этом чуть позже).
2. В настройках UAC нельзя установить значение «requireAdministrator» или «highestAvailable».
Сборки .NET, отвечающие этим предварительным требованиям, могут быть относительно легко использованы в качестве оружия с бэкдором для развертывания ClickOnce. Библиотека System.Deployment DLL содержит код, проверяющий удостоверение сборки, которое находится во встроенном манифесте приложения. Эта проверка перекрестно ссылается на удостоверение манифеста приложения, чтобы убедиться, что значения удостоверения совпадают. На изображении ниже показано, каким будет идентификатор по умолчанию манифеста встроенной сборки, если он присутствует.
Как видите, идентификатор содержит две части информации: версию и имя. На рисунке ниже показано, что содержится в манифесте развертывания для значения идентификатора. Если вы посмотрите на разницу, то увидите значение CPUArchitecture.
Значение « processorArchitecture» — это обязательное значение, которое должно присутствовать для удостоверения сборки в манифесте развертывания.
Эти два значения проверяются друг против друга, чтобы убедиться, что удостоверения сборок совпадают. Если значение удостоверения по умолчанию присутствует во встроенном манифесте сборки, произойдет сбой, поскольку отсутствует значение «processorArchitecture». Поэтому этот тип сборки невозможно использовать в качестве приложения ClickOnce для наших целей. Изменение этого значения потребует изменения сборки узла выполнения нашего кода, что приведет к потере всех преимуществ действительной подписи кода или репутации в Microsoft SmartScreen.
К счастью, существует множество сборок, у которых нет идентификатора в манифесте приложения. В следующем разделе мы покажем, как идентифицировать эти сборки, а пока на рисунке ниже показано, как выглядит встроенный манифест, когда удостоверение по умолчанию не задано, а вместо него в процессе сборки использовался нестандартный манифест.
XML:
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level replace the
requestedExecutionLevel node with one of the following.
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
Specifying requestedExecutionLevel node will disable file and registry virtualization.
If you want to utilize File and Registry Virtualization for backward
compatibility then delete the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- A list of all Windows versions that this application is designed to work with.
Windows will automatically select the most compatible environment.-->
<!-- If your application is designed to work with Windows 7, uncomment the following supportedOS node-->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- If your application is designed to work with Windows 8, uncomment the following supportedOS node-->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!-- If your application is designed to work with Windows 8.1, uncomment the following supportedOS node-->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!-- This Id value indicates the application supports Windows Threshold functionality-->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
</asmv1:assembly>Второе обязательное условие — в настройках UAC не обязательно должно быть указано значение «Администратор» или «Максимально доступный». Еще одна проверка System.Deployment DLL — поиск настроек UAC и возврат ошибок, если установлены запрещенные значения.
Если информация UAC существует или для нее задано значение asInvoker, сборка будет работать как развертывание ClickOnce.
Поскольку мы создаем приложения ClickOnce с нуля, нам придется создавать новые манифесты, в отличие от нашей предыдущей модификации существующих манифестов ClickOnce. У Microsoft есть утилита, которая используется для этой конкретной задачи, которая называется Manifest Generation and Editing Tool (Mage). Microsoft делает два разных инструмента, которые можно использовать: MageUI и Mage. Mage — это инструмент командной строки, входящий в состав Windows SDK, и именно его мы рассмотрим в рамках этой статьи.
После того, как вы пройдете процесс определения сборки .NET, которая может быть реализована как развертывание ClickOnce, вам потребуется создать структуру каталогов сборки, зависимостей и дополнительных файлов. Как упоминалось ранее, с помощью Mage необходимо создать два манифеста — манифест развертывания и манифест приложения. Манифест приложения можно создать с помощью следующей команды:
Далее вам нужно будет создать манифест развертывания. Это можно сделать с помощью следующей команды:
Аргумент ProviderUrl — это место, где будет размещен манифест развертывания, поскольку основной метод, который мы рассматриваем, — это веб-приложения. После создания манифестов вы увидите, что с помощью Mage создаются некоторые значения подписи. Как и то, что было рассмотрено при редактировании существующих манифестов, эти значения не всегда требуются и могут быть удалены. Если в общее развертывание будут внесены какие-либо изменения, подписи будут признаны недействительными, и их придется создавать повторно, что может привести к ненужному устранению неполадок. Как упоминалось ранее, эти значения таковы:
- <publicKeyToken> , требуется, но может быть обнулено 16 нулями
- Блок <hash> может быть вообще удален и не обязателен
- Блокировка идентификации издателя может быть полностью удалена
Теперь, когда мы идентифицировали существующую подписанную сборку .NET, которую можно развернуть как приложение ClickOnce, мы можем выполнить те же действия с бэкдором, что и в другом методе. Мы будем следовать путям кода, определять вызываемые библиотеки DLL и размещать наш код внутри этих библиотек DLL. Наконец, мы можем создать манифесты с помощью Mage и готовы к развертыванию.
Идентификация сборок .NET и приложений ClickOnce
До сих пор мы рассмотрели типы приложений, которые можно использовать в качестве оружия, и теперь мы хотим обнаружить потенциальные цели. Мы выпустили два инструмента, которые помогут в обнаружении существующих приложений ClickOnce и сборок .NET, которые можно использовать для ClickOnce.
> ClickonceHunter
- ищет в Интернете существующий опубликованный код ClickOnce
- Google dorks, Github и другие
> AssemblyHunter
- Ищет пути к файлам или файлы и ищет заданные критерии (подпись, идентификационная информация, архив, UAC и т. д.)
-Помогает определить целевые приложения для вооружения
ClickonceHunter автоматизирует то, что можно сделать вручную с помощью Google или других связанных поисков.
В то время как ClickonceHunter просматривает Интернет в поисках существующих приложений, AssemblyHunter будет рекурсивно искать в локальных файловых системах сборки, соответствующие критериям обычной сборки .NET для развертывания в качестве приложения ClickOnce.
Используя AssemblyHunter, мы можем быстро идентифицировать сборки в файловой системе хоста и искать значения, которые будут нам полезны.
AssemblyHunter показывает сборки, которые можно превратить в оружие
AssemblyHunter также покажет нам бесполезные для нас сборки, если мы захотим их увидеть.
Возможности обнаружения и предотвращения
Основным преимуществом для защитников, которые хотят идентифицировать вредоносные развертывания ClickOnce, является то, что ClickOnce обычно не используется во многих корпоративных средах. Защитники могут оценивать свою среду, чтобы узнать, насколько они распространены, и принять решение об обнаружении или предотвращении. При выявлении или предотвращении злонамеренного использования ClickOnce следует обратить внимание на следующие моменты:
> Мониторинг активности процесса dfsvc.exe
- Мониторинг активности дочерних процессов (например, дочерние процессы с неподписанными загрузками модулей)
- Необходимая базовая активность ClickOnce для внесения в белый список приложений с допустимыми вариантами использования в бизнесе.
-
Мониторинг активности, связанной с dfshim.dll (также можно использовать для запуска развертываний ClickOnce)
> Оценить телеметрию ETW, связанную с выполнением развертывания ClickOnce.
- Помните об ETW или значении конфигурации .NET <etwEnable>.
> Базовые каталоги установки ClickOnce по умолчанию
%LOCALAPPDATA%\Apps\2.0\<строка>
> Базовый уровень приложений, которые никогда не подключались к Интернету
> Отключите все установки ClickOnce из Интернета, но разрешите их из других зон доверия.
- Возможные варианты: Включено, AuthenticodeRequired и Отключено.
- Зоны включают: MyComputer, LocalIntranet, TrustedSites, Internet, UntrustedSites.
- Чтобы отключить установку из Интернета: \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel — Internet
isabled> Если развернуто решение Application Control
- Предотвратить загрузку ненадежных библиотек DLL
Если выполнение приложения ClickOnce из Интернета отключено с помощью ключей реестра, упомянутых выше, пользователь получит приглашение, которое не дает ему возможность запустить приложение.
Итог
Исходя из всего, что было рассмотрено, мы рассматриваем ClickOnce как одну из лучших возможностей для начального доступа. Есть еще много областей для изучения и дополнительный потенциал для наступательных вариантов использования. Несколько человек, которым мы хотим выразить благодарность и которые подготовили почву для проделанной работы, это Ли Кристенсен ( @tifkin_ ), чье исследование этой техники было бы невозможным без него, Кейси Смит ( @subTee ) для предыдущего .NET исследование и Уильям Берк ( @0xF4B0 ) за предыдущее исследование ClickOnce .
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://posts.specterops.io/less-sm...konce-for-trusted-code-execution-1446ea8051c5
Последнее редактирование: