usd-2024-0008 | Path Traversal in Webswing Upload Functionality

Advisory ID: usd-2024-0008
Product: Webswing
Affected Version: Confirmed on 23.2.2, potentially also on 24.1 (not tested)
Vulnerability Type: Relative Path Traversal (CWE-23)
Security Risk: High
Vendor URL: https://webswing.org/
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE Number: CVE-2024-39332
CVE Link: https://nvd.nist.gov/vuln/detail/CVE-2024-39332

Affected Component

Due to the product being closed-source, it is not possible to pinpoint the exact component.
As Webswing works by offering a toolkit that aims to be a drop-in replacement for Java Swing's toolkit, it is likely that the vulnerability is contained in the Webswing equivalent of java.awt.FileDialog.

Description

Webswing allows you to run Java Swing applications inside a web browser.
It consists of (a) the Webswing toolkit, which aims to be a drop-in replacement for Java Swing's toolkit, (b) the Webswing server and (c) the Webswing frontend.
In order to do so, it has to act as an intermediary between the Java client and the user's browser.
This requires putting various operations, such as file dialogs, into to context of the user's browser in a way that does not affect the Java client.
This vulnerability is contained within the logic that maps file imports functionality in Java clients to file upload functionality in browsers.

As far as can be observed from the outside, Webswing does this as follows:
1. Whenever the Java client wants to import a file, it calls the createFileDialog function with the necessary settings.
2. Depending on its configuration the Webswing server creates or chooses an upload folder.
3. The Webswing server sends a message to the Webswing frontend, which creates a file dialog from within the user's browser.
4. The Webswing frontend uploads the file contents as well as its filename to the Webswing server.
5. The Webswing server places the file into the specified upload folder and finally hands it to the Java client.

The vulnerability is contained in step 5 and can be exploited by specifiying a malicious filename in step 4.

Proof of Concept

When the user opts to upload a file, Webswing creates a popup which in turn opens file dialog on the user's system.
The functionality of this popup is contained in webswing-embed.js, in particular in the Jr class.

As this JavaScript code is in the user's browser, it can be modified. For example, the filename can be adjusted before the request is handed to the backend.
In the following the path traversal is added to the filename in the t variable.

sendUploadStart(e, t, r) {    
    this.manager.send({        
        directUpload: {            
            transferId: e,            
            event: Br.start,            
            fileName: "./../../../../home/webswing/.ssh/" + t,            
            size: r        
        }    
    })
}

The Webswing server receives the data sent from the browser via Websocket and passes it on to the Java application without further filtering.
In other words, the Webswing backend accepts the filename from the Webswing JavaScript frontend without validation and the Java Application trusts the path given by Webswing.

As a result, an attacker can write to arbitrary file locations that are accessible by the webswing user.

In the example payload above, the uploaded file is saved in /home/webswing/.ssh/. Even if the folder not exists it gets created.

In terms of impact, this vulnerability very likely leads to remote code execution for the attacker.
For example, if the SSH port had been open, the attacker could login using his respective private key.
Even without SSH, an attacker can modify any of the various shell scripts on the Webswing server to gain an interactive shell through a backdoor.

Fix

The backend should not trust the user input from the frontend and should not use the provided filename without filtering.
It is recommended to filter all input that is used in the context of file operations for path specifications.

Users of the software should upgrade to versions 24.1.1, 23.2.8 LTS, 22.1.23 LTS that fix this security issue.

References

Timeline

  • 2024-05-06: First contact request via contact form on https://www.webswing.org/en/contact.
  • 2024-06-05: Vulnerability confirmed by vendor.
  • 2024-06-17: The Responsible Disclosure Team requested a CVE for the issue in coordination with Webswing.
  • 2024-07-01: Vulnerability fixed in Versions 24.1.1, 23.2.8 LTS, 22.1.23 LTS.

Credits

This security vulnerability was identified by Ehud Cseresnyes and Yannick Westphal of usd AG.