During the course of our work, Nettitude have identified a stored Cross-Site Scripting (XSS) vulnerability within the CrushFTP web interface.
CrushFTP is a file transfer server which supports multiple file transfer protocols, and provides a web interface for users to manage their files, as well as for administrators to manage and monitor the service.
As shown below, there is a list of the most visited users displayed at the top of the page.
The list consists of
<a> HTML tags that contain each username. The double-quote character is not properly sanitized inside the
CrushFTP stores the details of registered users within the filesystem in the
users/MainUsers directory. The contents of this directory are shown below, with the users
TempAccount each having their own directory.
The user’s directory contains a file called
user.XML, which contains the data associated with the account. This is where information such as the username, password, etc, is stored in XML format.
When attempting to create a user, after a request to check if the username already exists, the application performs a POST request towards the
/WebInterface/function/ endpoint. The command used within the request is
setUserItem which creates the user folder in the application’s backend containing the given information.
The text highlighted below in red is the name of the directory that will be created for the user, while the text highlighted in blue is the username that will be saved within their
user.XML file. Nettitude modified this request, placing the value
random_user1 within the username POST parameter and
random_user2 within the username parameter in the XML data.
The new user then appeared within the users panel on the left hand side of the page.
From this, it was clear that the web application indexes the username by the name of the directory created for the user, and not by the username that is added in the
user.XML file. Nettitude reproduced the previous steps, but this time replacing the username parameter with
The application failed to validate the integrity of the data server-side, and the user’s folder was created with the payload included, as shown below.
After the operation was completed, the newly created user appeared within the users panel.
mostVisitedLinks list was also populated with the most visited users’ profiles.
Since the username had been tampered with and no output encoding was performed prior to adding the username to the user attribute of the
<a> object, the double-quote of the user attribute was escaped, and the
<img> tag that was injected in the username was rendered within the page.
Given that an invalid image source was used within the payload, this meant that the
If an attempt was made to delete the user, the payload would fire again in the pop-up window that appears.
The impact of a cross-site scripting attack can vary depending on the payload used, but it can usually be exploited for theft of information such as session cookies or other sensitive data, or to conduct unauthorised actions on behalf of an affected user. In this instance it may be exploited for privilege escalation or account takeover.
This vulnerability affected CrushFTP prior to version 9.4.0_15. Any later versions are no longer affected by this vulnerability, as the vendor was informed and performed the necessary actions to remediate the issue.
Multiple parts of the source code contribute to the payload’s execution in various fields, but the main reason behind the vulnerability is the incorrect sanitization of the username as it is processed within the backend. This, can be found in the
setUserItem function inside the
No input filtering was performed on the username, so special characters entered in the username field are not removed or sanitized in any way. In addition to this, no output encoding was performed when the data was displayed within the affected page itself. Proper output encoding, in combination with a strong content security policy, should always be used to mitigate the risk of cross-site scripting.
- Discovery by Nettitude: 19 November 2021
- CVE Assigned: 19 November 2021
- Vendor informed: 04 March 2022
- Vendor fix released: 08 March 2022