Is Dynamic Data Exchange (DDE) Injection a Thing?

This month our old friend Dynamic Data Exchange (DDE) within Microsoft’s office suite has been popular topic. Many will be familiar with it if they have played with CSV Injection before. With that, you can use DDE within a formula to get code execution within Excel.

The trigger for the buzz has been this post by Sensepost:

• https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/

What Sensepost have pointed out is that field codes within Word can do the same thing as formulas within Excel. This means that attackers can embed OS commands into Word document files without the use of office macros.

Any sane email filter will straight up block Macro Enabled documents (particularly .dotm and .docm extensions). Since this gets around that (and can use .docx), it is causing a stir within blue and red teams.

This article is going to give you an overview of DDE within Word. Compare and contrast it with CSV Injection and then end on the meat of this article. What nobody is talking about is potential server side application vulnerabilities. While I personally think this is going to be a niche issue, it makes sense to provide my speculation on the matter.

Risks of DDE within Word

The following list gives an overview of the current risks posed by DDE within Word as are generally being discussed:

• An attacker can generate a Word document which has a poisoned field code inside of it. When this is opened a victim will need to click "Yes" on multiple warnings before code executes. Microsoft has had these warnings in place for several years. Generally, this should be sufficient to protect most users from exploitation. However, it comes down to that old favourite “trust”. If the victim trusts the source then they are at risk of accepting all the warnings.
• An attacker would need to get the file to their victims. This would mean placing it on a network share, uploading it to a website, or emailing it to them.
• If you think about that for two seconds, there is a real risk for anyone who operates a business reliant on Word documents being sent to them. As an opening that is: Lawyers, Estate Agents, and anyone handling CVs regularly.
• Given this, it can be used by external or internal attackers to gain privileges.

Sound familiar? These are all identical to the risks posed by CSV Injection if you swap out Word for Excel.

Comparison with CSV Injection

CSV Injection has been seen as a server side application vulnerability for years. To exploit it, an attacker finds an application which generates CSV files. They then try to find an input parameter they can control which forms part of that export function. If the application accepts input prefixed with either an "@" or an "=", then it is possible to inject DDE. When the victim opens the ".csv" file in Excel, the formula is interpreted and you have code execution.

The team who discovered CSV Injection were looking for risks while no doubt engaged in testing a web application. It seems that nobody necessarily joined the dots to make that a Phishing payload for macroless Excel exploitation. Or that could be my naivety having spent my life hacking apps.

DDE within Word using field codes on the other hand has been developed specifically as a phishing payload. This means that we currently have a macroless Word exploitation technique. Conversely it seems that nobody has thought of this as potentially a server side application risk which is where this article is going to go into full on speculation mode in a minute.

There is a key difference between DDE via CSV and DDE within field codes. CSV is NOT an office suite document format. It is a plaintext representation of data which is seperated by delimiters. You can open a CSV file in notepad and make sense of it. It is just that Excel is generally the default viewer for Windows users and far prettier. DDE within field codes is exploiting ".doc" and ".docx" file formats which are Microsoft standards.

This is important if trying to generate detection rules as your CSV injection rules can fairly reliably detect the issue using regular expressions. While DDE within Word formats is going to need a bit of familiarity with the formats which is not insurmountable. I can already see people developing rules, so it's not that big of an issue really.

To summarise: in my eyes CSV Injection and DDE in Word are the same thing. The entire office suite appears to support DDE and that is where the problem lies. It is a feature to allow interprocess communication. It should probably just limit what can be run to other parts of the office suite and be done with it. But Microsoft have long avoided doing this as no doubt there are big solutions somewhere I am unaware of that definitely rely on this.

DDE in Web Applications Generating Documents

As stated above the entire schtick for CSV Injection is that it has been seen as a server side vulnerability. It is true that this can be fixed at the server side. However, the execution and impact is client side. This distinction has been particularly fun for me to explain on bug bounties and to customers with it being a sticking point on several occassions. We should all know the risks posed by applications generating things that open by default in Excel.

What about our new toy (DDEAUTO in Word)? Applications exist which generate Word documents programmatically. Heck pretty much every penetration testing team operates a form of Word automation. Other industries will equally need to do the same undoubtedly.

I have spent the best part of a decade automating Word document generation. There are libraries for .Net, Java, and Python at least which can do so and I have played with most of them. I have never found a case where I needed to allow a user to insert an arbitrary field code. Just because I have not done that does this mean that nobody ever has?

Enter my wild speculation that someone somewhere will have done this. Now I have a problem as basically Word generation applications are generally either "in house" or very expensive and subject to licensing. How can I do the legwork when many of the targets will be hidden away in some form? The next section gives you the tools to look for "DDE Injection" within server side applications.

Looking for DDE Vulnerabilities Server Side

If you maintain an application which programatically creates Word documents, then you can grep your code to look for potential vulnerabilities. My example is going to be in .Net applications. Open up your project and look for anything which calls the ActiveDocument.Fields.Add function.

That function is how you programatically add a field code into a document. To show how it can be called, I have provided an example macro. While there will be subtle differences in the calling chain within a server side application, it serves as a solid example.

If you find no occurrences of this function, then congratulations you do not need to do anything more! If you do find some, you will need to investigate further.

The second paramater is "Type" which specifies the type of field you are adding into the document. The enumeration which contains the types is specified here.

If your application is supporting fields of the following types (or an attacker can specify the type themselves) then your application may be at risk:

• wdFieldDDEAuto - code will execute automatically when a document is opened; or
• wdFieldDDE - code will execute in certain circumstances. I would guess if a table of contents is updated, if a document is print previewed or printed and maybe others.

In a nutshell: my recommendation would be to trace the source of the data used within the ActiveDocument.Fields.Add call to look for inputs that a user can influence.

Macro that Injects DDEAUTO Payload into a Document

The following includes a Macro which can programatically add a DDEAUTO field code into a document:

To use this follow the steps below:

• Open a word document.
• Press ALT + F11 to launch the macro editor.
• Click on "ThisDocument" for your document.
• Copy and paste the above code and then press the run button.

Running this will inject a field with the PoC directly into your document at the location of your cursor. They payload simply launches "calc.exe" and does nothing malicious.

In Summary

Dynamic Data Exchange (DDE) is back on the agenda and is proving useful as a macroless malware attack vector within Office documents. There is a lot of ongoing research which is widening the delivery of this to Outlook calendar invites, and other parts of the office suite. There are also several techniques which can obfuscate payloads and hide them within the warning messages.

CSV Injection has enabled similar attacks against Excel for several years. What I am speculating on is whether there are any server side applications which are vulnerable to DDE Injection into Word documents. This post has included a process for code reviewing applications written in .Net to confirm if applications are vulnerable, and includes a Macro that can be used to demonstrate using the "ActiveDocument.Fields.Add" function.

If you have a server side application which generates Word documents based on user input. Then I suggest you take a proactive step using these techniques.