PATH directories DLL planting on default Windows installations

TL;DR

The %LOCALAPPDATA%\Microsoft\WindowsApps folder is added to the PATH directories by default. This folder is not protected with an administrator ACL, hence it does not require elevated permissions to create files and write data in this folder. Planting a malicious DLL module in this folder may allow an attacker to execute code or elevate privileges, depending on the affected application loading the module.

Description

Many resources on this subject, including the blog post Triaging a DLL planting vulnerability by MSRC claims that

the directories that are in the PATH environment variable are always admin ACLed and a normal user can’t modify contents of these directories.

However, in fact, the directories that are in the PATH environment variable are not always admin ACLed and a normal user can modify contents of at least one PATH directory by default.

The %LOCALAPPDATA%\Microsoft\WindowsApps folder is added to the PATH directories by default and normal users have Full Control over this folder in their own profile. This weakness may allow remote code execution or elevation of privilege, if a vulnerable application attempts to load a DLL module that cannot be found in the prior directories searched, as per the DLL search order.

According to MSRC this is not a vulnerability, because

Anything planted in these directories would be owned by the user, and any code executing a planted binary here would only be executing in the context of the user. This does not elevate privileges, so the user would only be attacking their own session.

The above will be true for most cases, however, it does not take into account applications which are running with elevated permissions and are vulnerable to PATH directories DLL planting. In case of such applications this vulnerability may become easily exploitable, due to the writable WindowsApps folder being included in the PATH directories by default.

Anyway, I have found that many Electron applications including Edge, Visual Studio Code, WhatsApp Desktop, GitHub Desktop etc. are affected by this issue, because they are all looking for the vulkan-1.dll module in the WindowsApps folder.

Steps to reproduce

1. Drop a malicious vulkan-1.dll module in %LOCALAPPDATA%\Microsoft\WindowsApps.
2. Start Edge (Chromium), VSCode, GitHub Desktop or WhatsApp Desktop (or any other Electron desktop app?).
3. Your code in the malicious DLL module will be executed.

PoC

Stefan Kanthak’s Vulnerability and Exploit Detector is a great tool for researching potential DLL planting vulnerabilities. When SENTINEL.DLL runs in an interactive user session it displays one or more message boxes. I have planted SENTINEL.DLL file as vulkan-1.dll in the WindowsApps folder and launched some Electron applications to confirm that the DLL module is indeed being loaded and executed. The below screencapture shows the message boxes spawned by the planted vulkan-1.dll:

Timeline

⬅️ 2020-01-25: Reported issue to MSRC.
➡️ 2020-01-29: MSRC opened case 56269.
➡️ 2020-02-08: MSRC indicated that this issue will not be fixed.
⬅️ 2020-02-08: Provided feedback for MSRC to review.
➡️ 2020-02-27: MSRC confirmed that this issue will not be fixed.

References

• Vulnerability and Exploit Detector
• Dynamic-Link Library Search Order
• It rather involved being on the other side of this airtight hatchway: Planting DLLs into directories on the PATH for applications whose current directory is always System32
• Triaging a DLL planting vulnerability
• 2019 year-end link clearance: The different kinds of DLL planting