Advisory: Multiple Vulnerabilities in Quest Policy Authority for Unified Communications
Unified Communications (UC) solutions are often deployed in enterprise environments and allow users to integrate communication between various mediums such as text and instant messaging, video conferencing, e-mail and voicemail, file sharing, and much more. With the recent COVID-19 pandemic, teleworking is becoming more and more common in the workplace and a large number of businesses have integrated Unified Communications solutions into their workflow (Microsoft Teams, for example). This can drastically optimize business processes as well as increase productivity amongst employees.
When an attacker gains access to a UC management solution it can be a very bad day for the organization. The internal communication channels of an organization are almost guaranteed to carry proprietary information/trade secrets, sensitive configuration information, PII, and much more. The ability to monitor these internal communication channels leads the attacker one step closer to a large scale data loss for the vulnerable organization.
A few weeks ago I had the chance to test an instance of Quest Policy Authority for Unified Communications (version 8.1.2.200). According to Quest, the most recent version was released in 2010 and the product has been unsupported for the past seven years. Strangely enough, there were still many undiscovered (or undisclosed) vulnerabilities within the application. After reporting the vulnerabilities to the vendor, I was given the go ahead to publicly disclose as the product is at its end-of-life and therefore a patch will not be pushed.
Although I did discover a large number of vulnerabilities in the product, I will say that the test was limited in time and scope, therefore only two main components were assessed - the Web Compliance Manager and the Web Reporter. With more time and access, I am confident I would have been able to discover many other vulnerabilities within the underlying application.
With all things considered, I suggest anyone still using the product to mitigate risk by either upgrading to a new product that is under support from Quest or to find an alternative immediately.
CVE-2020-35203
The first vulnerability I discovered was a reflected cross-site scripting (XSS) vulnerability in the web compliance manager component. This was a pretty simple issue caused by text being reflected onto the page from the msg parameter in the initFile.jsp file.
CVE-2020-35204
Another reflected XSS vulnerability, this time in the main application via the FolderControl.jsp file via the unqID parameter.
This one had some strange behavior where the payload would persist throughout the browser session and would stack as more requests were made.
Above you can see no payload was placed in the parameter but the previous XSS is still firing?
What is even more strange is the fact that after the XSS fired, any request to the /PolicyAuthority/ directory would be met with a 500 Internal Error with a stack trace for a java.lang.NumberFormatException for the initial payload that was sent. If anyone is familiar with what is going on in the background here, please contact me! I’d be super curious to hear.
CVE-2020-35205
Going back to the initFile.jsp endpoint from earlier, I discovered a SSRF vulnerability that allowed enumeration of internal systems. By allowing unauthenticated connections to arbitrary systems/ports, an attacker could use this vulnerability as a make-shift port scanner to identify open ports on the target system or other systems within its internal network.
Additionally, an attacker can initiate connections to external systems. This is interesting because if the admin panel has not yet been configured on the target system, the attacker can configure the admin panel using their own database connection and essentially take over the application to use for their own purposes.
As shown above and below, using the “Save Configuration File” button, an attacker can take over the Web Compliance Manager panel of a target that has not been initially configured yet as long as they can reach a database with a successful connection.
After making a successful connection and saving the configuration file, I was able to add my own admin user and takeover the administrative control panel. With a more conspicuous username, an unsuspecting administrator who subsequently logs in to setup the database configuration may think that the secondary user is a default account that is deployed with the baseline software. As such, they would be unknowingly providing the attacker with access to monitor data related to internal communications channels.
CVE-2020-35206
Another file in the web compliance manager component, cConn.jsp, is vulnerable to reflected XSS attacks via the ur parameter. This parameter would normally be used to show the IP of the database server the user is attempting to connect to, but an attacker can inject HTML/JavaScript here to be reflected onto the page.
CVE-2020-35719
The index.jsp file in the search function of the Web Compliance Manager component is also vulnerable to reflected XSS attacks (post-auth) via the added parameter.
CVE-2020-35720
A post-auth stored XSS vulnerability exists in the submitUser.jsp file of the Web Compliance Manager component. When adding or modifying users, a XSS payload can be stored in the First Name, Last Name, or Logon Name fields. While this requires an administrator account with Manage Users privileges, this could allow privilege escalation (from only Manage Users -> Full privileges).
CVE-2020-35721
The BrowseAssets.do file of the Web Reporter component is vulnerable to a post-auth reflected XSS attack via the title parameter.
CVE-2020-35722
This one was my favorite and one of the most critical I discovered out of the bunch. By crafting a malicious link to the submitUser.jsp endpoint, an attacker can cause an administrative user to carry out various actions to include adding a new administrative user or changing the password of the current administrator!
The above photo is what a normal request should look like when adding or updating a user profile in the user management panel. As you can tell, this is normally sent as a POST request.
Conveniently for attackers, a GET request can be used to carry out the same function. This means a malicious link can be crafted to add or modify users on behalf of the attacker!
CVE-2020-35723
If specific conditions are met, the ReportPreview.do file of the Web Reporter component is vulnerable to post-auth Reflected XSS attacks via the referer parameter. For the XSS payload to fire, the victim must first click on manage favorites in the Web Reporter component and open any of their favorites for editing. As such, this vulnerability would require multiple user actions and is relatively low-threat.
CVE-2020-35724
The error.jsp file within the Web Compliance Manager component is vulnerable to post-auth reflected XSS attacks via the err parameter. Additionally, various parameters of the index.jsp file (such as cpr, tcp, and abs) will also redirect to the error.jsp file and cause the XSS payload to fire.
CVE-2020-35725
Another reflected XSS vulnerability was found in the index.jsp file of the Web Compliance Manager component via the msg parameter.
CVE-2020-35726
A reflected XSS vulnerability was also found in the index.jsp file of the Reports feature of the Web Compliance Manager component via the by parameter.
CVE-2020-35727
The last vulnerability I found was in the BrowseDirs.do file of the Web Reporter component. This file is vulnerable to post-auth reflected XSS via the by parameter.
Disclosure Timeline
December 9, 2020 - Reported CVE-2020-35203, 35204, 35205, and 35206 to the vendor
December 10, 2020 - Vendor replied requesting more information; provided requested info the same day.
December 11, 2020 - Reported 5 additional vulnerabilities
December 13, 2020 - Notified the vendor of additional vulnerabilities
December 16, 2020 - Received e-mail from the vendor stating the product is EOL and will not be patched
Thanks for reading! Check back for more posts in the future!
