CVE-2023–39612: CSP bypasss + XSS to achieve Admin Account Takeover + Remote Command Execution in FileBrowser

My 5th CVE: CVE-2023–39612

Hi, Febin here back again with a story of my 5th CVE. CVE-2023–39612 is an XSS vulnerability bypassing CSP, in FileBrowser (a popular self-hosted web-based File Manager).

https://nvd.nist.gov/vuln/detail/CVE-2023-39612

FileBrowser Github Repo: https://github.com/filebrowser/filebrowser

Let’s investigate Vulnerability….

Description

A Cross-Site Scripting vulnerability is discovered in FileBrowser below v2.25.0 in which an attacker with a non-admin user account inside the FileBrowser instance can create malicious HTML & JS files, craft them in a specific way, and send the HTML file’s link to the Admin to achieve Account takeover via XSS bypassing the Content-Security-Policy.

Proof-Of-Concept:

// xss.js

alert(document.cookie);

// xss.htm

<script src="/api/raw/poc/xss.js?auth=[jwt_token of the normal user/attacker]

1. Request valid tokens of the user. FileBrowser allows multiple tokens to be requested.

2. Create the 2 files as above (xss.htm and xss.js) under the poc folder. Here, am not creating a folder named “poc”, I am uploading both the files directly.

3. Craft the XSS URL as below and open it as the Admin user to verify the XSS.

http://your_filebrowser_ip:port//api/raw/poc/xss.htm?auth=[non-admin user's jwt token]&inline=true

Request without “inline=true”

Request when I add “inline=true” parameter

When the Admin loads the crafted URL in his browser, it will trigger a javascript alert with the Admin’s session token/cookie in it. The CSP is completely bypassed and the HTML file is loaded inside the browser session instead of it being downloaded as an attachment.

There’s an inbuilt option to share files to other users in FileBrowser, it can be abused to deliver the payload to the Admin user.

Admin accesses the shared file

Admin opens the shared file from User

XSS triggered

Explanation

• The parameter “?auth=[non-admin token]” is added in the URL so that when the Admin opens the URL it will fetch those HTML/js files that are created by the non-admin user, otherwise FileBrowser will use the Admin’s original jwt token that’s been stored as Cookie thus leading to a “404 Not Found” Error. This is because those files are created by the non-admin user, so if the API tries to fetch them with Admin’s token it will lead to an error, the API also accepts the jwt token inside a URL get parameter “?auth=”. So, the non-admin user can deliberately supply his own JWT token in the malicious URL for a successful exploitation
• The “?inline=true” parameter is included in the crafted URL because without that parameter FileBrowser will treat the HTML file as an attachment and will download it as a file, so by having “inline=true” the HTML file will be treated as an webpage, and execute the javascript.
• Content-Security-Policy(CSP) is bypassed because FileBrowser sets CSP “default-src” to ‘self’. As the malicious JS is also loaded from the same site, it will get executed.

CSP header

Impact

This vulnerability is capable of Admin account takeover, create backdoor users with Admin privilege.

How this leads to RCE?

• Achieving RCE from FileBrowser Admin account is fairly straightforward. There’s a feature for the Admin to execute system commands in FileBrowser, attacker can achieve RCE that way.

Exec Shell commands

• Another way is by accessing the File System by changing the “scope” to arbitrary locations on the machine with the privileges of the user that’s running/hosting the FileBrowser, and modifying files like ~/.bashrc or adding custom malicious Desktop entries (.desktop file) to ~/.config/autostart/ (xdg autostart directory for linux desktop, similar to user startup folder in Windows). Note: “~/” stands for “/home/<username>/”.

Fix:

They fixed the vulnerability by adding a CSP that blocks any Javascript from executing on /api/raw endpoint.

https://github.com/filebrowser/filebrowser/commit/b508ac3d4f7f0f75d6b49c99bdc661a6d2173f30

Update to the latest version if you are using Filebrowser.

Filebrowser v2.25.0 is released

https://github.com/filebrowser/filebrowser/releases

Takeaway:

• Got an XSS but there’s a CSP “default-src ‘self’ ” implemented? You can try to bypass the CSP if there’s an file upload functionality.
• Got an HTML file upload? Trying to leverage it to a Stored-XSS? Always try “?inline=true”. Here are some more, “?inline”, “?view=inline” and “?open=inline”.
• Always dig deeper.

Thanks.

Follow me on Twitter(X): https://twitter.com/febin_nj

Follow me on LinkedIn: https://www.linkedin.com/in/febin-mon-saji-1787951b1