The Takeaway

Log4j is a Java library used to do logging. It was recently found to have a vulnerability (CVE-2021-44228) that allows an attacker to take over your web server (or any device it runs on) and run commands from the device. Unfortunately, it is present in many, many applications and services all over the internet. This report explains how to verify if you have vulnerable versions of Log4j and, if so, reduce the risk while getting set to upgrade off it as soon as possible.

The Challenge

The security team for a financial services organization is looking for information on the Log4j vulnerability. Specifically, the team asks:

  • What exactly is impacted?
  • What are some ways to mitigate it, especially within custom applications?

Very Critical Issue

The Log4j Java logging dependency has a vulnerability in it that allows an attacker to take control of your web server (or any device it runs on) and run commands from your device. Attackers can run this attack before a login screen (unauthenticated).

This dependency is widely used by a large majority of vendors and software development shops. And because this vulnerability is widely available, the exploit difficulty level is nonexistent and the damage it can cause is absolute. It is not an understatement to say this is the most terrifying web application vulnerability of all time.

How To Find Log4j

Most organizations do not have an accurate and up-to-date application inventory—much less a current software bill of materials—meaning they have no idea if they have this library or not.

The first step is to go to your code repository or version control and search for “*log4J*”. Find out if you have code in more than one repo and, if so, search all of them. You may have your code stored all over the place. That’s OK. Just go through them one by one, make note of each place you have it, and which version of it (it should say in the name). Keep track, because different versions have different issues:

  • Versions 2.x (every single one except 2.15.x, which is the patch for this) are vulnerable.
  • Versions 1.x are only vulnerable if you call the JMSAppender functionality. You can look in your code for “JMSAppender” to see if you are calling it. If you are, you are vulnerable. If not, you’re good.

Verify with a Dependency Tracker or SCA

Once you have checked all your code, if possible, use a dependency tracking tool (such as the dependency graph and Dependabot from GitHub) or a software composition analysis (SCA) tool such as Snyk, OWASP Dependency Check/Track, WhiteSource, etc. It will tell you immediately if you have a problem and even give you instructions on what to do to fix it. This is an additional check.

If you are not vulnerable, relax on the custom software front. Save that energy for patching your noncustom apps and servers.

If Vulnerable Versions Sit Behind a CDN/WAF/RASP

Please note: If you are not on the security team and you are doing this activity, immediately inform the security team if you have found this vulnerable library.

It may seem obvious to say, “just patch,” but this is not a button-press problem. Upgrading this library is nontrivial and may even require rearchitecting your entire application. To reduce or eliminate the risk while you get ready to upgrade, take the following steps:

  1. Verify if the vulnerable code has been deployed. A surprising amount of code in your repository isn’t in production. If the code has not been deployed anywhere, mark it as “do not deploy” and move on.
  2. For anything that sits behind a web application firewall (WAF) or content delivery network (CDN), add the rules to block this attack. Cloudflare and Amazon CloudFront both can block this. Turn it on!
  3. If you have your own runtime application self-protection (RASP) or WAF, and there are no rules available yet from your vendor, tell them you want one now. If the rules are available, turn them on.
  4. If your WAF/RASP provider somehow does not have an available ruleset to block this, make your own (often called a “virtual patch”). There is regex available on the internet now to do this.

However, you must understand these are all temporary measures. You still need to:

  • Monitor to make sure it's working.
  • Upgrade the versions of Log4j as soon as possible.

If CDN, WAF or RASP Are Not an Option

You still have ways to protect your organization. They are much less appetizing though.

  • Option 1: Accept the risk, do nothing to block it, but speed the upgrade. You must still monitor the situation, but that is all. You will instead spend your efforts on releasing the upgraded version of your software as soon as possible. For some organizations, this is the only option. Ensure you test thoroughly; you don’t want to release patches like our industry saw during Meltdown/Spectre that broke the patched systems worse than the vulnerability would have.
  • Option 2: Shut off the vulnerable systems. Immediately. If your business can have a few systems down until you figure out how to do something better, this might present less risk. There are currently many systems all over the internet being turned off in the short term.
  • Option 3: Go through your code, remove this dependency and comment out the code that calls it. When you are ready to apply the upgrade/patch, you can add it back in and turn it back on. Stop logging, just for now. This is the only situation where I would ever recommend removing logging.

Get a Solid Game Plan in Place

You can do this, but you need to plan for and be aware of all the intricacies. Follow these key steps:

  • Find out if you have it. Search your repo and use SCA tools.
  • Block attacks if you can. Use a WAF/CDN to block directly or comment out the code and remove the dependency.
  • Plan your upgrade. It’s going to be a lot of work, but it’s the only 100% defense.

This is a widespread critical vulnerability. Act right now. Do not wait.

 

Any views or opinions presented in this document are solely those of the Faculty and do not necessarily represent the views and opinions of IANS. Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our written reports, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by the client in connection with such information, opinions, or advice.