Just as the dust started to settle on the weirdly-named Follina vulnerability…
… along came another zero-day Windows security hole.
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
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…
…says, “Use the scheme called https: to connect to a server called
example.com and then request a file called
Similarly, the URL…
…says, “Look for a file on the local computer called
thisone.txt in the directory
And the URL…
…says, “Do an LDAP lookup via TCP port 8888 to server
192.168.1.79, and search for an object called
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.
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
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:\Users\duck\mypreso.ppt, but can be remote files (UNC paths) such as
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!
- Turn on the Windows option to show file extensions. Annoyingly, Windows suppresses file extensions by default, so that a file such as
risky.exeshows up merely as
risky. This means that a file deliberately renamed to
readme.txt.exeends up apparently mislabelled as the innocent-looking
readme.txt. Open File Explorer and go to View > File Name Extensions.
- 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
\\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_ROOT\search-ms. This is a similar mitigation to the one used for the Follina bug, where you delete the
ms-msdtentry 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.