Yet another zero-day (sort of) in Windows “search URL” handling

Just as the dust started to settle on the weirdly-named Follina vulnerability…

… along came another zero-day Windows security hole.

Sort of.

We’re not convinced that this one is quite as dramatic or as dangerous as some of the headlines seem to suggest (which is why we carefully added the words “sort of” above), but we’re not surprised that researchers are currently looking for new ways to abuse the many proprietary URL types in Windows.

URL schemes revisited

To recap.

The Follina bug, now more properly known as CVE-2022-30190, hinges on a weird, non-standard URL supported by the Windows operating system.

Loosely speaking, most URLs are structured so they tell you, or the software you’re using, where to go, how to get there, and what to ask for when you arrive.

For example, the URL…

     https://example.com/ask/forthis.item  

…says, “Use the scheme called https: to connect to a server called example.com and then request a file called /ask/forthis.item.”

Similarly, the URL…

     file:///Users/duck/thisone.txt  

…says, “Look for a file on the local computer called thisone.txt in the directory /Users/duck“.

And the URL…

     ldap://192.169.1.79:8888/Runthis  

…says, “Do an LDAP lookup via TCP port 8888 to server 192.168.1.79, and search for an object called Runthis.

But Windows includes a lengthy list of proprietary URL schemes (the letters up to the first colon character), also known as protocol handlers, that can be used to trigger a range of non-standard activities simply by referencing the special URL.

The Follina bug, for example, took devious advantage of the URL scheme ms-msdt:, which relates to system diagnostics.

This ms-msdt: scheme, which we assume made sense at the time it was implemented even though it seems foolhardy now, says, “Run the Microsoft Support Diagnostic Tool”, a program called MSDT.EXE that is meant to walk you through a series of basic steps when troubleshooting a misbehaving app.

But a bunch of cybercriminals discovered that you can abuse the ms-msdt: protocol handler by means of a URL embedding inside a document or email that’s opened by Outlook or Office.

With a rogue ms-msdt: URL, attackers can not only silently launch the MSDT.EXE app on your computer, but also feed it a bunch of rogue PowerShell script code to force you into running malware of their choice.

Instead of helping you troubleshoot your computer, the crooks exploit MSDT into infecting it instead.

The URLs you’ve never heard of

It turns out that ms-msdt: isn’t the only weird-and-wonderful Windows-specific URL scheme that Microsoft has dreamed up.

There are numerous “helper” URL schemes, standard and non-standard, hooked up to protocol handlers via entries in the Windows registry.

These registry keys signify that special actions should be triggered when someone tries to access the relevant URLs.

For example, as you know from experience, accessing an https: URL usually fires up your browser, if it isn’t running already.

And, as we explained above, visiting an ms-msdt: URL fires up MSDT.EXE, although we suspect that very few people knew that before the start of this week. (We didn’t – we’d never used or even seen a URL of that type before the Follina story broke.)

Well, a cybersecurity researcher known as @hackerfantastic has uncovered a Windows URL scheme called search-ms: that could, like ms-msdt:, be misused for cybercriminal treachery.

As we’ve already said, we’re not quite convinced this sits in what we’d call “zero-day exploit” territory, because it doesn’t lead directly to unexpected remote code execution…

…but we accept that it’s a close call, and that you may want to block this special URL from working in future.

The “search URL” trick

Simply put, search-ms: URLs will pop up and perform a Windows search automatically, as though you’d clicked on the magnifying glass in the task bar yourself, entered text of your choice, and waited for the result.

And by embedding this type of URL in a document such as a DOC or RTF file, in much the same way that the Follina trick was pulled off, an attacker can therefore lure you into opening a document, and then automatically pop up an official-looking list of search results in association with it:

Microsoft Office 2019 / Windows 10 / search-ms: URI handler exploitation and post-exploitation steps to SYSTEM. pic.twitter.com/r512uF3vQ4

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

The attackers who embed the special URL in the booby-trapped document get to choose, in advance, what appears in the title of the search bar, and which files to display.

The files that show up don’t have to be locally-stored files such as C:Usersduckmypreso.ppt, but can be remote files (UNC paths) such as \live.sysinterals.compsshutdown.exe or \example.orgdodgy.exe.

Of course, this doesn’t automatically launch the offending files, which is why we only consider this a “sort of” zero-day.

You still need to choose one of the files, double-click to execute it and react to a security warning, as you see in the Twitter video above.

Nevertheless, this trick certainly puts you much more believably into harm’s way than an old-school email lure with suspicious-looking web links in it.

The window that pops up isn’t a browser or an email client.

Instead, it looks just like what you’d see if you did a regular search on your local computer, and doesn’t contain anything that looks like a traditional web link.

What to do?

• Never open files without double-checking their names. Don’t assume that files turning up in a Windows search dialog are local files you can trust, especially if the search isn’t one you initiated deliberately yourself. If in doubt, leave it out!
• Remember that remote filenames aren’t as obvious as web links. Windows allows you to access files by drive letter or by UNC path. A UNC path often refers to a server name on your own network, e.g. \MAINSRV, but can equally well refer to remote servers on the internet, such as \files.example.com or 198.51.100.42. Double-clicking on a remote file specified as a UNC path will not only download it in the background from the specified server, but also launch it automatically once it’s arrived.
• Consider deleting the registry entry HKEY_CLASSES_ROOTsearch-ms. This is a similar mitigation to the one used for the Follina bug, where you delete the ms-msdt entry instead. This breaks the magic connection between clicking on a search-ms: URL and the activation of the search window. After deleting the registry entry, search-ms: URLs have no special meaning, and therefore don’t trigger anything.
• Watch this space. We won’t be surprised if other proprietary Windows URLs make the cybersecurity news over the next few days or weeks, pressed into service for devious or even directly destructive purposes by cybercriminals, or simply just uncovered by researchers trying to push the limits of the system as it stands.