CVE-2023-51467 is an authentication bypass recently disclosed by SonicWall in Ofbiz—an Enterprise Resource Planning (ERP) system solution for automating applications and business management.
This vulnerability enables remote code execution (RCE) through xmlRPC requests to endpoints, leading to the execution of commands on the system.
Unfortunately, the initial mitigation efforts proved ineffective as they did not address the root cause, resulting in a new bypass with different CVE numbers and techniques.
This analysis explores Ofbiz, focusing on the main root cause behind CVE-2023-49070, CVE-2020-9496, and CVE-2023-51467. Notably, CVE-2023-51467 is not the first exploitation of this endpoint and was previously used by the Syssrv botnet for CVE-2020-9496.
Setting Up The Testing Lab
- Ensure that you have JAVA installed on the system; ysoserial requires JDK8 for proper functionality.
- Download the vulnerable version of Ofbiz using the command: wget https://codeload.github.com/apache/ofbiz-framework/zip/refs/tags/release18.12.05
- Unzip the downloaded file and build the application by running: ./gradlew ofbiz
- Verify the application is running by visiting: https://localhost:8443
- Setting up the debugging environment in Ofbiz is straightforward. Add the debugging flag –debug-jvm with the command: ./gradlew ofbiz –debug-jvm
- Configure the remote JVM debugging client with the default port 5005.
- Choose ‘Project structure’ in ‘File > Project structure‘ in the toolbar.
- Now, Ofbiz libraries and the debugger are ready for analysis.
The Vulnerability Analysis
Before diving into the analysis, let’s review the history of RPC exploits, examine their mitigation techniques, and explore bypass strategies to understand the structure of the application and its functionality.
CVE-2020-9496 – Insecure deserialization through XML-RPC request
The exploitation of CVE-2020-9496, involving insecure deserialization through XML-RPC requests, was carried out using the ysoserial tool. This tool generated a gadget chain utilizing CommonsBeanutils1 due to the application’s dependency on commons-beanutils:1.9.2.
The generated chain was then encoded in base64 and sent to the endpoint with an XML-RPC request structure, specifically to /webtools/control/xmlrpc.
The Ofbiz application was implemented with commons-beanutils:1.9.2.
For those interested in exploring gadget chains further, a comprehensive research paper on Java Deserialization RCE is available at https://hal.science/hal-03747004/document.
The request for this vulnerability was as follows:
The request contained placeholders such as <methodCall> and <methodNAme>, shaping the request structure correctly with struct parameters that took complex values.
Here we can see that the secure file gets created in the /tmp directory.
Moving on to the runtime analysis, the web application routing is stored in the Java application at /WEB-INF/web.xml.
This leads to the ControlServlet class in org.apache.ofbiz.webapp.control. Here, the doPost and doGet methods, handling post and get requests, were observed. The ConfigXMLReader, calling the RequestHandler method, proved to be of interest.
Now, we get the content resources from controller.xml.
The real path was /framework/webtools/webapp/webtools/WEB-INF/controller.xml.
Upon inspecting this file, I noticed that the event type for XML-RPC was XMLRPC, and importantly, there was no authentication check. This absence of authentication verification became a crucial point for mitigation.
EventFactory
And EventFactory will be instantiated to handle the events
runEvent
Will complete the process of the request with xmlRcpEventHandler
The application employed an external library to handle the XML request. This entire process, lacking an authentication check on /webtools/control/xmlrpc endpoint, exposed the endpoint to get used by unauthenticated users.
Patch diffing
To address this vulnerability, mitigation involves implementing authentication checks before accessing the endpoint. This is achieved by verifying the presence of a username and password in the file and adjusting the configuration to mandate authentication through routing in the controller.xml file.
LoginWorker.java
controller.xml
However, this mitigation step can be bypassed by introducing login parameters and requirePasswordChange to cause a logic vulnerability. This specific bypass was associated with CVE-2023-49070.
CVE-2023-49070 – Authentication Bypass leads to RCE
As we see here it’s to the same endpoint but with USERNAME=, &PASSWORD=, and &requirePasswordChange=Y to the endpoint which causes the bypass
As we see the secure file get created again under the /tmp directory
The process for CVE-2023-49070 follows a similar pattern, with the key distinction lying in the authentication aspect. This variation exploits the authentication bypass that we observed in the mitigation of CVE-2020-9496.
During the debugging of CVE, we can see that the Method responsible for checking login was checkLogin
Upon closer inspection, we focused on the ‘CheckLogin’ method within ‘extensionCheckLogin.’
The checkLogin starts checking the request.
This method checks the request, particularly for the parameters username, password, and token if they are null the application will return an error so in case there is no error the application will consider it as a successful login and Here is the root cause of this CVE which makes a logic vulnerability that makes the application fail to handle the login
Because by adding requirePasswordChange and making it equal to Y lets the application
get confused and will return requirePasswordChange rather than the error if there is no error rise the application will consider it a valid login and achieve Authentication bypass
doFilter
The checkLogin function assesses the request to the /control/xmlrpc endpoint and, if it contains </serializable>, logs an error stating ‘content not authorized for security reasons.’
The bypass of this filter was by adding ; to the end of /control/xmlrpc endpoint
The mitigation of this vulnerability was by removing XMLRPC-related to prevent attackers from exploiting the /webtools/control/xmlrpc endpoint and parsing the payloads to achieve RCE.
However, this mitigation was effective because it only prevented the attack for only /webtools/control/xmlrpc endpoint without mitigating the root cause of the authentication bypassing which caused CVE-2023-51467.
CVE-2023-51467 – Getting remote code executing using groovy
After identifying the new technique to exploit this vulnerability, a tweet by a security researcher showcasing the of using Groovy, specifically targeting /webtools/control/programexport.
This method involved using groovy language to circumvent authentication for this endpoint, similar to the approach seen in CVE-2020-9496 but with a different technique
The used command in the PoC : groovyProgram=throw+new+Exception(‘id’.execute().text);
The bypass was caused by CVE-2023-49070, but this time it was to access /webtools/control/programexport. Groovy wasn’t the root cause here, as it can be programmatically imported into all Apache applications.
The application was using a wordlist as security checks to prevent command injection and denial of services but these weren’t effective in our scenario and there are a lot of ways that can be used to bypass it with encoding
The mitigation strategy involved comparing the ‘LoginWorker.java‘ files in the new and old versions, with modifications detected in the following in certain lines:
The old check was replaced with UtilValidate.isEmpty for better handling of null and empty values
and
To handle unsuccessful logins and not process with requiredPasswordChange to prevent the authentication bypass
For further insights into Ofbiz security mitigation, refer to https://ofbiz.apache.org/security.html.
Conclusion
Our analysis, coupled with the historical context of mitigating these vulnerabilities, underscores the importance of addressing the main root cause for effective and lasting solutions.
Temporary fixes are prone to being bypassed, making it imperative to tackle vulnerabilities at their core. The ease of exploiting the root cause of this CVE heightens its risk, potentially enabling even script kiddies to leverage public exploits and cause significant damage.
Therefore, maintaining up-to-date products is paramount for robust security measures.
References
https://blog.sonicwall.com/en-us/2023/12/sonicwall-discovers-critical-apache-ofbiz-zero-day-authbiz
