Critical new zero-day vulnerability in popular Log4j library discovered with evidence of mass scanning for affected applications
News broke early Friday morning of a serious zero-day remote code execution (RCE) Log4j exploit (CVE-2021-44228) the most popular Java logging framework used by Java software far and wide. The Log4j vulnerability is especially dangerous, as it can be used to run any code via your software and requires very low skills to pull off from an attacker. Log4j is near ubiquitous in Java applications, so immediate action is needed from software maintainers to patch.
This affects anyone using Log4j to perform logging, and anyone using software that uses Log4j, which is a large population of enterprise Java software currently available.
A similar vulnerability was used in the famous Equifax hack with devastating results. What makes this issue potentially more dangerous is the wide adoption of Log4j in most of the Java ecosystem.
We have released a dedicated Log4j updates page.
Please visit it for the latest statistics, updates, and resources for customers
- UPDATE 11.12 11:52UTC : Unlike mentioned in the video, it seems like JDK versions above 8 are affected. See below for up-to-date mitigation strategies. We have also updated the guidance for developers and operators.
- UPDATE 13.12 15:25 UTC: There is now strong evidence the JDK version does not matter and the only mitigation is to update log4j2 to 2.15.0. EDIT: This is now outdated
- UPDATE 14.12 12:06 UTC: There is evidence Log4j 1.x in certain circumstances can become vulnerable to another issue, CVE-2021-4104
- UPDATE 14.12 19:19 UTC: A new Log4j version, 2.16.0, was released. It is now the recommended remediation - see details below.
- UPDATE 17.12 14:36 UTC: A CVE has been discovered in Log4j 2.15.0 - CVE-2021-45046. All remediation activity should focus on updating log4j to 2.16.0
- UPDATE 17.12 22:00 UTC: We have released a dedicated Log4j resource center for customers & new Log4J 2.17.0 released
Log4j vulnerability explained
Early Friday morning GMT, a vulnerability Proof of Concept was published in a GitHub repository and made public.
It affects Apache Log4j between versions 2.0 and 2.14.1 and cannot be mitigated by updating the underlying JDK version. See below for current mitigation advice.
Coordinated with this release, Apache published a fix to the issue.
This is a low-skilled attack that is extremely simple to execute. It allows the attacker to run Arbitrary Code on any vulnerable application that is vulnerable and use this capability to execute an attack. Compared to the famous 2017 Struts2 CVE that led to the Equifax vulnerability this issue is potentially more far-reaching, as Log4j is a far more widely adopted component.
This vulnerability affects any application that uses Log4j for logging, which includes software such as Minecraft, where we've already seen evidence of the vulnerability being exploitable using the built-in chat functionality. It's widely adopted in the enterprise Java software ecosystem, meaning you'll need to also update all affected applications.
As with historical RCE attacks, within hours there is strong evidence the Log4j vulnerability is being mass scanned on the internet. This means immediate reactions are needed from all maintainers.
It only took less than two days for companies to be exploited with a similar vulnerability that occurred in 2017.
How do I know if I'm affected?
Sonatype has fast-tracked the vulnerability. If you scanned your software with Sonatype Lifecycle, you'll receive automatic security alerts as a part of your usual continuous monitoring.
You can also run a manual search on Sonatype Lifecycle to check if you've been affected by the Log4j exploit. You can use the following REST API call to the Sonatype IQ server to find the affected Log4j versions:
"http://localhost:8070/api/v2/search/component?stageId=release&componentIdentifier={"format":"maven","coordinates":{"groupId":"org.apache.logging.log4j","artifactId":"log4j-core","version":"*","extension":"*","classifier":"*"}}"
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.
How do I mitigate the issue?
Sonatype customers
We have published guidelines on how you can find and fix the Log4j exploit with the Sonatype platform. Please see the following page:
As a developer using Log4j
The fixed version for this issue is out and was released by Apache - the main recommendation is to upgrade Log4j to the latest 2.17.0 version immediately. It is available via Maven Central. There is also a backported release 2.12.2 which is also now available via Central.
It's important to note, the initial fix 2.15.0 is secure against CVE-2021-44228. It does however contain another CVE that was discovered, CVE-2021-45046 that can cause remote code execution in certain non-default configurations.
You can also apply a Maven enforcer rule courtesy of Gunnar Morlin of Red Hat to prevent vulnerable packages from being included.
As a user of software using Log4j
Apply patches to the software running Java as soon as they come out and plan to receive them as they are released over the coming days and hours. Expect there to be a large volume of urgent updates.
As an operator of software using Log4j
Other mitigation and monitoring strategies include the following:
-
According to different CERT reports, change the configuration in your software by setting the following: "log4j2.formatMsgNoLookups" -> true
-
SNORT rules:
-
If you're running workloads on Kubernetes you can experiment with a kubectl script to override the above setting in all your pods (Courtesy of Bruno Borges of Microsoft):
-
If you are using Docker you can use this approach to create Log4j mitigated Dockerfiles (courtesy of Lari Hotari of Datastax):
There is also an application courtesy of Lari Hotari of Datastax that has a deliberately affected application you can use to test mitigations: https://github.com/lhotari/log4shell-mitigation-tester
Are Sonatype applications affected?
Our software including Sonatype Lifecycle, Sonatype Repository Firewall, Sonatype Nexus Repository OSS, and Sonatype Nexus Repository in versions 2.x and 3.x are NOT affected by CVE-2021-44228.
We advise keeping your software upgraded to the latest version.
