Perpetual IT

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:\Users\duck\mypreso.ppt, but can be remote files (UNC paths) such as \\live.sysinterals.com\psshutdown.exe or \\example.org\dodgy.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_ROOT\search-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.

---

The latest scheduled Firefox update is out, bringing the popular alternative browser to version 101.0.

This follows an intriguing month of Firefox 100 releases, with Firefox 100.0 arriving, as did Chromium 100 a month or so before it, without any trouble caused by the shift from a two-digit to a three-digit version number.

Early in 2022, as both Chromium and Firefox co-incidentally approached their centuries at about the same time, it looked as though at least a few mainstream websites were extracting version numbers for both products incorrectly.

Some sites, it seemed, were searching the browsers’ User-Agent text strings for patterns that were hard-wired to extract just two digits’ worth of version information.

As you can imagine, folding three digits into two gives you an error a bit like the millennium bug, with 100 turning either into 10 or into 00, depending on which end you prune.

Both 0 and 10 represent version numbers from a time long past, thus incorrectly flagging a brand-new browser as a recklessly outdated one, which some sites refused to accept.

No doubt in part due to the efforts of both Google’s Chromium and Mozilla’s Firefox coders (who combined to identify ill-behaved websites, and even prepared emergency “escape mechanisms” whereby their respesective browsers would continue calling themselves 99.something when visiting ill-programmed web servers), the 100.0 release of both browsers was ultimately uneventful…

…but Firefox followed its regular 100.0 release with an emergency 100.0.1 release, which turned on a brand new Windows security feature that hadn’t quite made the cut in 100.0.

We wondered why this new feature, which had been a long time in the brewing and wasn’t designed to fix a specific, known-to-be-exploitable security vulnerability, hadn’t simply been saved up and release as a new feature in the scheduled 101.0 version.

But the fact that it was just a couple of days before the notorious Pwn2Own hacking competition, where contestants are presented with bang-up-to-date computers on which to try their attacks, led us to assume (or at least to guess) that Mozilla figured that it was worth getting out an official release with additional anti-hacking protection, just in case.

Ultimately, however, Firefox was hacked, in a gloriously well-prepared double-exploit attack that took just seven seconds to break into the browser and then break back out of its protective shell for a full sandbox escape.

To its credit, Mozilla then released 100.0.2 within 48 hours, with fixes for both of these newly-disclosed bugs.

Less drama this time

We don’t doubt, therefore, that the somewhat less dramatic release of 101.0, with no zero-day security holes fixed, and no patches deemed Critical, will have been something of a relief to the Mozilla team.

In case you’re wondering, this was indeed the second full release of Firefox in the month of May 2022, which is Mozilla’s equivalent of a blue moon. (The moon doesn’t actually turn blue – that’s just the nickname used when there’s a second full moon squeezed into one calendar month).

This is caused by the fact that Firefox updates are scheduled for every fourth Tuesday, which is once every 28 days, rather than for a specific Tuesday in each month, which is once in about every 30.5 days.

Although none of the bugs fixed in this release are Critical, there are numerous High-category fixes, plus a handful of Moderate ones, including

• CVE-2022-31737: Heap buffer overflow in WebGL. A malicious webpage with booby-trapped graphics could caused a memory buffer overflow, typically leading to a crash, or perhaps even to remote code execution.
• CVE-2022-31738: Browser window spoof using fullscreen mode. Web pages aren’t supposed to be able to display content outside the confines of their own display area, thus leaving the browser itself with complete control of important user interface components such as the address bar and navigation buttons. A web page that could trick the browser into writing to the wrong part of the screen could bypass this “sanctity of display” protection.
• CVE-2022-31739: Attacker-influenced path traversal when saving downloaded files. When you specify a filename on Windows, some characters aren’t always treated literally. For example, a filename of %HOMEPATH% doesn’t necessarily get saved under that letter-for-letter filename. Unless you “escape” those percent signs to show they are meant literally, the special marker %HOMEPATH% is rewritten and replaced with the actual name of your home directory. Likewise, %WINDIR% denotes where Windows is installed, regardless of what directory was chosen at setup time. Programs that accept filenames from untrusted sources therefore need to take care to “escape” percent signs so that they mean exactly what they say (a % character), instead of sneakily triggering an rewrite that could misdirect a file from one directory into another.
• CVE-2022-31743: HTML Parsing incorrectly ended HTML comments prematurely. Anything between an opening text string of <!-- and a closing --> is treated as an HTML comment, and is skipped when the file is actually used. Misrecognising the end of a comment could lead to an otherwise innocent-looking page including content that wasn’t supposed to appear, or to a script element executing even though it was supposed to be ignored.
• CVE-2022-1919: Memory Corruption when manipulating webp images. This bug was essentially the opposite of a use-after-free, which is where a program hands back a block of memory so it can be used elsewhere in the program, but carries on writing to it anyway. This bug was what you might call a free-without-use, where Firefox attempted to “return” memory it hadn’t been given in the first place. This could lead to a crash, or perhaps even to remote code execution.

As well as these specific bugs, Mozilla also announced CVE-2022-31747 and CVE-2022-31748, vulnerability numbers designating a range of general memory mismanagement bugs found by the Firefox team and its automated bug-hunting tools.

These bugs weren’t examined in detail to see which ones could actually be exploited, but were assumed to be potentially exploitable and fixed anyway.

The first of these, CVE-2022-31747, denotes bugs fixed in both the 101.0 release and the Extended Support Release 91.10 (note that 91+10 = 101).

This implies that those bugs have been in Firefox’s codebase since the 91 release or even earlier, given that ESR 91.10 consists of the Firefox 91.0 code with all interim security fixes applied, but no new features added.

The latter designator, CVE-2022-31748, denotes bugs fixed in 101.0 only, and is a good reminder that new features do tend to bring new bugs, and helps explain why Mozilla maintains its ESR product branch.

The ESR flavour of Firefox is popular with network sysadmins who are willing to wait for new features, but not at the expense of running software that’s outdated from a security point of view.

What to do?

As usual, go to Help > About Firefox to check if you’re up to date, and to force an update if it turns out you aren’t.

(Linux/Unix users may need to refer to their distro for updates if they originally installed Firefox via a distro-managed package rather than by downloading Mozilla’s own installer.)

---

The internet is abuzz with news of a zero-day remote code execution bug in Microsoft Office.

More precisely, perhaps, it’s a code execution security hole hole that can be exploited by way of Office files, though for all we know there may be other ways to trigger or abuse this vulnerability.

Security researcher Kevin Beaumont has supplied it with the entirely arbitrary name Follina, and given that it doesn’t seem to have an official CVE number yet [2022-05-30T21:00Z], that name looks set both to stick and to be a useful search term.

The name is “derived”, if that is the right word, from the fact there’s a sample of an infected Word DOC file on Virus Total that goes by the name 05-2022-0438.doc. The numeric sequence 05-2022 seems pretty obvious (May 2022), but what about 0438? This is the dialling code for the area of Follina, not far from Venice in north-western Italy, so Beaumont applied the name “Follina” to the exploit as an arbitrary joke. There’s no suggestion that the malware came from that part of the world, or indeed that there is any Italian connection with this exploit at all.

How does it work?

Very loosely speaking, the exploit works like this:

• You open a booby-trapped DOC file, perhaps received via email.
• The document references a regular-looking https: URL that gets downloaded.
• This https: URL references an HTML file that contains some weird-looking JavaScript code.
• That JavaScript references an URL with the unusual identifier ms-msdt: in place of https:.
• 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 an MSDT command 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; you can answer a bunch of support-related questions; you can perform various automated tests on the app; and if you’re still stuck, you can choose to report the problem to Microsoft, uploading various troublehooting data at the same time.

Although 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.

Automatic remote script execution

Unfortunately, it looks as though the attackers who discovered the “Follina” trick (or the attackers who seem to have used this trick in various attacks last month, even if they didn’t figure it out themselves) have worked out a series of unusual but treacherous options to put on the command line.

These options make the MSDT troubleshooter do its job under remote control.

Instead of getting asked how you want to proceed, the crooks have crafted a sequence of parameters that not only cause operation to proceed automatically (e.g. the options /skip and /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.

In this case, the PowerShell was used to extract and launch a malware executable provided in compressed form by the crooks.

Threat researcher John Hammond at Huntress has confirmed, by way of launching CALC.EXE to “pop a calculator”, that any executable already on the computer can be directly loaded by this trick, too, so an attack could use existing tools or utilities, without relying on the perhaps more suspicious approach of launching a PowerShell script along the way.

No macros neeeded

Note that this attack is triggered by Word referencing the rogue ms-msdt: URL that’s referenced by a URL that’s contained in the DOC file itself.

No Visual Basic for Applications (VBA) Office macros are involved, so this trick works even if you have Office macros turned off completely.

Simply put, this looks like what you might call a handy Office URL “feature”, combined with a helpful MSDT diagnostic “feature”, to produce an abusable security hole that can cause a click-and-get-hit remote code execution exploit.

In other words, just opening up a booby-trapped document could deliver malware onto your computer without you realising.

In fact, John Hammond writes that this trick can be turned into an even more direct attack, by packaging the rogue content into an RTF file instead of a DOC file. In this case, he says, just previewing the document in Windows Explorer is enough to trigger the exploit, without even clicking to open it. Just rendering the thumbnail preview pane is enough to trip Windows and Office up.

What to do?

We’re guessing that Microsoft will soon come up with an official workaround, and hopefully, soon after that, a permanent patch, to prevent this “feature” from being used as an exploitable bug in future.

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 file are opened, or even just previewed, is clearly a security risk.

Right now (unfortunately, it’s a public holiday in the US), a workaround that’s generally agreed upon in the community is simply to break the relationship between ms-msdt: URLs and the MSDT.EXE utility.

You can do this by removing the registry entry HKEY_CLASSES_ROOT\ms-msdt, which removes any special meaning from URLs starting ms-msdt:.

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 tool and hit [Delete].

Or you can run the command REG DELETE HKCR\ms-msdt.

If you discover that you just can’t live without ms-msdt URLs, you can always replace the missing registry data later.

Just for the record, we’ve never even seen an ms-msdt URL before, let alone relied on one.

---

HOW SOPHOS PRODUCTS DETECT AND REPORT THESE ATTACKS

• Sophos endpoint products detect and block known attacks conducted via this exploit as Troj/DocDl-AGDX. You can use this detection name to search your logs both for DOC files that trigger the original download, and for HTML “second stage” files that follow.
• Sophos email and web filtering products intercept attack files of this sort as CXmail/OleDl-AG.

---

Home delivery scams, where the crooks falsely apologise to you for not delivering your latest parcel, have been around for years.

However, as we have unfortunately needed to say many times on Naked Security, these scams seem to have become steadily more professional-looking during the pandemic, as more and more people have got into the habit of ordering deliveries for everyday shopping instead of heading into stores.

For example, here’s a contemporary SMS-based scam (phishing that is kicked off by a text message, or SMS, is wryly known as smishing) that makes a good “picture story” of how these cybercrimes unfold.

In this criminal campaign, the scammers were targeting a home delivery company in the UK called Evri.

Unfortunately, and perhaps entirely deliberately on the part of the criminals, “Evri” is a recent UK-specific rebrand of the German company “Hermes”, so that UK customers may very well still be getting used to the new look and feel of the rebranded website, and to the new domain name.

Officially, the company’s web presence is at evri.com, so these crooks have grabbed a domain of the form evri-xxxxxxx.com to make things seem believable:

By the way, the domain used in this attack was first registered just yesterday, probably for use in this scam only, and at the time of writing, the content was served up by a hosting company based in Moscow, Russia.

Hosting companies typically provide ready-to-go web server templates, complete with HTTPS certificates that put a padlock in the address bar, and even if the service provider is responsive to complaints and turns off the website within a day or two, the crooks may well have got everything they were after from their fake server already.

When we tried the URL in this scam, we routinely experienced HTTP 404 errors (page not found) when visiting from a regular browser, meaning that the website was alive and responding, but effectively ignoring our requests.

As soon as we used a mobile browser, however, as you are likely to do when receiving a link directly on your mobile phone, the site sprang to life:

As you can see in the top left corner, underneath the popup asking for your postcode, the crooks have inserted a realistic Evri logo, even retaining the official text The new Hermes to “remind” visitors about the brand change.

You should baulk at the next page, of course, because delivery companies don’t ask for personal ID merely for parcel tracking purposes, but there are no obvious visual or spelling errors to warn you off:

Next, there’s a fake charge for a modest amount that doesn’t sound too much to lose if the transaction turns out to be fraudulent…

…except that the “redelivery charge” is there merely to give the the criminals an excuse to to ask for payment details:

If you put your credit card number and bank details into this page, you aren’t going to lose £1.45 (just under $2)…

…you’re going to lose your personal details to the crooks, who will probably use your card or bank account details themselves for a much more ambitious scam, or will sell them on to other crooks who specialise in that aspect of the cybercrime “business sector”.

Finally, there’s a short delay while the site pretends to “verify” your payment, after which the bogus site sneakily transfers you to the real one, so things appear to have ended normally:

What to do?

• Check all URLs carefully. Learn what server names to expect from the companies you do business with, and stick to those. Bookmark them for yourself in advance, based on trustworthy information such as URLs on printed statements or account signup forms.
• Steer clear of links in messages or emails if you can. Legitimate companies often provide quick-to-click links to help you jump directly to useful web pages for online accounts such as utility bills. These links save you a few seconds because you don’t need to find and type in your own tracking code or account number by hand. But you’ll never get caught out by fake links if you never use in-message links at all! (See point 1 above.) Those few seconds are a small price to pay for not paying the large price of handing over your personal data to cybercriminals.
• Report compromised cards or online accounts immediately. If you get as far entering any banking data into a fake pay page and then realise it’s a scam, call your bank’s fraud reporting number at once. Look on the back of your actual card so you get the right phone number. (Remember that you don’t have to click [OK] or [Continue] for a web form to capture any partial data you have already entered.)
• Check your bank and card statements. Don’t just look for payments that shouldn’t be there, but also keep an eye out for expected payments that don’t go through. Be alert for incoming funds you weren’t expecting, too, given that you can be called to account for any income that passes through your hands, even if you neither asked for it nor expected it.

And, of course, when it comes to personal data of any sort: if in doubt, don’t give it out.

---

EVRI’S SITE IN REAL LIFE

In real life, Evri’s site is at evri.com, not at any variations on that theme. The company has an official track-your-parcel page at this easily bookmarked URL:

https://www.evri.com/track-a-parcel

Find your own way there and you will see that the company doesn’t rely on personal data such as name and date of birth for parcel tracking – instead, the company uses one-off tracking or non-delivery codes:

These 16-digit and 8-digit codes are explained clearly at the site’s own help page:

https://www.evri.com/faqs/receiving-a-parcel/how-do-i-track-my-parcel

Find your own way to get in touch with the real sender to find out the 16-digit code if ever you need it.

And remember that the company’s 8-digit “calling card” codes are printed on physical calling cards you should find at your own doorway, thus gving you some confidence that a delivery really was attempted.

Don’t be fooled by emails or unsolicited electronic messages that could have come from anywhere: