A new Outlook attack method – Microsoft in denial
Sensepost has revealed an interesting way to hack your computer via Outlook. Microsoft’s public response has been to deny there’s a problem and put the responsibility on customers.
The method hasn’t been used ‘in the wild’ and it’s not easy to infect Outlook. But we’ve heard that before (especially from Microsoft) and history tells us that any technically possible hack will find a way to infect Office.
Outlook Forms run code
Outlook Forms are used to run code on your computer. That code can infect your computer, even if you’ve disabled ‘all’ macros.
Forms have been in Outlook for years and anyone can access them via the Developer tab. What’s less well known is that all the Outlook views (email, calendar, contacts) are really forms. Which form you get depends on the setting of the Outlook item; an email item will display the email form etc.
Hackers can create a special form and an Outlook item to trigger it via a tricky email.
The attack isn’t limited to a single computer. Exchange Server (including Office 365 mail hosts) save all custom forms to be synced with other computers using the same account.
Blocking VBA won’t work!
All this is possible because Outlook forms can start VBA code.
You might think that’s OK because you (or your network admin) has turned off the VBA feature in Outlook. Think again …
Forms access to VBA is separate from the usual VBA macro engine. The usual Macro Settings in the Trust Center do NOT apply – amazing but true.
In other words, this default setting in Outlook reportedly does NOT stop VBA via Forms. “Notifications for digitally signed macros, all other macros disabled” isn’t true at all.
We did some quick tests and we’re amazed to see that it’s true. An Outlook Form can run VBA code even if the Outlook Macro Setting is to disable ALL macros.
Redmond’s response will be wearily familiar to anyone who has been reading Office-Watch.com for the last two decades. It’s Redmond’s usual line; part denial and part blaming customers.
Here’s their official response:
“The technique described in the blog is not a software vulnerability and can only be leveraged using an account that has already been compromised by another method. We encourage customers to set strong passwords, not share those passwords across multiple services and enable security features such as multi-factor authentication to help keep them protected.”
All that’s pure sophistry. It’s probably some boilerplate PR text for these occasions. It’s untrue in parts and irrelevant in others.
The PR response deliberately ignores the key point that their own Outlook security setting is supposed to block ‘all macros’ and clearly doesn’t.
It’s hard to see how this isn’t a ‘software vulnerability’. A setting to block ‘all macros’ doesn’t do that – that’s a security vulnerability. Microsoft denying something doesn’t make it true – it just means Microsoft is lying.
It’s true that getting a hacked form (with VBA code) into Outlook isn’t easy, but there’s plenty of other, much harder hacks, that have been used.
The second sentence is just standard security advice .. strong passwords, don’t share, multi-factor authentication etc.
Microsoft’s advice to ‘enable security features’ shows they don’t understand the hack. If someone enables the Outlook security feature to ‘disable all macros’ it won’t prevent an attack at all.
We can only hope that behind this laughable PR façade, Microsoft is working on a fix.
For a start, making sure that the security setting to block ‘all macros’ truly does that. How about it Microsoft? Less PR nonsense and more protection for your paying customers.