Monday, December 13th, 2021
CVE-2021-44228: Apache Log4j Vulnerability
On Thursday, 9th December the Apache Foundation released an emergency update for a critical zero-day vulnerability in Log4j. Log4j is Java based logging tool used in servers and services all over the world. It is used by many companies including Apple, Amazon, Cloudflare, various Apache server types.
The critical vulnerability has been named Log4Shell and has received the identifier CVE-2021-44228. Log4j versions 2.15.0 and prior are subject to the vulnerability. CVE-2021-44228, received a CVSS severity score of 10.0, which is the maximum and is widely believed to be easy to exploit.
Many cybersecurity researchers have warned that hundreds of thousands of attempts to remotely execute code using the Log4j vulnerability have been detected in only a few days.
Since its discovery, Log4Shell has been exploited to release AWS keys, set up coin miners, and install remote access tools including Cobalt Strike to victims environments.
The impact of this vulnerability is huge and the speed at which attackers are using it is set to cause a disrupt to the cybersecurity sector over the coming weeks.
Apache Log4j 2.x <= 2.15.0-rc1
- Apache Struts
- Apache Solr
- Apache Druid
- Apache Flink
- Apache Dubbo
How it’s exploited in the wild
We have seen instances of payloads including cryptominers like Golang-based Kinsing ELF payloads, however this is only the beginning of it. This has the potential to scale massively as attackers ramp up their infrastructure to take advantage of this exploitation opportunity.
What happens now?
The CVE-2021-44228 vulnerability is still being actively investigated in order to properly identify the full scope severity. As 0-day vulnerabilities go this has an extremely high rating, meaning that attackers can remotely exploit it without any input from the victim and without high-level technical expertise. Furthermore, finding Log4j is a challenge as the way that Java packaging works, it is very possible that you could have Log4j hiding somewhere in your application and not know about it.
- Upgrade log4j 2 to the latest version, specifically log4j-2.15.0-rc2 or newer.
- According to Apache’s guidance, in releases >=2.10, this behavior can be mitigated by setting either the system property
log4j2.formatMsgNoLookupsor the environment variable
LOG4J_FORMAT_MSG_NO_LOOKUPSto true. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.