This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Kace Systems Management Appliance
A reflected XSS vulnerability exists in Quest KACE Systems Management Appliance Server Center 9.1.317 affecting the userui/software_library.php component via the PATH_INFO. (2019-11-06, CVE-2019-12917)
Quest KACE Systems Management Appliance Server Center 9.1.317 has an XSS vulnerability (via an SVG image and HTML file) that allows an authenticated user to execute arbitrary JavaScript in an administrator's browser. (2019-11-06, CVE-2019-13080)
Quest KACE Systems Management Appliance Server Center 9.1.317 has an XSS vulnerability (via the sam_detail_titled.php SAM_TYPE parameter) that allows an attacker to create a malicious link in order to attack authenticated users. (2019-11-06, CVE-2019-13077)
Quest KACE Systems Management Appliance Server Center 9.1.317 has an XSS vulnerability (via the title field in the /common/ticket_associated_tickets.php service desk ticket functionality) that allows an authenticated user to execute arbitrary JavaScript in a service desk user's browser. (2019-11-06, CVE-2019-13081)
An issue was discovered in Quest KACE Systems Management Appliance before 9.1. The script at /service/kbot_service_notsoap.php is vulnerable to unauthenticated reflected XSS when user-supplied input to the METHOD GET parameter is processed by the web application. Since the application does not properly validate and sanitize this parameter, it is possible to place arbitrary script code into the context of the same page. (2019-05-24, CVE-2019-11604)
Why Cross-site Scripting can be dangerous
Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.
The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:
https://server.com/confirmation?message=Transaction+Complete
what results in:
<span>Confirmation: Transaction Complete</span>
In that case the message can be modified to become a valid Javascript code, e.g.:
https://server.com/confirmation?message=<script>dangerous javascript code here</script>
and it will be executed locally by the user's browser with full access to the user's personal application/browser data:
<span>Confirmation: <script>dangerous javascript code here</script></span>