Critical New 0-day Vulnerability in Popular Log4j Library Discovered with Evidence of Mass Scanning for Affected Applications
News broke early Friday morning of a serious 0-day Remote Code Execution exploit in log4j - CVE-2021-44228- the most popular java logging framework used by Java software far and wide. This type of 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 log4 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.
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 centre 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 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 this vulnerability is being mass scanned on the internet. This means immediate reactions are needed from all maintainers.
It only took less than 2 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 and if you have scanned your software with Nexus Lifecycle you'll receive automatic security alerts as a part of your usual continuous monitoring.
You can also run a manual search on Nexus Lifecycle to check if you're affected. You can use the following REST API call to Nexus IQ server to find the affected Log4j versions:
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
How do I mitigate the issue?
We have published guidelines on how you can Find and Fix Log4j with The Nexus 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.
Please see Apache Log4Js official security notes for up to date information.
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 is to change 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 Nexus Lifecycle, Nexus Firewall, Nexus Repository Manager OSS and Nexus Repository Manager Pro in versions 2.x and 3.x are NOT affected by CVE-2021-44228. Please visit this page for detailed information about our products.
As the situation is ever evolving, we are keeping the above help article up to date relating to CVE-2021-44228
We advise keeping your software upgraded at the latest version.