Duck-Assisted Code Execution in EMC Data Protection Advisor

September 26, 2017 | Vincent Lee

Today, we published yet another 0-day advisory, this time for a bug in the EMC Data Protection Advisor. This vulnerability was discovered by Andrea Micalizzi (rgod), and, when used in conjunction with two other bugs (ZDI-17-811/CVE-2017-8013 and ZDI-17-710/CVE-2017-8002) can achieve unauthenticated code execution as SYSTEM. Unfortunately, the vendor chose not to patch this bug since it needs a helping hand to get that code execution. Fortunately (for attackers), other bugs in the product combined with an ill-tempered water fowl provide all the help needed.


Let's begin by breaking down the technical details of this unpatched bug. Here's a quick video showing the how the exploit chain can be used:

ZDI-17-812 - EMC Data Protection Advisor ScheduledReportResource Command Injection Remote Code Execution Vulnerability

Upon installation of EMC Data Protection Advisor, the "EMC DPA Application" service will be listening on TCP port 9002 by default. The vulnerability resides in the following endpoint:


This endpoint allows a user to schedule reports by submitting some XML data. The following is an example XML:

<scheduledReport version="1">
  <description>Example Schedule</description>
   <nodeLink type="Group">
     <child type="Group">
       <child type="Group">

The Vulnerability

The vulnerability resides in the lack of proper validation on the <preScript> tag. The bug makes it possible to specify arbitrary executables and even remote storage locations. An attacker could point the preScript to a malicious network share and exploit this flaw without first uploading any malicious script.

This feature is processed by the com.emc.dpa.restapi.schedreport.ScheduledReportResource class.

In the decompiled code above, we can see that attacker controlled XML is passed into the convertToEntity() function. Let's take a closer look at what this function does:

Eventually, the scheduled report will be processed and the preScript value will be executed in a separate process by the com.emc.apollo.command.util.ExecCommandsBean located in commands.jar.


Although the vulnerability is quite straight forward, exploitation is not as trivial. First, the endpoint is only reachable by authenticated users. (Un)Fortunately, every installation comes with multiple free backdoor accounts; DPA Metrics User, Agent Registration User, and Donald Duck. Most importantly, Donald Duck has Administrator privileges! (Who knew Donald had administrative talents?) This issue was patched in ZDI-17-811 (CVE-2017-8013).

Default user entries of the DPA PostgreSQL database displayed in pgAdmin4

Even with the help from Donald Duck, the attacker still needs to provide valid controlPanelID, windowID, and userID to properly schedule a report. Luckily, rgod also discovered ZDI-17-710 (CVE-2017-8002), a blind SQL injection vulnerability that will allow the attacker to obtain these IDs. Combining these three vulnerabilities, rgod beautifully crafted a multi-staged PoC to achieve code execution as SYSTEM.


This selection of bugs discovered by rgod has demonstrated how attackers can combine multiple non-RCE vulnerabilities in a target to eventually achieve total system compromise. Sadly, the vendor decided not to fix this submission because they view it as by design, not a vulnerability and provided the following statement:

"[This issue is] an initial design flaw of the product and not a vulnerability. If further details are provided then the product team will investigate further into this issue."

Given that the vendor has killed 2 out of the 3 bugs in the chain, it is understandable that EMC has made such decision. However, there are definitely many precautionary steps that EMC can take to harden their software instead of just calling it a "feature". Other bugs certainly may exist that can take advantage of this flaw. It would have been ideal for the vendor to shut it down completely. Hopefully a few more bugs in this area can convince them to do so.

Disclosure Timeline

04/12/2017 - ZDI disclosed the report to the vendor
04/14/2017 - The vendor acknowledged the report as PSRC-4399
05/09/2017 - The vendor responded that "an intial design flaw of the product and not a vulnerability. If further details are provided then the product team will investigate further into this issue."
06/27/2017 - ZDI met with the vendor by phone to discuss (multiple cases). We left thinking the vendor wanted more time to revisit the report
08/25/2017 - The vendor again advised ZDI that: The product team did not see this as an issue as the product is functioning by design
09/15/2017 - ZDI advised the vendor that this report will 0-day on 9/26
09/25/2017 - The vendor replied to ZDI and reiterated the position that this is "by design"