Late last week, the Log4J vulnerability, otherwise known as CVE-2021-44228, came out and it is a doozy. A flaw in Apache’s Log4j logging framework (version 2.14.1 or lower) allows remote code execution on systems running it. The vulnerability was announced on December 9, 2021. However, it appears the bad guys have found it first. According to CheckPoint, there are over 100 attempts to exploit the vulnerability every minute. This vulnerability is widespread and not something to take lightly.
According to Palo Alto, like many high severity RCE exploits, thus far, massive scanning activity for CVE-2021-44228 has begun on the internet with the intent of seeking out and exploiting unpatched systems. We highly recommend that organizations upgrade to the latest version (2.16.0) of Apache log4j 2 for all systems.
Check Point stated that at present, most of the attacks focus on the use of a cryptocurrency mining at the expense of the victims, however under the auspices of the noise more advanced attackers may act aggressively against quality targets. Since Friday we witnessed what looks like an evolutionary repression, with new variations of the original exploit being introduced rapidly- over 60 in less than 24 hours.
What can you do?
For starters, pay attention to your inbox. Software providers of impacted systems are actively sending mitigation and remediation steps.
Cloudflare has provided instructions on how to mitigate the issue here:
To mitigate the following options are available (see the advisory from Apache here):
- Upgrade to Log4j v2.15.0
- If you are using Log4j v2.10 or above, and cannot upgrade, then set the property:
Additionally, an environment variable can be set for these same affected versions:
- Or remove the JndiLookup class from the classpath. For example, you can run a command like
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class