Tuesday, October 10, 2017

Exploiting Office native functionality: Word DDE edition

Sensepost researchers show a way to exploit DDE to run code from Word, without macros or buffer overflows. Here's how to detect it.

Updated 11 October: I originally wrote that this exploit technique bypassed both disabled macros, and Protected View. That is incorrect: this technique will work if macros are disabled, but the code does not trigger while in Protected View. Thanks to Matt Nelson (@enigma0x3) for pointing out my mistake.

I love reading exploit techniques that rely on native features of the operating system or common applications. As an attacker, I find it diabolically clever to abuse features the target fully expects to be used and cannot turn off without disrupting business. As a defender, I am intrigued by the challenge of detecting malicious use of perfectly legitimate features.

Researchers Etienne Stalmans and Saif El-Shereisuch of Sensepost wrote of a slick way to execute code on a target computer using Microsoft Word - but without the macros or buffer overflows usually exploited to this end. Instead, they use dynamic data exchange, or DDE - an older technology once used for coding and automation withyin MS Office applications. This is particularly clever because it works even with macros disabled - because it's not using the macro subsystem.

There are no "security" warnings for the user, as such, although there is a prompt asking if the user wants to start the application specified in the command. The authors suggest is is possible to tweak the command syntax to suppress this popup.

This document contains links that may refer to other files. Do you want to update this document with the data from the linked files?

The remote data is not accessible. Do you want to start the application c:\windows\system32\cmd.exe?

Edit: Several researchers have demonstrated not eliminating the popup, but rather changing the text to seem less suspicious:

The authors provide step-by-step instructions for reproducing this exploit. In about sixty seconds I was able to create a Microsoft Word (2016) document, use CTRL-F9 to insert a custom field, and put the following command into the field:
{ DDEAUTO c:\\windows\\system32\\cmd.exe "/c calc.exe" }
After saving the file, merely opening the file triggers the above two pop-up notices, then launches the Microsoft Calculator app. Of course, Calculator is not malicious - it merely demonstrates the exploit. I could put anything else I wanted in the command instead.

But I'm a defender. I'm not one to stop at popping calc. I want to detect it too. 

Microsoft Office with its default settings keeps a record of popup messages in the Windows Event Log. In Windows Event Viewer, in the Applications and Services Logs folder, in the Microsoft Office Alerts channel, there is now an event 300. The message body contains the text "Do you want to start the application c:\windows\system32\cmd.exe" - a dead giveaway that an Office application launched something. 

Microsoft Office writes a Windows event for every popup message

While there are legitimate reasons for Office apps to launch other programs (custom-built business apps, for example), those can generally be cataloged; anything outside that catalog of legitimate Office-based applications is suspicious.

But back to my earlier point: the authors said it is possible to adjust command syntax to eliminate this popup alert. No popup means no alert to record in the Microsoft Office Alerts channel.

Ahh, but a program still started. As Austin "malware archeologist" Michael Gough is fond of saying, malware can hide - but it must run. His website has a set of fantastic "cheat sheets" that belong in every Windows administrator's back pocket.

Windows has optional features to keep a detailed log of every program or process that ever starts - but only if you take the time to set up process auditing. Microsoft published a guide to enabling process auditing using Group Policy Objects, a handy feature of Active Directory environments that makes it easy (well, easier) to apply configurations to an entire enterprise at one time.

But not every small business or home office uses Active Directory. In fact, the system that I tested this scenario on runs Windows 10 Home, which doesn't even have the graphical policy editor for managing policy settings. But it still has the underlying features.

To enable detailed tracking of process creation, including the complete command line with parameters, on any Windows system not managed by an Active Directory domain, run the following commands in a Windows command prompt running with administrator rights:

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit /f /t REG_SZ /v ProcessCreationIncludeCmdLine_Enabled=1

auditpol /set /Category:"Detailed Tracking" /subcategory:"Process Creation" /success:enable /failure:enable

The first command inserts a registry value that tell Windows to track the complete command line including any parameters; the second command enables process creation tracking. With these two commands run, Windows will now add an event 4688 to the Security log every time a new process or program starts. Yes, it's a bit noisy, but it's not something you have to look at every day. And when you do need it, it's a life saver.

With process auditing turned on, opening the demonstration Word document above creates the following event in the Security channel:

With process auditing enabled, each process creation adds a Windows event, even if there is no popup.

Again, "Creator Process Name: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE" is a dead giveaway that Microsoft Word launched some external program, an event that should be a red flag for your investigators.

One final note: after I published this article, fellow Austin security pro Brian Boettcher mentioned a very simple trick to stop this exploit dead in its tracks: disabling the "update automatic links at open" option in Word.

Do you have something to add? A question you'd like answered? Think I'm out of my mind? Join the conversation below, reach out by email at david (at) securityforrealpeople.com, or hit me up on Twitter at @dnlongen

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.

Whois David?

My photo

I have spent the better part of two decades in information technology and security, with roots in application developer support, system administration, and network security. My specialty is cyber threat intelligence - software vulnerabilities and patching, malware, social networking risks, etc. In particular, I strive to write about complex cyber topics in a way that can be understood by those outside the infosec industry.

Why do I do this? A common comment I get from friends and family is that complex security topics give them headaches. They want to know in simple terms how to stay safe in a connected world. Folks like me and my peers have chosen to make a profession out of hacking and defending. I've been doing this for the better part of two decades, and so have a high degree of knowledge in the field. Others have chosen different paths - paths where I would be lost. This is my effort to share my knowledge with those that are experts in something else.

When not in front of a digital screen, I spend my time raising five rambunctious teens and pre-teens - including two sets of twins. Our family enjoys archery, raising show and meat rabbits, and simply enjoying life in the Texas hill country.

For a decade I served as either Commander or a division leader for the Awana Club in Dripping Springs, Texas; while I have retired from that role I continue to have a passion for children's ministry. At the moment I teach 1st through 3rd grade Sunday School. Follow FBC Dripping Springs Kids to see what is going on in our children's ministries.