Windows Dynamic Data Exchange Protocol: Abuse for Fun and Profit

During a recent Application Security Assessment, I came across an interesting insecurity that oftentimes analyst may overlook. The application had a certain export capability that allowed a legitimate analyst to select whatever fields may be of interest and export them to a csv file to open locally in Microsoft Office. Exporting data to CSV seems like a standard feature that most report portals should have, right? Well, what happens when the portal or application allows a user to input whatever values he wants in the document, without any sanitization? They are able to inject formulas into cells to execute code of our choosing. More interesting - DDE allows us to run commands on the local filesystem!

Windows provides several methods for transferring data between applications. One method is to use the Dynamic Data Exchange (DDE) protocol. The DDE protocol is a set of messages and guidelines. It sends messages between applications that share data and uses shared memory to exchange data between applications. Applications can use the DDE protocol for one-time data transfers and for continuous exchanges in which applications send updates to one another as new data becomes available.

Spreadsheet software allows you to create formulas in cells by prepending the ‘=’ character as a value in the cell followed by the appropriate code. Various security issues arise when untrusted data is processed by an unsuspecting reader.

The following symbols can be used to trigger formula interpretation in Microsoft Excel:

  • Equals  to ("=")

  • Plus ("+")

  • Minus ("-")

  • At ("@")

So, if an attacker has control over the values being written into the spreadsheet he can execute commands locally on the file system with something along the lines of:

=cmd|' /C calc'!A0

This will open the calculator on the victim PC:

image1.png

Once a hacker knows they have code execution on the victims P.C, they can take this a step further to system compromise.  For example, they could implant malicious data inside the legitimate application and when an unsuspecting analyst downloads the document for review the payload will be executed. For those familiar with penetration testing engagements, this means that we can call back to a control and command center such as meterpreter or empire.

Even though this payload requires a certain level of user interaction, the viewer must click enable, in my experience most unsuspecting users go ahead and enable it as it is indeed a trusted source:

image3.png


An additional security warning is thrown as well but often times is overlooked by the viewer:

image2.png

That being said, even though this attack payload is noisy and wouldn’t necessarily be used in a more sophisticated attack, it is definitely effective to show a client when performing an application security assessment. The impact of this attack could be severe as we can write malicious VBS or call powershell directly to further the impact. Also to note, VirusTotal and AV engines do not detect the office document as malicious.

image4.png

MITIGATION:

A viable fix for this on the server side would be to sanitize or escape characters that Excel recognizes as formulas. The characters “=”, “+”, and “-“,  should be prepended with an apostrophe. A simple rule of thumb is do not blindly trust user defined input. Also, you can edit your registry to disable DDE on the local system.

\HKEY_CURRENT_USER\Software\Microsoft\Office<version>\Word\SecurityAllowDD(DWORD)

 

- Humberto Cabrera, Sr. Security Consultant, Prescient Security

 

REFRENCES:

https://www.contextis.com/blog/comma-separated-vulnerabilities

https://pentestlab.blog/2018/01/16/microsoft-office-dde-attacks/