Windows AppX Deployment Service Local Privilege Escalation (CVE-2020-1488)

The AppX Deployment Service (AppXSVC) on Microsoft Windows suffers from an arbitrary file/directory deletion vulnerability that could be triggered by standard non-privileged users due to improper user impersonation during the removal process of any application from the Windows App Store (also known as Microsoft Store) leading to an elevation of privileges attack. Now, before we dive into the finding details, let's briefly talk about the vulnerable service and Microsoft Store applications.

From a high-level overview, the AppX service is part of the WSAPPX process and it’s used for installing, removing, and updating Microsoft Store apps in the background. Microsoft Store apps (also known as Universal Windows Platform (UWP) or Universal Application Platform (UAP) apps) have several notable features. One of the key features is the fact they run on all Windows device families such as Windows phone and Xbox as opposed to traditional desktop apps which are limited to PC only. Another interesting feature about Microsoft Store apps is that they are sandboxed, as in they run with a low-integrity level inside an AppContainer (i.e. limited in terms of what they have access to on the host system), moreover, each application comes with a set of permissions required to function properly. These permissions are called capabilities and are declared as part of the application package when it’s submitted to the Store. This way, the user can decide whether these capabilities are acceptable. Here’s an example of said capabilities for OneNote.

​It’s worth mentioning that the Store applications are distributed in self-contained .AppX packages, hence the service name. Now, the service has proven to be prone to elevation of privilege bugs in the past, most notably CVE-2019-0841 and CVE-2019-1064. As such we’ve decided to interact with the Microsoft Store component to see how the AppX service behaves and ultimately found the bug by removing an application from the Store. We used the below command to remove OneNote application but in reality, it could be any application using a standard non-privileged user account.

​And noticed the following activity in Process Monitor under the current user AppData folder.

​Most of the above operations such as reading and directory listing were performed by the AppX service while impersonating the currently logged on user.

​However, file and directory deletion operations were performed with no user impersonation resulting in an arbitrary file/directory deletion with NT AUTHORITY\SYSTEM privileges.

​To confirm our assumptions, we analyzed the above operation by following the stack trace below.

​As an example, we decompiled the function that calls into RemoveDirectoryW + 0x145 in KernelBase and ultimately NtSetInformationFile in NTDLL where the  FILE_DISPOSITION_INFORMATION_EX structure has FILE_DISPOSITION_DELETE set among other flags before switching to kernel space.

​As you can see, the calling function is pretty self-explanatory and there is no user impersonation using functions like ImpersonateLoggedOnUser before RemoveDirectoryW function call and as such the AppX service will effectively iterate through all files and directories belonging to the application in question and ultimately delete them as NT AUTHORITY\SYSTEM. Let’s create a Symbolic Link using James Forshaw’s testing tools targeting C:\Windows\Help directory.

​And then uninstall OneNote application from Microsoft Store.

​We can see that all directories and files under the target folder have been removed.

​At this point, we combined the arbitrary file/directory deletion bug with Windows Error Reporting (WER) method found by Jonas L here to build an exploit for Windows 10. Since we’re effectively abusing Microsoft Store applications to trigger the bug, we thought it would be more appropriate to run the exploit in Windows Terminal application.
 

We did report this bug to Microsoft and patch was released in August’s patch Tuesday. Feel free to reach out to labs@activecyber.us if you have any questions. Also, see the link here for a complete list of ACTIVELabs advisories.
 
Affected Products

• Windows 10

• Windows 8

 
Disclosure Timeline

• 04-17-20: ACTIVELabs sent the report along with the exploit to Microsoft

• 04-21-20: Microsoft confirmed the report and started investigating the issue

• 04-25-20: ACTIVELabs sent additional notes to Microsoft

• 06-09-20: Bounty awarded

• 07-14-20: Microsoft assigned CVE-2020-1488 to the bug and informed ACTIVELabs the patch will be released on August 11, 2020.  

• 08-11-20: Patch released in August patch Tuesday

• 08-12-20: ACTIVELabs publishes an advisory

• 08-18-20: ACTIVELabs publishes this blog post