Kinsing Malware Exploits Novel Openfire Vulnerability

Aqua Nautilus discovered a new campaign that exploits the Openfire vulnerability (CVE-2023-32315), that was disclosed in May of this year, to deploy Kinsing malware and a cryptominer. This vulnerability leads to a path traversal attack, which grants an unauthenticated user access to the Openfire setup environment. This then allows the threat actor to create a new admin user and upload malicious plugins. Eventually the attacker can gain full control over the server. In this blog, we explain the vulnerability, Kinsing’s campaign, and quantify the extent of instances potentially exposed to this specific vulnerability. For example, our dedicated Openfire honeypot demonstrated over 1,000 attacks in less than two months.

The Openfire Vulnerability

Openfire is a real-time collaboration (RTC) server that is used as a chat platform for sending instant messages over the XMPP protocol (Extensible Messaging and Presence Protocol). It is designed as an internal IM server for enterprises, supporting more than 50,000 concurrent users and providing them with a secure and segmented channel for communication across different departments within an organization.

In May this year, a new vulnerability (CVE-2023-32315) was discovered in the Openfire console. This vulnerability, which was found in the console, is related to path traversal through the setup environment. This flaw allows an unauthorized user to exploit the unauthenticated Openfire Setup Environment within an established Openfire configuration. As a result, a threat actor gains access to the admin setup files that are typically restricted within the Openfire Admin Console. Next, the threat actor can choose between either adding an admin user to the console or uploading a plugin which will eventually allow full control over the server.

The anatomy of the Kinsing campaign

This Kinsing campaign exploits the vulnerability, drops in runtime Kinsing malware and a cryptominer, tries to evade detection and gain persistence. This is illustrated in the attack flow chart below:

The threat actor scans the internet for Openfire servers (an example can be found below), and once a server is found, it is automatically tested if the server is vulnerable to CVE-2023-32315.

This vulnerability allows the creation of a new admin user with the ability to upload plugins. In this campaign, the threat actor uses the vulnerability to create a new admin user and upload a plugin (cmd.jsp), which was designed to deploy the main payload – Kinsing malware.

As seen in figure 2 below, the threat actor is sending a user create command to the user-create.jsp.

Figure 2: The request made by the attacker to create a new user on our Openfire server

The request is constructed from the following fields:

• Create – the create=%E5%88%9B%E5%BB%BA%E7%94%A8%E6%88%B7 argument is an html encoding that translates to 创建用户 which is in Chinese and stands for create user.
• CSRF – A unique token generated on the server side and shared with the client to safeguard against CSRF attacks. Incorrect validation of the token when using the GET method allows bypassing the validation.
• Username – Adding a name of the new created user.
• Password – Adding a password to the new created user.
• Confirm – Password reentry for the new user.
• isAdmin – Grants the new user Admin permissions.
• Create – Sends the above data to create the new user.

Once the new user is successfully created, it enables the threat actor to undergo a valid authentication process for the Openfire Administration Panel, thereby gaining complete access as an authenticated user. Furthermore, since the user is created as an admin, this grants the threat actor with elevated permissions within the system.

Next, the threat actor is uploading a malicious plugin that allows web shell commands on the server, as seen in Figure 3 below.

Figure 3: Successful upload of a zipped Metasploit framework

The threat actor uploads a zip file which is a Metasploit exploit aimed to extend the cmd.jsp to enable http requests at the threat actor’s disposal. This allows downloading the Kinsing malware which is hard coded in the plugin. As depicted in Figure 4 below, the file was flagged in VirusTotal (VT) as malicious (backdoor/Kinsing) by two vendors.

Figure 4: VirusTotal scan of the zipped Metasploit file

The zip file contains a malicious jar file, but has no detections in VT.

In Figure 5 below you can see a snippet from this JAR file that sheds some more light on its purpose.

Figure 5: A snippet from the main payload in the attack

This plugin contains a Java class named cmd.jsp that is a backdoor which enables downloading files and executing commands on the server.

Next, there’s a broad communication between the C2 server and the malware (which we will further elaborate on in a future dedicated blog). Next a new shell script is downloaded as a secondary payload.

This script creates a cronjob and delete competition, so it’s designed to make persistence on the server, as can be seen in Figures 6 and 7 below.

Figure 6: Establishing Server Persistence Through Cronjob

Figure 7: Eliminating old/competing attacks

Vulnerable Openfire Servers in the Wild

Since Openfire is being used by large organizations around the world, we were curious about the level of exposure in the wild. We queried Shodan (IPs search engine) and found 6,419 internet connected servers with Openfire service running. Out of this initial number 1,383 (21.5%) weren’t reachable. We were left with 5,036 servers, out of which 984 were vulnerable to this vulnerability (19.5%).
Below in figure 8, you can see the geo location spread of these servers, as it appears that the majority are located in USA, China and Brazil.

Figure 8: Openfire vulnerability instances Map

In the beginning of July, we created an Openfire honeypot, and it was immediately targeted. As illustrated in figure 9 below, there are dozens of attacks per day that targeted the Openfire vulnerability. The majority though (91%) were attributed to the Kinsing campaign described above.

Figure 9: Our Openfire honeypot attack trend between July 1st and August 23rd

We found that our honeypot was targeted by two distinct types of attacks. One that was broadly discussed above, which deploys a web shell and enables the attacker to download Kinsing malware and cryptominers, all the attacks seem to be connected. The second one involves the same Metasploit exploit to deploy the web shell, but we haven’t seen any specific tools used during this attack. The attackers collected information about the system but didn’t continue their attack.

How to Secure Your Environment

As the count of newly discovered vulnerabilities continues to rise, estimated to reach tens of thousands each year, we must heighten our awareness and invest more attention in maintaining our resources. This blog underscores how vulnerabilities can impact the entire environment, putting it at risk. Through the exploitation of the vulnerability, the threat actor gains authentication as an admin user, enabling the ability to execute actions within the Openfire Administration Console, and ultimately, execute malicious commands remotely.
To protect against these types of attacks, we propose adhering to the following guidelines:

1. Keep Your Environment Up to Date

Given that vulnerabilities are periodically unveiled, it’s paramount to stay vigilant regarding updates and security alerts. Should you discover that one of your instances is susceptible, promptly undertake updates in accordance with the distributor’s guidelines. The Aqua Platform allows you to easily detect novel vulnerabilities. We built a vulnerable Openfire application to serve as our honeypot, in the screenshots below you can see our validation process to scan the newly created container image to verify it is vulnerable to the abovementioned vulnerability.

As illustrated in figure 10, we set the scanner to fail any images with a severity score high or critical. In this case the only vulnerability was the Openfire CVE-2023-32315, which failed the compliance of the container image.

Figure 10: The Aqua platform fails the build when a high rank vulnerability is detected

Figure 11: Vulnerability details as seen in the Aqua platform

2. Configure Environments Diligently

Steer clear of employing default settings and ensure that passwords adhere to best practices. Regularly refreshing secrets and passwords further bolsters the security of your environments.

3. Conduct Thorough Environment Scans for Unknown Threats

Threat actors are progressively refining their tactics, camouflaging their activities to resemble legitimate operations, making the detection of their actions a formidable challenge. Consequently, runtime detection and response solutions can prove invaluable in identifying anomalies and issuing alerts about malicious activities. Our runtime protection module on the Aqua Platform detected the Kinsing attack as illustrated in the screenshots below.

Figure 12: The attack timeline in the Aqua platform

Figure 13: Event description – Kinsing malware conducts direct communication to download the cryptominer

Figure 14: Drift Detection in the Aqua platform: The file kdevtmpfsi (a Monero cryptominer) is downloaded into the container