Remote Code Execution via Path Traversal in the Device Metadata Authoring Wizard

Summary

Attackers can use the .devicemanifest-ms and .devicemetadata-ms file extensions for remote code execution in phishing scenarios when the Windows Driver Kit is installed on a victim’s machine. This is possible because the Windows Driver Kit installer installs the Device Metadata Authoring Wizard and associates the .devicemanifest-ms and .devicemetadata-ms file extensions with the program DeviceMetadataWizard.exe. When a victim user opens a maliciously crafted .devicemanifest-ms or .devicemetadata-ms file, an attacker can abuse a path traversal vulnerability in DeviceMetadataWizard.exe to place a file in any writeable directory accessible by the victim user. Writing to certain paths can result in arbitrary code execution (e.g. the user’s Startup folder).

Technical Details

The .devicemanifest-ms and .devicemetadata-ms file extensions are registered on machines where the Device Metadata Authoring Wizard is installed. This application is part of the Windows Driver Kit and is installed by default on the Azure Visual Studio Community template VMs. It may also be installed when certain features are enabled during the Visual Studio installation process. The program DeviceMetadataWizard.exe handles files with this extension, as seen in the screenshot below showing the file extension association in the registry:

Underneath, the .devicemanifest-ms and .devicemetadata-ms files are cabinet files. When a user opens one of these files, DeviceMetadataWizard.exe automatically extracts their contents into the current user’s temp folder.

DeviceMetadataWizard.exe’s cabinet extraction is vulnerable to path traversal due to concatenation of the temporary directory’s path with file names in the cabinet file. An attacker can create a malicious cabinet file containing a file whose name contains relative path specifiers (e.g. ..\..\..\file.txt). When a victim user clicks on the malicious .devicemanifest-ms or .devicemetadata-ms file and DeviceMetadataWizard.exe opens, DeviceMetadataWizard.exe will automatically extract the cabinet file and the files inside the cabinet archive will be concatenated with the temporary directory’s path. If a file in the cabinet archive contains relative path specifiers, then DeviceMetadataWizard.exe will extract the files to an unintended location.

As .devicemanifest-ms and .devicemetadata-ms are not subject to Mark of the Web and therefore not protected by SmartScreen, the file types are candidates for use in targeted phishing attacks.

Proof of Concept

In cmd.exe:

1. copy C:\windows\system32\cmd.exe AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.exe
2. makecab.exe AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.exe out.devicemanifest-ms
3. Now, in your favorite text/hex editor, open out.devicemanifest-ms and replace the string “AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.exe” with “..\..\..\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\AAAAAAAAAAAA.exe”

1. Double click on out.devicemanifest-ms

Expected Result

Upon double clicking out.devicemanifest-ms, the file type should fail to load. All embedded files are safely extracted to the temp folder and deleted upon the exit of DeviceMetadataWizard.exe.

Actual Result:

Upon double clicking out.devicemanifest-ms, the file fails to load, but DeviceMetadataWizard.exe writes the file “AAAAAAAAAAAA.exe” to the folder C:\users\<user>\appdata\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ AAAAAAAAAAAA.exe.

Prevention and Detection Guidance

Only users with the Windows Driver Kit installed are affected by this vulnerability (likely developers). Therefore, the overall attack surface is fairly limited.

In terms of prevention, it’s very likely that developers do not even use the Device Metadata Authoring Wizard. Therefore, consider removing this tool if it’s not in use. To reduce the impact of this vulnerability on machines where the tool is used, consider removing the .devicemanifest-ms and .devicemetadata-ms file association handlers by deleting the following registry keys:

• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.devicemetadata-ms
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.devicemanifest-ms

Also consider blacklisting the .devicemanifest-ms and .devicemetadata-ms file types using your email and web content filtering appliances.

If you have an application whitelisting solution in place, the likelihood of exploitation is greatly decreased as an attacker would need to leverage an application whitelisting bypass in order to gain arbitrary code execution.

In terms of host-based detections, baseline the normal behavior of DeviceMetadataWizard.exe in your environment and alert on anomalous file writes. In particular, baseline the typical folders where certain file extensions are written (e.g. is it common for any other file extension besides .devicemanifest-ms and .devicemetadata-ms, to be written outside of the %TEMP% folder?).

Disclosure Timeline

As committed as SpecterOps is to transparency, we acknowledge the speed at which attackers adopt new offensive techniques once they are made public. This is why prior to publication of a new bug or offensive technique, we regularly inform the respective vendor of the issue, supply ample time to mitigate the issue, and notify select, trusted vendors in order to ensure that detections can be delivered to their customers as quickly as possible.

• September 25, 2018 — Initial report to MSRC
• September 27, 2018 — Report acknowledgement received from MSRC and case number assigned
• October 4, 2018 — MSRC sends email stating they’re investigating how to address the issue.
• December 18, 2018 — Send email asking for an update.
• December 18, 2018 — MSRC responds saying they’re still figuring out how to address the issue.
• December 19, 2018 — MSRC notified that a blog post is written and will be released at the beginning of the year. Replied asking if it will be patched by then.
• December 19, 2018 — MSRC states it likely won’t be patched by January and asks to review blog post.
• Holiday break
• January 21, 2019 — MSRC follows up about the blog post.
• January 23, 2019 — Responded with blog posts
• January 23, 2019 — MSRC responds and says it will distribute the post applicable team members.
• January 30, 2019 — Inform MSRC that of plan to release post on February 6 and ask for if there’s any additional information about the timeline for a patch.
• January 30, 2019 — MSRC states that the release date should be okay and that they are still actively discussing the issue and will get back to me in 24 hours.
• January 30, 2019 — MSRC states that they plan to fix the issue in a future version of the Windows Driver Kit, but older versions will remain vulnerable since there is no update mechanism for the Windows Driver Kit. MSRC also states that the Windows Defender team has reviewed the post and is considering mitigation options.