SonicWall Discovers Second Critical Apache OFBiz Zero-Day Vulnerability

Overview

The SonicWall Capture Labs threat research team has discovered a pre-authentication remote code execution vulnerability in Apache OFBiz being tracked as CVE-2024-38856 (insert link when available) with a CVSS score of 9.8. This is the second major flaw SonicWall has discovered in Apache OFBiz in recent months, the first coming in December 2023. This time, a flaw in the override view functionality exposes critical endpoints to unauthenticated threat actors using a crafted request, paving the way for remote code execution. It affects Apache OFBiz versions up to 18.12.14, and users are strongly encouraged to upgrade their instances to version 18.12.15 (insert link when available) or newer.

Apache OFBiz is an open-source Enterprise Resource Planning (ERP) system that can be adapted to meet the specific needs of different businesses across industries. Among its features, the software can automate and integrate many of a business's processes, including accounting, human resources, customer relationship management, order management, manufacturing and e-commerce. According to publicly available data, approximately 170 companies use Apache OFBiz. Among the users, 41% are in the United States, 19% are in India, 7% are in Germany, 6% are in France, and 5% are in the United Kingdom.

OFBiz software is used by several well-known companies such as United Airlines, Atlassian JIRA, GrowERP, Lindt Chocolate Club, Home Depot, Cognizant Technology Solutions Corp., Titan Industries, HP Development Company and Upwork Global Inc. Some of the major industries that utilize this software are Information Technology and Services (25%), Computer Software (17%), Internet (6%) and Retail (5%). Additionally, many companies may use OFBiz as part of their software supply chain.

SonicWall is committed to helping defenders get the necessary resources to protect their organizations. As part of this effort, we responsibly disclosed the discovered vulnerability to Apache OFBiz, providing them with advanced notice so that patches or other mitigation strategies can be deployed. In addition to the patch, SonicWall has developed IPS signature IPS:4455 to detect any active exploitation of this vulnerability. At this time, SonicWall is unaware of any active exploitation.

Technical Overview

While analyzing the CVE-2024-36104, disclosed on June 3rd, an unauthenticated RCE using path traversal, we noticed that the ControlServlet and RequestHandler functions received different endpoints to process, as seen in the log output displayed in Figure 2. This occurred when sending the publicly available PoC as seen in Figure 1. Ideally, both the ControlServlet and RequestHandler should get the same endpoint to process, or the RequestHandler function should render the login view if the requested endpoint requires authentication.

[Link]

Figure 1: CVE-2024- 36104 exploit request in 18.12.13

[Link]

Figure 2: CVE-2024- 36104 request logs

While we suspected the root cause of the issue lies in the authentication process, the patch reveals that checks were introduced to prevent path traversal attack vectors as seen in Figure 3.

[Link]

Figure 3: CVE-2024-36104 patch

Our suspicions led us to try and circumvent the patch. One test case we started working with was to send the raw URL without any path traversal vector -
"POST /webtools/control/forgotPassword/ProgramExport". The result of this test and removing the path traversal attack was that access was granted!

Unauthenticated access was allowed to the ProgramExport endpoint by chaining it with any other endpoints that do not require authentication by abusing the override view functionality. Endpoints that do not require authentication are generally defined in the controller.xml with either auth="false" or without auth attribute, for example, forgotPassword, showDateTime, TestService, view, and main. This means that some URLs that can be used to exploit this vulnerability are:

• POST /webtools/control/forgotPassword/ProgramExport
• POST /webtools/control/main/ProgramExport
• POST /webtools/control/showDateTime/ProgramExport
• POST /webtools/control/view/ProgramExport
• POST /webtools/control/TestService/ProgramExport

To gain a deeper understanding of the issue, we dove into the data processing flow within the authentication mechanism in the RequestHandler.java file during the attack, as demonstrated in Figure 4. This request executes the id command in case of successful exploitation of the vulnerability.

[Link]

Figure 4: CVE-2024-38856 exploit request in version 18.12.14

Technical Root Cause Analysis

Upon receiving the request, the server initializes the values of the variables path, requestUri and overrideViewURI, as shown in Figure 5.

[Link]

Figure 5: Initialization of requestUri

While the setting of the path is straightforward, it calls the getRequestUri and getOverrideViewUri methods to calculate the values of requestUri and overrideViewUri respectively. Here, the difference in the calculated return values of requestUri and overrideViewUri for the given path (/forgotPassword/ProgramExport) stands out. The bug lies in the logic of the authentication mechanism since the authentication checks are performed on requestUri; however, the page located in overrideViewUri is being rendered.

As seen in Figure 6, the getRequestUri method splits the path by "/" and returns the value of the 0^th element-forgotPassword.

[Link]

Figure 6: getRequestUri calculating the value of requestUri

Then, the program proceeds to initialize the value of the overrideViewUri variable. In order to calculate the value of overrideViewUri, the getOverrideViewUri method first splits the value of path by "/" to separate the path items, as seen in Figure 7.

[Link]

Figure 7: getOverrideViewUri method in action

After the split, the 0 element from the list is discarded, and the 1^st element (ProgramExport) is returned as demonstrated in Figure 8. The key here is this does not match what the getRequestUri method returns, as it keeps the 0 element.

[Link]

Figure 8: getOverrideViewUri calculating the value of overrideViewUri

As a result of this mismatch, the final calculated values of requestUri and overrideViewUri are requestUri=forgotPassword and overrideViewUri=ProgramExport, shown in Figure 9.

[Link]

Figure 9: Final values of requestUri and overrideViewUri

Since the authentication checks are performed on the value of requestUri (forgotPassword) and not on the value of overrideViewUri (ProgramExport), the difference in the calculated values creates confusion for the authentication functionality, as seen in Figure 10, allowing the malformed request to be executed.

[Link]

Figure 10: Security checks for malformed request

Figure 11 highlights the difference between the value of securityAuth for the malformed vs legitimate request. For a malformed request, its value is false, meaning there won't be a need for authentication, unlike the legitimate request. Here, the legitimate request hits the endpoint ProgramExport directly using the URL POST /webtools/control/ProgramExport

[Link]

Figure 11: Security checks for malformed request

Finally, it renders the ProgramExport view at the end, as seen in Figure 12, allowing the execution of the supplied code without authentication.

[Link]

Figure 12: Rendering of the view - ProgramExport

Patch Review

The vulnerability was fixed swiftly (Kudos!) by Apache OFbiz with this commitby introducing the improved permission checks to execute the groovy functions. For due diligence, we confirmed the patch's effectiveness by running the same exploit request mentioned above, which was unsuccessful.

Acknowledgment

We appreciate the prompt response and remediation by the Apache OFBiz team. They demonstrated extreme care for the security of their customers and were a pleasure to work with. The time from reporting the vulnerability to receiving a patch for analysis was less than 24 hours.