Skyhigh Security Secure Web Gateway: Information Disclosure Due to Same Origin Policy Bypass on Block Page

When HTTP traffic is blocked by the Secure Web Gateway, a block page containing relevant information is returned by the Secure Web Gateway in place of the actual server response. Consequently, the browser assumes that the block page is the actual server response such that the Same Origin Policy cannot be applied correctly. For example, if a third-party website performs a request to its own origin which is blocked, the Same Origin Policy will not restrict access to the block page such that the potentially sensitive information contained in the block page can be accessed by the website’s JavaScript code.

Details

• Product: Secure Web Gateway
• Affected Versions: 12.x before 12.2.10, 11.x before 11.2.24, 10.2.11, potentially also other 10.x versions
• Fixed Versions: 12.2.10, 11.2.24 (not verified by RedTeam Pentesting)
• Vulnerability Type: Information Disclosure
• Security Risk: low
• Vendor URL: https://www.skyhighsecurity.com/en-us/products/secure-web-gateway.html
• Vendor Status: fixed version released
• Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2022-001
• Advisory Status: published
• CVE: CVE-2024-6398
• CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6398

Introduction

“Skyhigh Security Secure Web Gateway (SWG) is the intelligent, cloud-native web security solution that connects and secures your workforce from malicious websites and cloud apps—from anywhere, any application, and any device.”

(from the vendor’s homepage)

More Details

The Secure Web Gateway (SWG) can be configured with rules to block certain HTTP requests or responses. If such a rule is triggered, for example by a malicious file in the server response, the SWG will inject a block page as response to the request, replacing any actual response from the server. By default, the block page contains relevant information indicating why the request or response was blocked. The official documentation describes how the block page can be customised to contain very detailed and potentially sensitive information such as the applied rule names, client IP, proxy hostname and IP and even the username and authentication method of the proxy authentication.

All modern web browsers apply a Same Origin Policy to prevent access to the content of responses corresponding to cross-origin requests. However, as the block page is returned instead of an actual server response, the browser applies the Same Origin Policy to the block page response as if it was a response from the domain in the original request. This is especially problematic when a request to a website’s own origin is blocked by the SWG as the browser’s Same Origin Policy automatically grants access to the response in this case as it is considered a same-origin response. This allows any third-party website to access the potentially sensitive information contained in the block page whereas this information would not be accessible if the block page had been served from a separate domain.

It was also discovered that source paths of static assets such as images or JavaScript code embedded into the block page disclose URL paths that are always handled directly by the SWG, no matter on which domain they are accessed. Based on the Same Origin Policy considerations outlined above, these URL paths can be used by a third-party website to communicate with the SWG directly through the user’s browser. Extracting the URL paths from a block page also grants attackers the required information to exploit other vulnerabilities in the SWG such as a cross-site scripting vulnerability, which was also discovered by RedTeam Pentesting (see rt-sa-2022-002).

Proof of Concept

In order to exploit this vulnerability, a web server has to be set up that offers an endpoint to which communication is blocked by a SWG. The actual implementation of such an endpoint is highly dependent on SWG’s configuration. However, for typical rule sets, serving a well-known malicious executable of even just an EICAR test file is likely to suffice.

Additionally, the web server has to serve a web page containing JavaScript code that performs a request to the aforementioned endpoint and extracts the potentially sensitive information from the returned block page. The following example outlines a possible implementation:

let res = await fetch(`/path/to/blocked/content`);
console.log(await res.text())

Workaround

Remove any information from the block page that is considered sensitive.

Fix

According to the vendor, the vulnerability was fixed in versions 12.2.10 and 11.2.24. This was not verified by RedTeam Pentesting.

Security Risk

The vulnerability allows third-party websites to access information which is included in the SWG’s customisable block page. Therefore, the risk of this vulnerability heavily depends on the concrete information that is disclosed on the block page. The information included in typical customised block pages may aid in exploiting other vulnerabilities or provide hints about the applied rules which can potentially help in finding a rule bypass technique. While the vulnerability is generally considered a low risk only, it might be necessary to adjust the risk estimation based on the actual information that is disclosed in the configured block page, especially if it provides attackers with information that may be used to exploit other vulnerabilities such as rt-sa-2022-002.

Timeline

• 2022-07-29 Vulnerability identified
• 2022-10-20 Customer approved disclosure to vendor
• 2022-10-20 Vulnerability was disclosed to the vendor
• 2023-01-13 Vendor asked for more time
• 2023-06-27 Vendor asked for more time
• 2024-06-07 Vendor asked for more time
• 2024-07-15 Vendor confirmed release of fixed versions
• 2024-07-22 Advisory published

RedTeam Pentesting GmbH

RedTeam Pentesting offers individual penetration tests performed by a team of specialised IT-security experts. Hereby, security weaknesses in company networks or products are uncovered and can be fixed immediately.

As there are only few experts in this field, RedTeam Pentesting wants to share its knowledge and enhance the public knowledge with research in security-related areas. The results are made available as public security advisories.

More information about RedTeam Pentesting can be found at: https://www.redteam-pentesting.de/

Working at RedTeam Pentesting

RedTeam Pentesting is looking for penetration testers to join our team in Aachen, Germany. If you are interested please visit: https://jobs.redteam-pentesting.de/