You probably heard the news this weekend about the new critical remote code execution vulnerability affecting Apache log4j 2. A remote code execution vulnerability is an attack that can be launched from anywhere in the world, as long as an affected system is available remotely.

Why is important? The vulnerability affects millions of devices, including web applications, IOT devices, etc. This means both personal and corporate devices could be vulnerable.

What should you do?

  • Home – Look out for alerts from vendors that you purchased products from (e.g. Apple, Amazon, Google, etc.). If they recommend you update your devices, or if you are being prompted to, make sure to update them.
  • Office – You can also look out for alerts from vendors, but since there are so many more devices in the office setting, the easiest approach is to run a vulnerability scan or use one of the proof of concepts to test. (Another option in the office is a manual process and requires you taking an inventory of all the applications that have a web interface. Once identified, you can log in to each of them to determine if they are running Apache and Log4j.) Once the scan is complete and if anything is identified, determine if a patch is available by checking vendor websites, or take steps to limit exposure.

Some more specific things:

How can I detect it?

  • Take a manual inventory of all applications running a web server and determine if Apache is installed. Next determine if Log4j is also installed
  • Run a vulnerability scan using a commercial tool to determine if Log4j is present in the environment
  • You can download and run an open source vulnerability scanning tool called grype, which can be found here: https://github.com/anchore/grype

How can I remediate it?

There are a few ways to remediate:

  1. Wait for the vendor to release a patch. (the most simplest).
  2. Rely on your Intrusion Detection/Prevention provider to detect and block malicious traffic. This can also be done on certain firewalls.
  3. Download the latest Log4j mitigated version 2.15.0 from its download page
    1. If you can’t upgrade, follow steps below:
      1. If using version log4j2.x version >=2.10 and <= 2.14.1, this behavior can be mitigated by either setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
      2. If using version >=2.0-beta9 and <=2.10.0, mitigation is to remove log4j’s JndiLookup class from JVM’s classpath as under: 
        zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Need help with detection?

If this sounds to cumbersome or you don’t know where to start, we can help. Reach out now and find out how we can scan your environment for this vulnerability and help you remediate it.