Microsoft blocks web installation of its own App Installer files

Late last year (November 2021), we reported on an unusual campaign of scammy emails warning recipients that they were in big trouble at work.

If you saw one of these, you’ll probably remember it: a customer had made a formal complaint and the company was scrambling to hold a meeting to investigate your alleged poor conduct…

…so you were expected to follow a link to download and read the complaint against you.

Here at Sophos, many of us were on the spamming list and received emails of this sort:

You’re fired!

Some of us subsequently received follow-up messages telling us that we were no longer technically in trouble, for the rather dramatic reason that we’d been fired; our “termination letters” were attached, once again as a document download link.

The downloads looked like PDF files:

But the download links weren’t conventional http:// or https:// downloads; instead, they relied on an unusual link starting ms-appinstaller://, which (on Windows, at least), triggers Microsoft’s App Installer system to orchestrate the download process.

This ms-appinstaller protocol not only takes you down a very different visual path than a traditional web download, but also mirrors the sort of experience that you would only ever have seen before, if you had seen it at all, when using the Microsoft Store.

Notably, the process insists on a digitally-signed application bundle (for bundle, think Android APK or Linux package), and therefore starts with a reassuring, if unfamiliar, popup assuring you, with a confident-looking green tick (check mark), that this is a Trusted App, apparently coded by a vendor you know:

Note that in the screenshot above, the publisher’s name (fraudulently given as “Adobe Inc.”) is just a text string in the app bundle itself; to “verify” the signer, you need to click on the blue text Trusted App].

Unfortunately, the signer’s name doesn’t tell you much at all, or at least it didn’t last year when we first saw this trick used for distributing “trusted” malware.

Rogue signing made easy

In the example above, the app signer claimed to be a accounting firm and was a registered UK business.

But if you had chased it further than that, you would have found a company that had never really done any business, was located at an unlikely address, and was about to be deregistered anyway.

Simply put, based on an online-and-apparently-never-used-for-real company registration that probably cost just a few pounds (and who knows whether the attackers actually paid anything for it, or simply acquired access to the company data via an earlier hack or data breach?), cybercriminals were able to:

• Acquire a “trusted” signing key and use it to sign App Installer bundles.
• Distribute an App Installer bundle that presented itself as a Trusted App, much like an app from the curated Microsoft Store.
• Trigger the installation via the Appinstaller.exe process, not more suspiciously via a browser.
• Install and activate numerous unsigned apps under the imprimatur of the signed, and allewgedly trusted, top-level bundle file.

In the you’ve-been-fired email example we encountered here at Sophos, the purveyors of the “Trusted App” turned out to be the BazarLoader malware gang.

So, if the legitimate-looking, Microsoft Store-like installation process was enough to ensnare your trust, you’d have ended up with persistent backdoor malware – what’s often referred to as a bot or zombie.

The backdoor bot started off by leaking system configuration information to the crooks, and then waited for remote instructions on what new malware to download and run next.

Cybercriminals with generic remote code executiuon (RCE) access like this typically use your computer as a pawn in the underground economy, “renting” it out – possibly repeatedly – to other crooks to conduct further cybercrimes, either against your computer, or via your computer, or both.

Sometimes, sadly, this sort of zombification only gets detected by the victim when the bot operators “rent out” the infected computer (or use it themselves) one last time for a final round of malware that you can’t help but notice…

…typically, a ransomware attack.

More security implied that an HTTPS certificate

Note that the level of cybersecurity belief you are invited to adopt in the case of an ms-appinstaller:// download is significantly greater than the cybersecurity inference you’re expected to make from a regular https:// web certificate.

Web certificates, which use the TLS (transport layer security) protocol to encrypt and to integrity-check the data exchanged in an HTTP session between a client and the server, don’t say anything about how trustworthy the site at the other end actually is.

Indeed, browser makers have gone out of their way, over the past decade or so, to adjust the words, icons and colours used in the browser itself to describe an HTTPS-protected site.

After all, TLS, by design and by definition, provides transport-level security, thus putting the S (for secure) in HTTP (short for hypertext transfer protocol), but doesn’t aim or claim to perform any verification or trust assessment for the content that’s transmitted.

Firefox, for example, still uses a padlock icon to denote a “secure” site, but annotates the padlock simply with the words “Connection secure” and “You are securely connected”, without making any claims about the site itself:

The Edge browser does something similar when you click on a website’s padlock, mentioning the confidentiality of the connection, but not suggesting that you can therefore ultimately trust the contents of the site:

This site has a valid certificate, issued by a trusted authority. This means information (such as passwords or credit cards) will be securely sent to this site and cannot be intercepted. Always be sure you’re on the intended site before entering any information.​

In contrast, the App Installer popup that verifies the digital signature of the App Bundle you’re downloading explicitly identifies the software itself as a Trusted App, even though it allows the signer of the app to include entirely bogus vendor data in the app bundle, and then helpfully displays that fraudulent “identification” directly beneath to the “Trusted App” designator.

This implies, in our minds, anyway, that a much higher cybersecurity bar has been reached: it acts as a type of content-level assertion that lives on after installation, rather than merely denoting some degree of transport-level security that protects the network part of the download only.

Recommended workarounds

We recommended, and still recommend, various security workarounds, including:

• Use a web filter, if you have one, to block the download of likely App Installer bundles. File extensions to block include: .msix, .appx, .msixbundle and .appxbundle.
• Use a web filter, if you have one, to prevent users from clicking on URLs that start with ms-appinstaller://. This is the special protocol (referred to in URL terminology as a scheme) used by Windows to fire up the App Installer to take over from your browser.
• Use Microsoft Group Policy settings, if possible, to prevent non-admin users from installing App Bundles at all. If that’s a step too far, lock down users so they can install App Bundles from the Microsoft Store only.

For the Group Policy tweaks that help with this issue (which was given the vulnerability idenfitier CVE-2021-43890), you can consult Microsoft’s published guidelines on which settings to use.

A step too far?

Our middle recommendation above might seem rather drastic, either for your internal users if your company relies on vendors that ship their software via App Bundles, or for external customers if you have gone down the App Bundle path for software delivery.

After all, App Bundles are supposed to have several advantages, notably for vendors with endpoint products that support a range of different Windows versions running on various computer types (e.g. Intel, AMD, ARM):

• One signed bundle to rule them all, digitially signed at the top level.
• User doesn’t need to figure out which of numerous distinct builds to use on their computer, so can’t end up with the wrong version.
• Web dowloads via the App Installer save bandwidth by omitting the parts that aren’t required.

In Microsoft’s own words:

The ms-appinstaller protocol handler was introduced to enable users to seamlessly install an application by simply clicking a link on a website. What this protocol handler provides is a way for users to install an app without needing to download the entire MSIX package. This experience is popular, and we are thrilled that it has been adopted by so many people today.

What to do?

Despite the upbeat paragraph at the end of the previous section, Microsoft isn’t so thrilled that cybercriminals have adopted this “seamless” process that works “by simply clicking a link”, as we documented for the first time last last year.

For the time being, at any rate:

We are actively working to address this vulnerability. For now, we have disabled the ms-appinstaller scheme (protocol). This means that App Installer will not be able to install an app directly from a web server. Instead, users will need to first download the app to their device, and then install the package with App Installer. This may increase the download size for some packages.

In other words, Microsoft itself has given up entirely on supporting its own ms-appinstaller:// URL type via the web, because it thinks the process is still too easily abused.

Therefore:

• If you use App Bundles to distribute your own software, you will need to change either your software packaging process, or your installation instructions, or both. Otherwise, potential customers may assume that your software is no longer compatible with their computer or their network, and shop elsewhere.
• If you rely on vendors who distribute programs via App Bundles, you will need to change your deployment and updating procedures. Otherwise you might end up out of date, or with unhappy internal users.