How to Protect Against Log4j CVE-2021-44228 RCE Vulnerability

Update (Dec 29th 2021 - 02:20 UTC): A new vulnerability with a moderate severity was identified and assigned CVE-2021-44832. Apache has released v2.17.1 to mitigate this. The bug requires attacker to control configuration for any effect. If, as part of mitigation, you have removed the JNDI class altogether from log4j JARs, you are already protected.

Update (Dec 24th 2021 - 03:00 UTC): The Amazon Corretto team released a hotpatch for Apache log4j on 12th Dec 2021. A tool that injects an agent into a running JVM to patch JNDI lookups. Tool is available for Ubuntu, Debian and Amazon Linux.

Update (Dec 20th 2021 - 12:30 UTC): We are releasing an updated one pager. This has added information about CVE-2021-45105 and CVE-2021-45046. Please share this with your customers, internal teams and other stakeholders.

Update (Dec 20th 2021 - 12:00 UTC): Screamingfrog releases version 16.0 of the SEO Spider product on 14th December 2021 to mitigate the Log4j CVE-2021-44228 vulnerability

Update (Dec 20th 2021 - 12:00 UTC): Link-Assistant support replies to a question about whether their product is vulnerable to the Log4j CVE-2021-44228 vulnerability. The product does not use any log4j components so its not vulnerable.

Update (Dec 18th 2021 - 14:00 UTC): Apache Log4j2 v2.17.0 released to fix a Denial of Service vulnerability. CVE-2021-45105 has been assigned. v2.16.0 did not fix a recursive self referential lookup under special configurations.

Update (Dec 16th 2021 - 16:00 UTC): Incomplete fix for CVE-2021-44228 results in a DoS condition under special configurations. Assigned CVE-2021-45046. Must upgrade log4j to 2.16.0

‍Update (Dec 15th 2021 - 10:55 UTC): Apache Pulsar released PR 13226 updating log4j version to 2.15.0. No new release since 2.8.1. Fix will release as part of Pulsar 2.8.2, 2.7.4 and 2.9.1

Update (Dec 15th 2021 - 08:30 UTC): OpenIdentityPlatform OpenAM v14.6.4 not vulnerable as it uses log4j 1.x over SLF4J without the JMSAppender

Update (Dec 15th 2021 - 07:40 UTC): Apache Airflow not vulnerable, does not use log4j, logging via python

Update (Dec 15th 2021 - 05:40 UTC): Amazon Machine Linux 1&2 not vulnerable - Added issue to CISA Gov Github page

Update (Dec 14th 2021 - 08:10 UTC): Elasticsearch and Elastic cloud users who are on versions older than 7.2 should restart their deployments for the updated setting to be picked up

Update (Dec 14th 2021 - 07:58 UTC): Elasticsearch announcement (ESA-2021-31), Elasticsearch 5 is susceptible to both RCE and info leak via DNS. For versions 5.6.11 - 5.6.16 the vulnerability can be mitigated by setting the Dlog4j2.formatMsgNoLookups=true JVM option in JAVA_TOOL_OPTIONS env var or by setting system property

Update (Dec 14th 2021 - 06:00 UTC): You can download a short one pager to share with your customers, internal teams and other stakeholders using this link.

Update (Dec 13th 2021 - 18:00 UTC): Log4j v2.16.0 released. CVE-2021-44228 fixed. Disables access to JNDI by default.

What is Apache Log4j?

Apache Log4j is an open-source Java package. It is the most widely used default logging package.

Affected users include Apple iCloud, AWS, Google, Cloudflare, most of the financial services world, among others.

What can go wrong

Many many things can go wrong. Attackers may execute their own code in your server, remotely over the network, without any permission! If not code, they can scoop up all the server secrets that are in the server memory.

Why should you care

1. Log4j is one of the most widely used component for Java and Java VM based applications.

2. Log4j maybe used directly in code or in another component. So there is no easy way to figure out if you are using it in production.

3. If it is being used, attacking it just requires a simple HTTP request. This is why it is rated at severity 10!!!

4. Are you absolutely sure your organization doesn’t use Java/JVM? This includes applications & System libs as well

You have convinced me, what do I do next?

1. Ask your SaaS vendors if they are impacted and what are they doing about it?

2. Talk to team leads/developers if they use any software that requires Java to be installed

3. Read updates from cloud service providers on how they are patching and if there is something you need to do

4. Share this one-pager with everyone who should understand the gravity of the current situation

5. Talk to riyaz@kloudle.com if want to see a demonstration of how simple it is to attack and steal data

CVE-2021-44228 log4j Exploitation in Action

A demonstration of a reverse shell on AWS cloud by exploiting CVE-2021-44228 (log4j2 RCE) vulnerability.

https://youtu.be/dguVlEpPFgg