ed0e1e4d44
1979 changes to exploits/shellcodes Couchdb 1.5.0 - 'uuids' Denial of Service Apache CouchDB 1.5.0 - 'uuids' Denial of Service Beyond Remote 2.2.5.3 - Denial of Service (PoC) udisks2 2.8.0 - Denial of Service (PoC) Termite 3.4 - Denial of Service (PoC) SoftX FTP Client 3.3 - Denial of Service (PoC) Silverstripe 2.3.5 - Cross-Site Request Forgery / Open redirection SilverStripe CMS 2.3.5 - Cross-Site Request Forgery / Open Redirection Silverstripe CMS 3.0.2 - Multiple Vulnerabilities SilverStripe CMS 3.0.2 - Multiple Vulnerabilities Silverstripe CMS 2.4 - File Renaming Security Bypass SilverStripe CMS 2.4 - File Renaming Security Bypass Silverstripe CMS 2.4.5 - Multiple Cross-Site Scripting Vulnerabilities SilverStripe CMS 2.4.5 - Multiple Cross-Site Scripting Vulnerabilities Silverstripe CMS 2.4.7 - 'install.php' PHP Code Injection SilverStripe CMS 2.4.7 - 'install.php' PHP Code Injection Silverstripe Pixlr Image Editor - 'upload.php' Arbitrary File Upload SilverStripe CMS Pixlr Image Editor - 'upload.php' Arbitrary File Upload Silverstripe CMS 2.4.x - 'BackURL' Open Redirection SilverStripe CMS 2.4.x - 'BackURL' Open Redirection Silverstripe CMS - 'MemberLoginForm.php' Information Disclosure SilverStripe CMS - 'MemberLoginForm.php' Information Disclosure Silverstripe CMS - Multiple HTML Injection Vulnerabilities SilverStripe CMS - Multiple HTML Injection Vulnerabilities Apache CouchDB 1.7.0 and 2.x before 2.1.1 - Remote Privilege Escalation Apache CouchDB 1.7.0 / 2.x < 2.1.1 - Remote Privilege Escalation Monstra CMS before 3.0.4 - Cross-Site Scripting Monstra CMS < 3.0.4 - Cross-Site Scripting (2) Monstra CMS < 3.0.4 - Cross-Site Scripting Monstra CMS < 3.0.4 - Cross-Site Scripting (1) Navigate CMS 2.8 - Cross-Site Scripting Collectric CMU 1.0 - 'lang' SQL injection Joomla! Component CW Article Attachments 1.0.6 - 'id' SQL Injection LG SuperSign EZ CMS 2.5 - Remote Code Execution MyBB Visual Editor 1.8.18 - Cross-Site Scripting Joomla! Component AMGallery 1.2.3 - 'filter_category_id' SQL Injection Joomla! Component Micro Deal Factory 2.4.0 - 'id' SQL Injection RICOH Aficio MP 301 Printer - Cross-Site Scripting Joomla! Component Auction Factory 4.5.5 - 'filter_order' SQL Injection RICOH MP C6003 Printer - Cross-Site Scripting Linux/ARM - Egghunter (PWN!) + execve(_/bin/sh__ NULL_ NULL) Shellcode (28 Bytes) Linux/ARM - sigaction() Based Egghunter (PWN!) + execve(_/bin/sh__ NULL_ NULL) Shellcode (52 Bytes)
50 lines
No EOL
5 KiB
Text
50 lines
No EOL
5 KiB
Text
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 |