Microsoft Office RCE Bug
This vulnerability is exploiting users in a variety of ways, but mainly through Phishing emails. The exploit has been reported to work in the following way:
- You open a booby-trapped DOC file, received via email.
- The document references a regular-looking
https:URL that gets downloaded.
ms-msdt:in place of
- On Windows,
ms-msdt:is a proprietary URL type that launches the MSDT software toolkit.
- MSDT is shorthand for Microsoft Support Diagnostic Tool.
- The command-line supplied to MSDT via the URL causes it to run untrusted code.
When invoked, the malicious
ms-msdt: link triggers the MSDT utility with command line arguments like this:
msdt /id pcwdiagnostic ....
If run by hand, with no other parameters, this automatically loads MSDT and invokes the Program Compatibility Troubleshooter, which looks innocent enough, like this:
From here, you can choose an app to troubleshoot, answer a bunch of support-related questions, perform various automated tests on the app, and if you’re still stuck, you can choose to report the problem to Microsoft, uploading troubleshooting data at the same time.
You probably wouldn’t expect to get thrown into this
PCWDiagnostic utility just by opening a document, you’d at least see a series of popup dialogs and you’d get to choose what to do at every step of the way.
Unfortunately, instead of getting asked how you want to proceed, the crooks have crafted a sequence of parameters that not only cause the malicious operation to proceed automatically (e.g. the options
/force), but also to invoke a PowerShell script along the way.
Worse still, this PowerShell script doesn’t have to be in a file on disk already, it can be provided in scrambled source code form right on the command line itself, along with all the other options used. The PowerShell is used to extract and launch executable malware provided in compressed form by the hackers.
What Should You Do?
As convenient as Microsoft’s proprietary
ms-xxxx URLs may be, the fact that they’re designed to launch processes automatically when specific types of files are opened, or even just previewed, is certainly a security risk.
A workaround that was quickly agreed upon in the community, and has been officially endorsed by Microsoft, is simply to break the relationship between
ms-msdt: URLs and the MSDT utility. This means that
ms-msdt: URLs no longer have any special significance, and can’t be used to force
MSDT.EXE to run.
You can make this change simply by removing the registry entry
HKEY_CLASSES_ROOT\ms-msdt if it exists. If it’s not there, then you are already protected.
If you create a file with a name ending
.REG that contains this text…
Windows Registry Editor Version 5.00 [-HKEY_CLASSES_ROOT\ms-msdt]
…you can double-click the
.REG file to remove (the minus sign means “delete”) the offending entry.
You can also browse to
HKEY_CLASSES_ROOT\ms-msdt in the
REGEDIT utility and hit
Or you can run the command:
REG DELETE HKCR\ms-msdt.
Note that you need administrator privileges to modify the registry in this way.
If you discover that you just can’t live without
ms-msdt URLs, you can always replace the missing registry data later.
To back up the
HKEY_CLASSES_ROOT\ms-msdt registry key, use the command:
REG EXPORT HKEY_CLASSES_ROOT\ms-msdt backup-msdt.reg.
To restore the deleted registry key later, use:
REG IMPORT backup-msdt.reg.
You have a Vulnerability Alert Management Process, right?
If you’re a subscriber to CyberHoot’s services, you’ll have access to our Policy and Process library which contains the vulnerability alert management process document. This document prescribes how to respond to situations like this and in what time frame. If your company has not yet adopted a VAMP-like process, now is a great time to get started.