Amazon, Apple, Twitter, Minecraft, Cloudflare, Steam: This is only a very partial list of organizations affected by this vulnerability. The implications are far-reaching as Log4j is an extremely common logging library used in most Java applications, including business systems, to record log information. Less than 24 hours after this vulnerability was published, a crypto miner was already deployed to exploit this vulnerability.
Log4Shell was already being exploited for a few days before it became public knowledge. Log4shell scan attempts were detected up to two weeks in advance. Attackers could install crypto miners, create botnets, and steal sensitive data and system credentials. To date, it is estimated that over a million machines have been affected.
The first attacks and scans, which were still manual, are now being followed by automated attempts to exploit the vulnerability. After some experts cautiously speculated that the vulnerability had worm potential, reality is now catching up: Security experts have detected variants of the Mirai botnet drones that infect worm-like vulnerable servers and automatically spread further.
In the meantime, the highly active Conti extortion group has also jumped on the Log4j bandwagon and is using the vulnerability to penetrate servers and networks and set up their ransomware. Cybergang resells the accesses obtained in this way. Their business model is called ransomware-as-a-service.
The previous attempts at attack were probably mainly tests. But now it’s getting serious. Cybercrime and secret services use the gap for their own purposes.
Most of the attacks on the vulnerability are still general vulnerability scans. Their sheer number is already decreasing somewhat. But that doesn’t mean the all clear. The content delivery network specialist Akamai reports that their systems detect 250,000 attempted attacks on the CVE-2021-44228 vulnerability every hour. The company assumes that such attacks will accompany us for months to come.
How to fix Log4J RCE vulnerability?
The easiest and most recommended way to fix this vulnerability is to update to Log4J version 2.15.0 or later.
If the update is not possible for some reason or not possible at short notice, then you can mitigate the danger in the earlier versions 2.10.0 to 2.15.0 with the following system settings:
In addition, an environment variable can be set:
For releases from 2.0-beta9 to 2.10.0, removing the JndiLookup class from the classpath would be the solution. The command to perform such an action is:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
For more details, see the GitHub commit that fixes this vulnerability.