Update #1 (1/29/2018): Hours after the release of this post, Matt Nelson unleashed a new technique to bypass the latest mitigation options made available by Microsoft. As a result, attackers can embed an Excel spreadsheet within OneNote in order to completely bypass the corresponding registry key intended to block DDE functionality. Furthermore, OneNote documents downloaded from external sources (e.g., the public Internet) are (still) not sandboxed by Protected View. I’ve added another item to the roadmap for my Office DDE payload generation tool, as I intend to automate this technique as well.
Microsoft pushed an update that disables DDE functionality within Word by default. However, this default setting can be nullified by setting a single registry key value. All other Office applications remain (relatively) vulnerable to DDE abuse attacks, but protection can be opted into by setting specific registry keys for each product.
The Dynamic Data Exchange (DDE) protocol exposes functionality that allows data to be transmitted and shared between applications/processes on Windows platforms. Back in 2014, James Kettle and Rohan Durve released a blog post describing the formula injection technique affecting Microsoft Excel, which can be abused in order to achieve arbitrary command execution by way of the DDE protocol. About two years later, Jerome Smith delivered a presentation at CamSec detailing a technique that abused DDE in Excel to achieve arbitrary command and code execution. This served as a catalyst for subsequent offensive research led by many, including Saif Sherei, Etienne Stalmans, Kevin Beaumont, Ryan Hanson, and Mike Czumak. As a result, similar techniques abusing the DDE protocol were crafted for other applications within the Microsoft Office product line, specifically, Word and Outlook. Shortly after this research was publicized, malware samples and phishing documents surfaced “in the wild” that leveraged these techniques. The following posts cover these DDE attacks:
In the midst of all this, several tools were created to leverage this offensive technique and released for public use. Panagiotis Gkatziroulis covered the usage and functionality of such tools in their post on Medium, which includes my DDE payload generation tool available on GitHub.
Starting in November of 2017, Microsoft began issuing several Windows updates and advisories to combat these attacks. Microsoft Security Advisory 4053440 provides explicit detail regarding the changes that Microsoft made to DDE functionality and behavior in the context of Office applications. Originally, Microsoft provided some “defense-in-depth” options for Windows users, allowing for more granular control over allowed DDE functionality within Office applications. Microsoft then issued an update that changed default DDE behavior.
As of this writing, these updates simply disabled DDE functionality within all versions of Microsoft Word by default. This leaves the DDE protocol enabled by default for the remaining Office applications that have been identified as vulnerable, notably Excel and Outlook. Additionally, Microsoft offered users the ability to override this default setting in Word by way of the Windows registry in order to support legacy applications that rely on the DDE protocol. Although this update puts a damper on Word DDE attacks “out of the box”, both attackers and administrators can utilize the special registry key noted below to side-step the patch:
1 \HKEY_CURRENT_USER\Software\Microsoft\Office<version>\Word\Security AllowDDE(DWORD)
Microsoft Security Advisory ADV170021 outlines the three values to which this registry key can be set. Needless to say, potential attackers could either forcefully set the value to “2” or hope the environment’s administrators have already done so.
- 0: To disable DDE. This is the default setting after you install the update.
- 1: To allow DDE requests to an already running program, but prevent DDE requests that require another executable program to be launched.
- 2: To fully allow DDE requests.
The Word DDE attack has traditionally been leveraged during targeted phishing campaigns, so the likelihood of an attacker creating or otherwise modifying this registry key after having already gained a foothold on the target machine is relatively low. However, as previously mentioned, there is the possibility that an administrator creates the registry key and sets its value to “2” in order to support legacy applications or services.
Although this appears problematic, these advisories present a way to apply granular control over DDE functionality across all affected Office applications. These options can be enabled and disabled by way of specific registry keys, also detailed in Microsoft Security Advisory ADV170021 and this gist posted by Will Dormann.
After all is said and done, Microsoft Word is still vulnerable to DDE attacks if the appropriate registry key is set. All other Office applications are vulnerable by default, as the latest Microsoft update only addressed the default behavior of DDE in Word. Please note that your mileage may vary with Outlook DDE attacks because some email providers automatically convert messages to HTML formatting before delivery to the recipient. This will strip any DDE elements out of the original rich text formatted (RTF) message.
As a byproduct of this post, I have updated my Office DDE payload generation tool to include simple Excel DDE payload generation. The tool roadmap includes adding another script to generate Outlook DDE payloads and research potential obfuscation and evasion techniques for both Excel and Outlook DDE payloads.
As always, feel free to reach out via Twitter with any questions/comments.