A Summary of log4j Exploit in a Log4shell - What Happened and What You Can Do About It

December 21, 2021

By now everyone has likely come across the recent log4j exploit called "log4shell", recorded as CVE-2021-44228. Later, two more vulnerabilities were discovered, CVE-2021-45046 and CVE-2021-45105. We wanted to share our findings and recommended immediate remediation steps. We will update this post as new information becomes available.

Update History

Whenever we update information in this blog post you can find a summary of the changes here.

Date	Comment
2021-12-21	add note on patching live system
2021-12-21	add info about Cloud & CDN security services
2021-12-21	published public version
2021-12-15	add notes on 3rd party software remediation
2021-12-15	add info on new CVE-2021-45046

What happened and who is affected?

A vulnerability in the log4j-core Java library was found that allows Remote Code Execution (RCE) and/or extracting information from affected systems. It is considered one of the most serious bugs in recent software history. Every application using the log4j-core library directly or indirectly might be affected. Worse, the vulnerability seems to have been around for a few years(!).

Note: only log4j-core (i.e. the implementation of the log4j v2 logging engine) is affected. log4j-api is not affected.

Immediate Mitigation Steps

Upgrade every affected application to log4j v2.17.0 ASAP. (no, there's no way around it!)
- most other fixes previously circulated have been discredited
rotate all secrets after upgrading!
- Secrets used by the application may have been compromised
perform a clean slate redeployment of your services
- hackers might have already installed malicious software

If you can't upgrade & redeploy, there's a possibility to temporarily patch a running live system as documented by LunaSec here.

In a soon-to-follow-up post, we will describe a list of ways to upgrade applications.

Note: there are some other recommendations out there - only the first in the list below is still considered a valid remediation:

For releases from 2.0 to 2.10.0: you may want to remove the LDAP class from log4j completely by issuing the following command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
~~For version >=2.10: set log4j2.formatMsgNoLookups to true~~
For certain JVM Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as default setting

How to identify affected applications?

IMPORTANT: internal systems may be affected as well: Malicious data may be sent via messages or stored in a database and may trigger the exploit when this data is processed at a later point by such internal systems!

Own applications

use mvn dependency:tree | grep log4j-core to check if your application has log4j-core on its classpath. If so -> force an upgrade (e.g. using <dependencyManagement>)

3rd party applications

Here is a list of applications known to use log4j v2. Check with the vendors for patch releases.

Scan using APM tools like NewRelic

APM tools like NewRelic, AppDynamics, DynaTrace and Datadog support querying your applications' inventories.

In our case, a lot of our services integrate with NewRelic. There's a script that allows to use NewRelic to scan software for usages of log4j-core libraries. This is also a great help for monitoring progress of mitigation efforts.

Use Security Scanners to scan your systems

There are plenty security scanners out there. Use scanners like Nuclei or Burp Suite to scan your systems for vulnerabilities.

Additional Notes

Previously circulating superseded information

Previously at has been reported that some Java versions would be safe. A few other workarounds like setting environment variables to disable to problematic feature were suggested. All this information and workarounds have all been discredited in the meantime (see https://logging.apache.org/log4j/2.x/security.html)

log4j v1 is not affected

log4j v1 has a lot of other security holes, but incidently does NOT seem to be affected by log4shell.

Check entire JVM

Check any JVM agent you might be running and upgrade to a patched version. E.g. also NewRelic agent is affected and must be upgraded.

Logback is also affected, but low severity

logback is also affected but the exploit is much more difficult, hence the severity of logback's bug is not critical. Upgrade to v1.2.8 is still recommended though.

How the Attack works

Lunasec did a great job explaining the attack in detail in their blog post.

Next Steps

Identify successful attacks

Since the exploit is already around for a while, noone can be sure, whether systems had been successfully attacked in the past. We are currently triaging systems under the assumption that they have been exploited in the past. The good news is, that we can not identify any attacks prior to 2021-12-10 ~14h CEST.

Leverage Cloud and CDN Provider Security Services

Check for posts of your providers about using their security services to protect your applications

Review emergency procedures

This includes reviewing runbooks etc. to coordinate and improve your response to future attacks. A thorough post-mortem is highly recommended!

Swap log4j for slf4j+logback

At this point it is advisable to replace log4j with logback by leveraging slf4j's "bridge" components - it's effectively a drop-in replacement: http://www.slf4j.org/legacy.html