Yesterday, we wrote that Microsoft had decided to turn off a handy software deployment feature, even though the company described itself as “thrilled” by the feature, and described its functionality as “popular”.
#ICYMI, that was about the use of so-called App Bundles to make software available for download via your browser.
By clicking on an App Bundle link (which starts with ms-appinstaller:// instead of the more usual https://), you would kickstart an installation process that looked much more official and trustworthy than just downloading an EXE file.
Criminals learned how to abuse App Bundles in order to give the impression that their malware installers were somehow approved or vetted by Microsoft, almost as though the download had come from the Microsoft Store itself (it hadn’t).
So, for the greater good of all, Microsoft essentially told its own software to block a useful feature of its own software, until further notice, at any rate:
This sort of thing doesn’t happen often, especially at Microsoft.
But no sooner had we written up the App Installer changes than we received an ever bigger – and, if we’re honest, a better – surprise…
… when Microsoft announced a change to the security settings in Office.
Macro code from the internet will at last be turned off by default!
Fin de siècle
If you’ve been in cybersecurity since the last millennium, you will certainly remember, and may still have occasional nightmares about, Microsoft Office macro viruses.
In fact, macro viruses were already a problem even before the Office apps merged into a suite of tools with a common macro coding language known as VBA, short for Visual Basic for Applications.
Before 1997, for example, Microsoft Word had its own scripting languge called WordBasic – similar to VBA, but not compatible with it – that was widely abused by malware writers for programming self-speading computer viruses.
But VBA was more powerful, more standardised, and once Office appeared, the malware writers took to it like… well, like a duck to water.
Simply put, if an Office document contained an embedded macro with a name that matched one of the Office menu options, then that macro would be triggered automatically whenever the user clicked on that menu item.
This made it easy for companies to adapt the behaviour of their Office apps to match their own workflow, which was enormously handy if you needed or wanted such a feature, for example to limit documents labelled ‘confidential’ from being printed out by mistake.
Even more dramatically, some special event-based macros, such as Auto_Open, were automatically triggered even if all you did was look at the document.
As a result, a malware writer who wanted to booby-trap a document file, getting it to run an embedded virus every single time the document was viewed, didn’t have to learn any special hacking or low-level coding skills at all.
As you probably know, the family of languages known as BASIC are meant to live up to their name. The word has even been wrangled backwards into the acronym Beginners’ All-purpose Symbolic Instruction Code, to remind you that it’s easy to learn because it was designed to be easy to learn.
Virus writing for everyone
Suddenly, anyone and everyone could be a virus writer.
Given that people typically exchanged Office documents many times a day (hundreds or thousands of times more frequently than they ever exchanged programs, or EXE files), macro viruses quickly became an ever-present, ever-troublesome problem.
Part of the problem was that that the vast majority of users, who didn’t really need VBA at all, were forced to have it installed and enabled by default.
Even those who didn’t want it and knew they didn’t want it couldn’t choose to skip the VBA part at installation time, or reliably turn it off afterwards.
For years, the cybersecurity industry urged Microsoft to change the Office defaults to allow installs where VBA functionality could be turned off (at the least), omitted entirely if desired (better still), or not installed by default at all (best of all).
The answer was always a resounding “No”.
Microsoft’s annoying, but understandable, argument was that endpoint software products generally get judged, by users and reviewers alike, based on what they do “out ot the box”.
Redmond suggested that full-power-Office-with-non-default-VBA would quickly become known in the market as a low-end-document-suite-with-no-macro-support-at-all, and thus the company would effectively be undermining its own product to give more aggressive competitors an unfair advantage.
(We’ve simplified enormously, but you get the idea, and anyone who has ever worked in a product management department or in product marketing will probably sympathise with Microsoft’s position. If your regular product already has features that influential customers expect, you don’t do yourself any favours by pretending that it doesn’t.)
Gradual restrictions and improvements
Ultimately, Microsoft did come to the cybersecurity party, and made steady changes to the VBA ecosystem that definitely helped to curb the virus writers’ “free-for-all” that existed in the late 1990s.
Sample security-related changes include:
- Making it easier and quicker to detect whether a file was a pure document, thus swiftly differentiating between document objects containing no macros at all, and template files with macro code inside. In the early days of macro viruses, back when computers were much slower than today, significant malware-like scanning was needed on every document file just to figure out if it needed scanning for malware.
- Making it harder for templates containing malware macros to copy them outwards into an as-yet uninfected file. Unfortunately, although this helped to kill off self-spreading macro malware (what we call true computer viruses), it didn’t prevent macro malware in general. Criminals could still create their own booby-trapped files up front and send them individually to each potential victim, just as they do today, without relying on self-replication to spread further.
- Popping up a ‘dangerous content’ warning so that macros can’t easily run by mistake. As useful as this feature is, because macros don’t run until you choose to allow them, crooks have learned how to defeat it. They typically add content to the document that helpfully “explains” which button to press, often providing a handy arrow pointing at it, and giving a believable reason that disguises the security risk.
- Adding Group Policy settings for stricter macro controls on company networks. For example, administrators can block macros altogether in Office files that came from outside the network, so that users can’t click to allow macros to run in files received via email or downloaded the web, even if they want to. But this setting is currently off by default.
More change coming soon
We still haven’t reached the point where an informed user with a local Office installation can remove VBA entirely and open Office files in a world in which VBA cannot work, rather than simply not working (which is nearly, but ultimately not at all, the same thing).
But Microsoft claims that this year’s Office 2203 releases will have one significantly different default – different by Redmond’s standards, anyway:
VBA macros obtained from the internet will now be blocked by default.
For macros in files obtained from the internet, users will no longer be able to enable content with a click of a button. A message bar will appear for users notifying them with a button to learn more. The default is more secure and is expected to keep more users safe including home users and information workers in managed organizations.
It took us ages to figure out the version number 2203. Having lived through Y2K – and, indeed, having been on duty in SophosLabs at that magical midnight hour, we’ve naively assumed that no one in the world, let alone anyone in IT or computer science, would now knowingly write the year as YY instead of YYYY. But 2203 apparently refers to “March 2022”, which means official releases starting in early April 2022.
According to Microsoft, any document tagged as having come from the internet, e.g. an email attachment or a web download, will be treated as though it contains no macros.
By default, you won’t be able to enable the macros from inside Office, even if you’re convinced (or are certain) that the macros are both expected and trustworthy.
Instead, says the report, you’ll see this:
Not exactly a victory over VBA malware
We’re delighted to see this change coming, but it’s nevertheless only a small security step for Office users, because:
- VBA will still be fully supported, and you will still be able to save documents from email or your browser and then open them locally in such a way that embedded macros will be permitted. We can therefore expect cybercriminals to come up with circumlocutions, helpful diagrams and even what sound like “security conscious” reasons for opening documents in a more convoluted but insecure way.
- The changes won’t reach older versions of Office for months, or perhaps years. Even the current version won’t include this change in all update channels until January 2023 at the earliest. Change dates for Office 2021 and earlier haven’t even been announced yet.
- Mobile and Mac users won’t be getting this change.
- Not all Office components are included. Apparently, only Access, Excel, PowerPoint, Visio, and Word will be getting this new setting. Although those file types cover the majority of attacks, it would be better if this macro-blocking feature applied to all Microsoft products without fear or favour.
For further information, consult Microsoft’s official article, Macros from the internet will be blocked by default in Office.