New Windows Search zero-day added to Microsoft protocol nightmare

A new Windows Search zero-day vulnerability can be used to automatically open a search window containing remotely-hosted malware executables simply by launching a Word document.

The security issue can be leveraged because Windows supports a URI protocol handler called ‘search-ms’ that allows applications and HTML links to launch customized searches on a device.

While most Windows searches will look on the local device’s index, it is also possible to force Windows Search to query file shares on remote hosts and use a custom title for the search window.

For example, the popular Sysinternals toolset allows you to remotely mount live.sysinternals.com as a network share to launch their utilities. To search this remote share and list only files matching a particular name, you could use the following ‘search-ms’ URI:

search-ms:query=proc&crumb=location:%5C%5Clive.sysinternals.com&displayname=Searching%20Sysinternals

As you can see from the command above, the search-ms ‘crumb’ variable specifies the location to search, and the ‘displayname’ variable specifies the search title.

A customized search window will appear when this command is executed from a Run dialog or web browser address bar on Windows 7, Windows 10, and Windows 11, as shown below.

Notice how the window title is set to the ‘Searching Sysinternals’ display name we specified in the search-ms URI.

Threat actors could use this same approach for malicious attacks, where phishing emails are sent pretending to be security updates or patches that need to be installed.

They can then set up a remote Windows share that can be used to host malware disguised as security updates and then include the search-ms URI in their phishing attachments or emails.

However, it would not be easy to get a user to click on a URL like this, especially when it displays a warning, as shown below.

But Hacker House co-founder and security researcher Matthew Hickey found a way by combining a newly discovered Microsoft Office OLEObject flaw with the search-ms protocol handler to open a remote search window simply by opening a Word document.

Microsoft Office takes it to the next level

This week, researchers discovered that threat actors were utilizing a new Windows zero-day vulnerability in Microsoft Windows Support Diagnostic Tool (MSDT). To exploit it, threat actors created malicious Word documents that launched the ‘ms-msdt’ URI protocol handler to execute PowerShell commands simply by opening the document.

Identified as CVE-2022-30190, the flaw makes it possible to modify Microsoft Office documents to bypass Protected View and launch URI protocol handlers without interaction by users, which will only lead to further abuse of protocol handlers.

This was seen yesterday when Hickey converted existing Microsoft Word MSDT exploits to use the search-ms protocol handler we described earlier.

With this new PoC, when a user opens a Word document, it will automatically launch a ‘search-ms’ command to open a Windows Search window that lists executables on a remote SMB share. This share can be named whatever the threat actor wants, such as ‘Critical Updates,’ prompting the users to install the listed malware.

Microsoft Office search-ms: URI handler exploitation, requires user-interaction. Unpatched. pic.twitter.com/iYbZNtMpnx

— hackerfantastic.crypto (@hackerfantastic) June 1, 2022

Like the MSDT exploits, Hickey also showed that you could create RTF versions that automatically open a Windows Search window when the document is rendered in the Explorer preview pane.

Here is the same search-ms attack being leveraged through an RTF document when Windows Preview Pane is enabled… 😉 pic.twitter.com/AmOeGWltjm

— hackerfantastic.crypto (@hackerfantastic) June 1, 2022

By using this type of malicious Word document, threat actors can create elaborate phishing campaigns that automatically launch Windows Search windows on recipients’ devices to trick them into launching malware.

While this exploit is not as severe as the MS-MSDT remote code execution vulnerability, it could lead to abuse by industrious threat actors who want to create sophisticated phishing campaigns.

Although we’ve already found ways threat actors could exploit this new flaw in the wild, we’re not going to share this information for obvious reasons.

To mitigate this vulnerability, Hickey says you can use the same mitigation for ms-msdt exploits – delete the search-ms protocol handler from the Windows Registry.

1. Run Command Prompt as Administrator.
2. To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOTsearch-ms search-ms.reg“
3. Execute the command “reg delete HKEY_CLASSES_ROOTsearch-ms /f“

A Windows ProtocolNightmare

Both the MSDT and search-ms abuse examples are not new, initially disclosed by Benjamin Altpeter in 2020 in his thesis about Electron application security.

However, it wasn’t until recently that they started to be weaponized in Word documents for phishing attacks without user interaction, which turned them into zero-day vulnerabilities.

Based on Microsoft’s guidance for CVE-2022-30190, the company appears to be tackling the flaws in the protocol handlers and their underlying Windows features, rather than the fact that threat actors can abuse Microsoft Office to launch these URIs without user interaction.

As CERT/CC vulnerability analyst Will Dormann says, these exploits actually utilize two different flaws. Without fixing the Microsoft Office URI issue, further protocol handlers will be abused.

Hickey also told BleepingComputer that he believes that this not necessarily a flaw in the protocol handlers, but rather a combination leading to a ‘Microsoft Office OLEObject search-ms Location Path Spoofing Vulnerability.’

“The next best thing is to fix the search abilities title and location setting messages to prevent such spoofing attacks or disable it as a URI handler,” explained Hickey in a conversation about the flaws.

In June, researchers accidentally disclosed the technical details and a proof-of-concept (PoC) exploit for a Windows Spooler RCE vulnerability named PrintNightmare.

While the RCE component was quickly fixed, a wide range of local privilege elevation vulnerabilities were discovered that continued to be disclosed under the ‘PrintNightmare’ classification.

It wasn’t until Microsoft made some drastic changes to Windows Printing that they finally got control of this vulnerability class, even though it caused numerous printing problems for some time.

By tackling the problem only at the protocol handler/Windows feature side, Microsoft is facing a whole new ‘ProtocolNightmare’ classification where researchers will continue to find new URI handlers to abuse in attacks.

Until Microsoft makes it impossible to launch URI handlers in Microsoft Office without user interaction, be prepared for a whole series of similar news articles as new exploits are released.

Source: www.bleepingcomputer.com