CVE-2020-36917: iDS6 DSSPro Information Disclosure Flaw

CVE-2020-36917 Overview

CVE-2020-36917 affects iDS6 DSSPro Digital Signage System 6.2, a content management product previously distributed by Yerootech. The vulnerability stems from cleartext transmission of authentication credentials over HTTP. When the autoSave feature is enabled, the application stores and transmits user passwords inside cookies without encryption. An adjacent network attacker can intercept these cookies through a man-in-the-middle position and recover valid user credentials. The flaw is classified under CWE-319: Cleartext Transmission of Sensitive Information.

Critical Impact
Adjacent network attackers can capture administrative passwords in plaintext from HTTP traffic, leading to full account takeover of the digital signage management interface.

Affected Products

iDS6 DSSPro Digital Signage System version 6.2
Yerootech DSSPro management web interface
Deployments using the autoSave credential feature over HTTP

Discovery Timeline

2026-01-06 - CVE-2020-36917 published to the National Vulnerability Database
2026-04-15 - Last updated in the NVD database

Technical Details for CVE-2020-36917

Vulnerability Analysis

The iDS6 DSSPro web application exposes a login workflow that persists credentials in a browser cookie when the autoSave option is selected. The application transmits the cookie value over unencrypted HTTP, exposing the password to anyone with visibility into the network path. Because the credential is stored client-side and resent on each request, repeated capture opportunities exist for the duration of the session.

The defect violates fundamental transport security principles. Authentication material must travel over Transport Layer Security (TLS) channels and must not be cached in retrievable cookie form. CVE-2020-36917 demonstrates both failures simultaneously, producing a high-impact confidentiality issue.

Root Cause

The root cause is improper handling of authentication data by the DSSPro front-end. The autoSave feature serializes the username and password into a cookie and reuses it for subsequent sessions. The application does not enforce HTTPS, does not set the Secure or HttpOnly cookie attributes, and does not hash or encrypt the stored credential.

Attack Vector

Exploitation requires adjacent network access, such as a shared Wi-Fi segment, a switched LAN with ARP spoofing capability, or an upstream router under attacker control. The attacker passively captures HTTP traffic between the operator browser and the DSSPro server. The cleartext cookie reveals the password, which the attacker reuses to authenticate to the management console.

For additional technical context, see the VulnCheck Advisory on DSSPRO Vulnerability and the Zero Science Vulnerability ZSL-2020-5605 publication. A proof-of-concept write-up is also archived in the Packet Storm Security File 159915 and CXSecurity Issue WLB-2020110023.

Detection Methods for CVE-2020-36917

Indicators of Compromise

HTTP requests to the DSSPro management interface containing cookie headers with credential fields in cleartext.
Unexpected logins to the DSSPro console from hosts that share the operator network segment.
ARP table anomalies or duplicate MAC bindings on networks where DSSPro is administered.

Detection Strategies

Inspect proxy and web gateway logs for HTTP traffic destined to DSSPro hosts and flag any sessions carrying credential-bearing cookies.
Deploy network intrusion detection signatures that alert on cookie names associated with the DSSPro autoSave feature traversing port 80.
Correlate authentication events on the DSSPro server with the source network segment to identify logins from non-operator subnets.

Monitoring Recommendations

Continuously monitor for plaintext HTTP usage on management VLANs and alert when administrative URLs appear unencrypted.
Track failed and successful logins to the DSSPro console and baseline expected administrator source addresses.
Watch for layer-2 attack indicators such as ARP spoofing or rogue DHCP responses on segments serving signage operators.

How to Mitigate CVE-2020-36917

Immediate Actions Required

Disable the autoSave credential option in all DSSPro client sessions and clear browser cookies that may contain stored passwords.
Rotate all DSSPro user passwords, prioritizing administrator accounts that authenticated over untrusted networks.
Restrict access to the DSSPro management interface to a dedicated, encrypted administrative network or VPN.

Patch Information

No vendor patch has been published in the references available for CVE-2020-36917. The product source, Yerootech, is reachable only through an archived security page. Operators should treat the platform as unmaintained for this issue and apply compensating controls. Additional references are tracked in IBM X-Force Vulnerability 191261.

Workarounds

Front the DSSPro web interface with a TLS-terminating reverse proxy that enforces HTTPS and rewrites cookies with Secure and HttpOnly flags.
Place the DSSPro server on an isolated VLAN reachable only through bastion hosts or jump servers.
Enforce strong password rotation and unique credentials per administrator, since cookie capture exposes the stored value directly.
Replace the platform with a supported signage management solution if long-term maintenance is required.

bash

# Example NGINX reverse proxy configuration enforcing TLS for DSSPro
server {
    listen 443 ssl;
    server_name dsspro.internal.example.com;

    ssl_certificate     /etc/ssl/certs/dsspro.crt;
    ssl_certificate_key /etc/ssl/private/dsspro.key;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://10.0.0.25:80;
        proxy_cookie_flags ~ Secure HttpOnly;
        proxy_set_header X-Forwarded-Proto https;
    }
}

server {
    listen 80;
    server_name dsspro.internal.example.com;
    return 301 https://$host$request_uri;
}