microsoft windows 10 desktop bridge activation arbitrary directory creation privilege escalation

				
Windows: Desktop Bridge Activation Arbitrary Directory Creation EoP
Platform: Windows 10 1703, 1709 (not tested RS4)
Class: Elevation of Privilege

Summary: The activator for Desktop Bridge applications calls CreateAppContainerToken while running as a privileged account leading to creation of arbitrary object directories leading to EoP.

Description:
As much of the activation of Desktop Bridge applications require TCB privilege (such as creating the container) it’s delegated to the AppInfo service which runs as Local System. During post activation, either through RAiLaunchProcessWithIdentity or RAiFinishPackageActivation the API PostCreateProcessDesktopAppXActivation is called in daxexec which sets up various things. One of those things is registering the process with the Process State Manager service and to do that it passes an AppContainer token for the AppX package. 

To create the token the service will call the API CreateAppContainerToken, however it doesn’t impersonate the user while doing this which results in the service setting up the AppContainer object directories as the process user. By placing symbolic links into these locations arbitrary object directories can be created, as long as the parent directory can be written by Local System. The created directories are also given an explicit DACL which grants the user access so that they can also be written to by the original user once created. 

On Windows 8.1 this would be trivial to exploit as NtCreateLowBoxToken didn’t care what handles you passed it for capture, however since CVE-2015-2554 (which I reported) the system call checks that the directories are under the AppContainerNamedObjects directory for the user. They’re still created but once NtCreateLowBoxToken is called they’ll be closed again. However due to the way kernel objects persist it just becomes a race condition, as long as you open the directory you want before all handles are closed then you can keep it alive to do what you need to do with it. In practice it seems to be possible to capture the directory reliably but perhaps only on multi core systems.

IMO this might be best to fix in CreateAppContainerToken, perhaps by impersonating the base token which is being used to create the lowbox one. I’ve tried to track down cases before where this function is called inappropriately and it wouldn’t surprise me if there’s more bad callers for this function as impersonation can be tricky to get right, especially when hidden behind RAI C++ classes. 

As an aside it’s also worth noting that this type of bug is of more general application to the session 0 AppContainerNamedObjects directory. That directory granted access to the Everyone group to write to it as shown below.


PS C:\> $d = Get-NtDirectory \Sessions\0\AppContainerNamedObjects
PS C:\> $d.SecurityDescriptor.Dacl

Type       User                           Flags                Mask
----       ----                           -----                ----
Allowed    Everyone                       None                 0002000F
Allowed    NT AUTHORITY\SYSTEM            None                 000F000F
Allowed    NT AUTHORITY\RESTRICTED        None                 00000002
Allowed    APPLICATION PACKAGE AUTHORI... None                 00000003
Allowed    APPLICATION PACKAGE AUTHORI... None                 00000003
Allowed    NT AUTHORITY\SYSTEM            ObjectInherit, Co... 10000000

Previously nothing used it in Session 0 but in a recent update the UMFD process spawns in Session 0 as an AC and so the directories would be created by a system process which could be redirected. I’m not sure that’s very useful but it’s something which you might also want to fix.

Proof of Concept:

I’ve provided a PoC as a C# project. As it’s a race condition it should be run on a multi-core machine to give the threads a chance to capture the directory object. It might work on a single core as well but I’ve not tested it. If it fails to get the directory try it again as it’s possible that the race wasn’t successfully won. It uses the My Office application as with previous exploits, if it’s not installed then the PoC will fail. However it doesn’t need a specific Desktop Bridge application just any installed will do though you’d have to modify the package information in the PoC to do so. The PoC will try and create the folder \Blah in the object manager namespace.

1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work.
2) Run the PoC, if the PoC says that OfficeHub is already running ensure it’s closed.
3) If a dialog appears saying the application has failed to start click OK.
4) The poc should print whether it captured the directory and if so what access was granted.

Expected Result:
Create of the application should fail and the directories are not created.

Observed Result:
The directories are created, the application will still fail.


Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/44914.zip
            
				

Microsoft windows 10 desktop bridge activation arbitrary directory creation privilege escalation Vulnerability / Exploit Source : Microsoft windows 10 desktop bridge activation arbitrary directory creation privilege escalation