CVE-2022-26134 Seen in the Wild by Cortex XDR

Nowadays, more and more Java vulnerabilities are being discovered. Exploiting these vulnerabilities can devastate a server, often resulting in remote code execution (RCE) and data leaks. And, since most Java vulnerabilities are logical, weaponizing them can be quite easy, which leads to widespread exploitation.

Cortex XDR for Linux protects against these kinds of exploits, and in the case of CVE-2022-26134, it helped block attacks out of the box without any configuration or content update.

CVE-2022-26134 is an RCE vulnerability, meaning that successful exploitation will result in a fully compromised server with attacker-controlled code running. This article will review some of the exploits and payloads we encountered in the wild and how we managed to stop them.

Atlassian published a security advisory on June 2nd, 2022, regarding the vulnerability used in the wild, and a proof-of-concept (POC) exploit was published soon after. Cortex XDR agent for Linux managed to catch various exploit attempts in the wild without any content changes to our product - even catching attempts on June 3rd, 2022. You can read here for a deeper dive into how our agent can block such exploits, where we detail how the Cortex XDR agent deals with the Log4Shell vulnerability.

Additional information regarding the exploit can be found on the Unit 42 blog.

Root Cause

Rapid7 has a great technical analysis on its blog. In essence, a user-controlled input is passed to the function TextParseUtil::translateVariables, which leads to Object-Graph Navigation Language (OGNL) evaluation which can be leveraged for Java code execution. This is similar to an Apache Struts vulnerability, where user-controlled input was also passed down to this function.

In the Wild

During our routine monitoring of Cortex XDR’s proprietary Java Anti-Deserialization module for Linux, available since Cortex XDR for Linux version 7.2 and content version 143, we encountered several attempts to execute commands on Confluence servers. It is important to note that the module prevented these commands from being executed, so customer servers were not impacted. It is insightful to explore the commands that attackers attempted to execute.

Case #1

We saw many commands of id and whoami, which used the basic exploitation technique, probably to just check whether the server was vulnerable.

Case 1: Example of how to trigger this basic RCE

We saw the attacker directly invoking Java’s infrastructure of executing processes without passing through an intermediary (as we will see in later cases).

Case #2

We saw the following commands prevented:

Case 2: Examples of malicious commands

This time, as can be seen in this stack trace collected by the Cortex XDR Java Deserialization module for Linux, the attackers chose to utilize Java’s built-in Javascript execution engine - Nashorn.

Figure 1. Stacktrace that includes Nashorn entries

Some public GitHub repositories with exploit scripts utilize the Nashorn engine for further execution. Unfortunately, the command-and-control (C2) server of the first two attack scenarios is down as of the writing of this blog post, so no further analysis was possible.

Regarding commands three and four, we assume they are part of the same campaign due to the shared IP being used. This campaign dropped XMR miners on the hosts to collect cryptocurrency. Each of these RCE payloads runs a remote script in memory, which downloads and runs another remote script, hxxp://202[.]28[.]229[.]174/ap.sh. Which eventually downloads and runs a variant of XMRig miner and a shell script used as a watchdog for the miner.

Case #3

We observed command execution attempts by a malicious actor trying to get a reverse shell:

Case 3: Attacker’s reverse shell

This is a classic TCP reverse shell payload meant to provide the attacker with remote interactive control over the server. Here the attacker used Nashorn as well, and the stack trace is similar to Case #2.

Cortex XDR for Linux Protection

Cortex XDR employs a multi-layer protection approach to these kinds of attacks and, therefore, can prevent the attack in several stages:

1. Java Anti-Deserialization Module prevents the exploitation attempt out of the box and synchronously, meaning no configuration changes were required and no malicious commands were executed.
2. Cortex XDR Behavioral Threat Protection and WildFire integration catch the miner execution.
3. There are several Behavioral Threat Prevention rules targeting reverse shell scenarios.

We highly recommend applying the supplied patch by Confluence as soon as possible and having the latest Cortex XDR for Linux agent running with the latest content.

Appendix - Indicators of Compromise