Post Syndicated from Vaibhav Singhal original https://blog.cloudflare.com/cloudflare-observations-of-confluence-zero-day-cve-2022-26134/

On 2022-06-02 at 20:00 UTC Attlasian released a Security Advisory relating to a remote code execution (RCE) vulnerability affecting Confluence Server and Confluence Data Center products. This post covers our current analysis of this vulnerability.

When we learned about the vulnerability, Cloudflare’s internal teams immediately engaged to ensure all our customers and our own infrastructure were protected:

• Our Web Application Firewall (WAF) teams started work on our first mitigation rules that were deployed on 2022-06-02 at 23:38 UTC for all customers.
• Our internal security team started reviewing our Confluence instances to ensure Cloudflare itself was not impacted.

What is the impact of this vulnerability?

According to Volexity, the vulnerability results in full unauthenticated RCE, allowing an attacker to fully take over the target application.

Active exploits of this vulnerability leverage command injections using specially crafted strings to load a malicious class file in memory, allowing attackers to subsequently plant a webshell on the target machine that they can interact with.

Once the vulnerability is exploited, attackers can implant additional malicious code such as Behinder; a custom webshell called noop.jsp, which replaces the legitimate noop.jsp file located at Confluence root>/confluence/noop.jsp; and another open source webshell called Chopper.

Our observations of exploit attempts in the wild

Once we learned of the vulnerability, we began reviewing  our WAF data to identify activity related to exploitation of the vulnerability. We identified requests matching potentially malicious payloads as early as 2022-05-26 00:33 UTC, indicating that knowledge of the exploit was realized by some attackers prior to the Atlassian security advisory.

Since our mitigation rules were put in place, we have seen a large spike in activity starting from 2022-06-03 10:30 UTC — a little more than 10 hours after the new WAF rules were first deployed. This large spike coincides with the increased awareness of the vulnerability and release of public proof of concepts. Attackers are actively scanning for vulnerable applications at time of writing.

Although we have seen valid attack payloads since 2022-05-26, many payloads that started matching our initial WAF mitigation rules once the advisory was released were not valid against this specific vulnerability. Examples provided below:

The activity above indicates that actors were using scanning tools to try and identify the attack vectors. Exact knowledge of how to exploit the vulnerability may have been consolidated amongst select attackers and may not have been widespread.

The decline in WAF rule matches in the graph above after 2022-06-03 23:00 UTC is due to us releasing improved WAF rules. The new, updated rules greatly improved accuracy, reducing the number of false positives, such as the examples above.

A valid malicious URL targeting a vulnerable Confluence application is shown below:

(Where $HOSTNAME is the host of the target application.)

The URL above will run the contents of the HTTP request post body eval(#parameters.data[0]). Normally this will be a script that will download a web shell to the local server allowing the attacker to run arbitrary code on demand.

Other example URLs, omitting the schema and hostname, include:

Some of the activity we are observing is indicative of malware campaigns and botnet behavior. It is important to note that given the payload structure, other WAF rules have also been effective at mitigating particular variations of the attack. These include rule PHP100011 and PLONE0002.

Cloudflare’s response to CVE-2022-26134

We have a defense-in-depth approach which uses Cloudflare to protect Cloudflare. We had  high confidence that we were not impacted by this vulnerability due to the security measures in place. We confirmed this by leveraging our detection and response capabilities to sweep all of our internal assets and logs for signs of attempted compromise.

The main actions we took in response to this incident were:

1. Gathered as much information as possible about the attack.
2. Engaged our WAF team to start working on mitigation rules for this CVE.
3. Searched our logs for any signs of compromise.
4. We searched the logs from our internal Confluence instances for any signs of attempted exploits. We supplemented our assessment with the pattern strings provided by Atlasian: “${“.
5. Any matches were reviewed to find out if they could be actual exploits. We found no signs that our systems were targeted by actual exploits.
6. As soon as the WAF team was confident of the quality of the new rules, we started deploying them to all our servers to start protecting our customers as soon as possible. As we also use the WAF for our internal systems, our Confluence instances are also protected by the new WAF rules.
7. We scrutinized our Confluence servers for signs of compromise and the presence of malicious implants. No signs of compromise were detected.
8. We deployed rules to our SIEM and monitoring systems to detect any new exploitation attempt against our Confluence instances.

How Cloudflare uses Confluence

Cloudflare uses Confluence internally as our main wiki platform. Many of our teams use Confluence as their main knowledge-sharing platform. Our internal instances are protected by Cloudflare Access. In previous blog posts, we described how we use Access to protect internal resources. This means that every request sent to our Confluence servers must be authenticated and validated in accordance with our Access policies. No unauthenticated access is allowed.

This allowed us to be confident that only Cloudflare users are able to submit requests to our Confluence instances, thus reducing the risk of external exploitation attempts.

What to do if you are using Confluence on-prem

If you are an Atlassian customer for their on-prem products, you should patch to their latest fixed versions. We advise the following actions:

1. Add Cloudflare Access as an extra protection layer for all your websites. Easy-to-follow instructions to enable Cloudflare Access are available here.
2. Enable a WAF that includes protection for CVE-2022-26134 in front of your Confluence instances. For more information on how to enable Cloudflare’s WAF and other security products, check here.
3. Check the logs from your Confluence instances for signs of exploitation attempts. Look for the strings /wiki/ and ${ in the same request.
4. Use forensic tools and check for signs of post-exploitation tools such as webshells or other malicious implants.

Indicators of compromise and attack

The following indicators are associated with activity observed in the wild by Cloudflare, as described above. These indicators can be searched for against logs to determine if there is compromise in the environment associated with the Confluence vulnerability.

Indicators of Compromise (IOC)

#	Type	Value	Filename/Hash
1	File	50f4595d90173fbe8b85bd78a460375d8d5a869f1fef190f72ef993c73534276	Filename: 45.64.json Malicious file associated with exploit
2	File	b85c16a7a0826edbcddbd2c17078472169f8d9ecaa7209a2d3976264eb3da0cc	Filename: 45.64.rar Malicious file associated with exploit
3	File	90e3331f6dd780979d22f5eb339dadde3d9bcf51d8cb6bfdc40c43d147ecdc8c	Filename: 45.640.txt Malicious file associated with exploit
4	File	1905fc63a9490533dc4f854d47c7cb317a5f485218173892eafa31d7864e2043	Filename: 45.647.txt Malicious file associated with exploit
5	File	5add63588480287d1aee01e8dd267340426df322fe7a33129d588415fd6551fc	Filename: lan (perl script) Malicious file associated with exploit
6	File	67c2bae1d5df19f5f1ac07f76adbb63d5163ec2564c4a8310e78bcb77d25c988	Filename: jui.sh Malicious file associated with exploit
7	File	281a348223a517c9ca13f34a4454a6fdf835b9cb13d0eb3ce25a76097acbe3fb	Filename: conf Malicious file associated with exploit

Indicators of Attack (IOA)

#	Type	Value	Hash
1	URL String	${	String used to craft malicious payload
2	URL String	javax.script.ScriptEngineManager	String indicative of ScriptEngine manager to craft malicious payloads