CVE-2017-9387 in VeraEdge
Summary
by MITRE
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a shell script called relay.sh which is used for creating new SSH relays for the device so that the device connects to Vera servers. All the parameters passed in this specific script are logged to a log file called log.relay in the /tmp folder. The user can also read all the log files from the device using a script called log.sh. However, when the script loads the log files it displays them with content-type text/html and passes all the logs through the ansi2html binary which converts all the character text including HTML meta-characters correctly to be displayed in the browser. This allows an attacker to use the log files as a storing mechanism for the XSS payload and thus whenever a user navigates to that log.sh script, it enables the XSS payload and allows an attacker to execute his malicious payload on the user's browser.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 06/24/2020
The vulnerability identified in CVE-2017-9387 affects VeraEdge 1.7.19 and Veralite 1.7.481 devices, representing a critical security flaw in the device's logging and display mechanisms. This issue stems from improper handling of user-supplied parameters within the relay.sh shell script, which creates SSH relays for device communication with Vera servers. The device's architecture inadvertently stores all input parameters in a log file named log.relay located in the /tmp directory, creating a persistent storage mechanism for attacker-controlled data. The vulnerability manifests through the log.sh script which provides read access to these log files, enabling unauthorized users to retrieve and display the stored information. This design flaw creates a pathway for cross-site scripting attacks by leveraging the device's own logging infrastructure as a payload delivery mechanism.
The technical exploitation of this vulnerability involves the manipulation of input parameters passed to the relay.sh script, which are then logged without proper sanitization. When these parameters contain malicious content such as javascript payloads or html meta-characters, they are stored in the log.relay file and subsequently displayed through the log.sh interface. The log.sh script processes these log files by setting content-type text/html and passing the content through the ansi2html binary for browser display formatting. This processing step fails to properly sanitize or escape the stored content, allowing malicious payloads embedded in the log files to execute within the victim's browser context. The vulnerability operates at the intersection of improper input validation and insecure output handling, creating an environment where attacker-controlled data can be interpreted as executable code by web browsers.
The operational impact of CVE-2017-9387 extends beyond simple cross-site scripting, as it provides attackers with persistent command and control capabilities within the device's administrative interface. An attacker who can inject malicious content into the logging system can execute arbitrary javascript code in the context of authenticated users who view the log files, potentially leading to session hijacking, credential theft, or further device compromise. The vulnerability's persistence is enhanced by the fact that log files remain accessible and readable through the log.sh interface, allowing attackers to maintain their payload across multiple sessions. This weakness fundamentally undermines the device's security model and creates opportunities for attackers to establish long-term presence within the network environment. The attack vector is particularly concerning because it leverages legitimate device functionality rather than exploiting unknown vulnerabilities, making detection more difficult.
Mitigation strategies for CVE-2017-9387 should focus on implementing proper input sanitization and output encoding mechanisms within the device's logging and display systems. The primary remediation involves ensuring that all user-supplied parameters are properly validated and sanitized before being written to log files, preventing malicious content from being stored in the first place. Additionally, the log.sh script should implement proper content sanitization when displaying log files, regardless of the content-type header or processing binary used. Security controls should include input filtering to remove or escape potentially dangerous characters, output encoding to prevent interpretation of stored data as executable code, and access controls to limit log file reading capabilities to authorized personnel only. This vulnerability aligns with CWE-79 (Cross-site Scripting) and CWE-20 (Improper Input Validation) categories, and represents a technique consistent with ATT&CK tactics including T1059.007 (Scripting) and T1566.001 (Phishing via Social Media) where attackers leverage legitimate system features for malicious purposes.