A Cross-platform Java
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2013-2465 | Unspecified Flaw in Oracle Java SE 2D Component Exploited in the Wild (CVE-2013-2465) CVE-2013-2465 is an unspecified vulnerability in the Java Runtime Environment (JRE) component of Oracle Java SE, located in the 2D graphics/rendering subsystem. It is triggered via unknown vectors related to 2D, typically when a hostile applet or application causes the JRE to process crafted graphical content. An attacker who successfully exploits it can affect confidentiality, integrity, and availability, which in practice means remote compromise of the affected system without user credentials. Any deployment of Oracle Java SE — end-user desktops with the browser plugin and servers running JRE releases current at the time of the June 2013 Oracle Critical Patch Update — is affected. Exploitation is confirmed in the wild: the flaw was added to CISA's Known Exploited Vulnerabilities catalog on 2022-03-28 with known ransomware use, EPSS assigns it a 98.7% probability of exploitation within 30 days (top percentile), and related 2013-era reporting around exploit kits such as LightsOut documents the era's heavy exploit-kit targeting of Java. Do: Apply the June 2013 Oracle Java SE Critical Patch Update, or any later supported Java SE release, per vendor instructions as CISA requires. Audit environments for legacy JRE installs and enabled Java browser plugin/applet support — especially on user-facing and internet-exposed legacy servers — and remove or upgrade them. Because CISA lists known ransomware use, prioritize patching external-facing and end-user systems. | — | 99% | KEV ransomware |
| masshundreds of millions of endpoints at the time of 2013 disclosure; today, a residual population of legacy Java deployments of unknown size |
Full article562 words · extracted from securelist.com · click to collapse
Early this year, we received a malicious Java application for analysis, which turned out to be a multi-platform bot capable of running on Windows, Mac OS and Linux. The bot was written entirely in Java. The attackers used vulnerability CVE-2013-2465 to infect users with the malware.
Initializing and decrypting strings
To make analyzing and detecting the malware more difficult, its developers used the Zelix Klassmaster obfuscator. In addition to obfuscating bytecode, Zelix encrypts string constants. Zelix generates a different key for each class – which means that in order to decrypt all the strings in the application, you have to analyze all the classes in order to find the decryption keys.
String initialization and decryption is implemented in the static initializer code (<clinit>).
Encrypted string initialization
The algorithm is as follows: take the current index of an encrypted character in the string, calculate the remainder from its division by 5 and choose the current key depending on the result. Next, identify the decrypted character by performing module 2 bitwise addition with the key selected.
String decryption
For a specific case, the decryption algorithm looks as follows:
Python implementation of the decryption algorithm
The launch
When launched, the bot copies itself into the user’s home directory and sets itself to run at system startup. Depending on the platform on which the bot has been launched, the following method is used for adding it to autostart programs:
- For Windows – HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun
- Mac OS – the standard Mac OS service launchd is used
- For Linux – /etc/init.d/
The bot’s body contains an encrypted configuration file for the launchd service.
Decrypted configuration file for the launchd service
After launching and setting itself to run at system startup, the bot needs to report this to its owners. To provide a means of identifying each bot, a unique bot identifier is generated on each user machine. The identifier is saved to the file jsuid.dat in the user’s home directory.
Contents of jsuid.dat
Controlling the bot
The bot is controlled via the IRC protocol. This leads us to one more curious feature of this malware – it uses the PircBot open framework to implement communication via IRC. The malware includes all the classes needed for the purpose.
After launching, the malware initiates connection to an IRC server.
Connecting to an IRC server
After successfully establishing a connection, the bot joins a predefined channel and waits for the attackers’ commands:
Joining an IRC channel
Main functionality
The bot is designed to conduct DDoS attacks from infected user machines.
The bot supports two flood types:
- HTTP
- UDP
Which attack type is to be used is specified by an attacker in the IRC channel for zombie machines. In addition, the following parameters are specified:
- Address of the computer to be attacked
- Port number
- Attack duration
- Number of threads to be used in the attack
Generating headers during an HTTP flood attack
The User-Agent value to be inserted into an HTTP request is selected randomly from a list stored in the bot’s body in encrypted form.
Decrypted list of User Agent values supported by the bot
When analyzing the malware, we detected an attempt to attack a bulk email service.
Command to launch an attack
Kaspersky Lab detects this malware as HEUR:Backdoor.Java.Agent.a.
We would like to thank Zoltan Balazs, CTO at MRG Effitas, for sharing a sample of the malware with us.
Text extracted automatically; images, tables and formatting may be missing. Original: https://securelist.com/a-cross-platform-java-bot/58227/