Apache has released a new update for Log4j, version 2.16.0. While the previous release (2.15.0) removed the ability to resolve lookups, and addressed issues to mitigate CVE-2021-44228, this release disables JNDI by default and removes support for message lookups.

Please see the Cisco Talos site for updated and evolving coverage on Log4j

See Also: What Is Log4j and Why Security Alerts Matter to DevSecOps Teams

As developers, we are all waking up to find a newly discovered zero-day vulnerability (CVE-2021-44228) in the Apache Log4j library. If exploited, the vulnerability allows attackers to gain full control of affected servers and your application. Like many developers, you’re probably scrambling to figure out what systems are affected and how to fix or patch this vulnerability. (TALOS Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild)

And to make your job even more difficult, Log4j is so widely used that you may not even realize where in your systems it’s being used. Many think that this Log4j vulnerability only impacts your Java code. Unfortunately, this is not true. Log4j is a key component of many commercial and open-source solutions including Apache Solr, Apache Struts2, Apache Fink, Apache Druid, Apache Kafka, Elasticsearch, and many more.

Your challenge now is to contain the threat of exploitation as quickly as possible. There are a few key things you can do as a developer.

First, categorize your actions into three main environments:

  1. Development
  2. Test
  3. Production

Development is easy. Just make sure to locate all usage of Log4j 2.0-beta9 to 2.14.1 and upgrade to 2.16.0 Please refer to the Talos Log4J Threat Advisory for more information.

Your test environment is almost as simple. Just add the extra step of pushing the updated code to a test environment where your usual automated and manual testing can be executed.

Production is where it gets a little trickier. As I’m sure you’re already concerned about, these code changes could affect your systems and business. Some aspects to consider:

  1. How will any downtime affect your customers and your business? What workarounds can you quickly offer to mitigate this downtime?
  2. What is the effect of the fix? Do other systems integrate with this system? Does the affected system have an API that other systems call? Will the patch potentially cause cascading defects? You need adequate time to thoroughly test.
  3. What other systems in your organization might have this vulnerability? How can you track those down and test them?

Finding, fixing, and testing all the affected systems could take days. In the meantime, you need to protect yourself now. Luckily there are some readily-available solutions that can help. These solutions help find where the OSS vulnerability exists in your production environment as well as mitigate the risk of the exploitation until the vulnerable library can be upgraded. Options for immediate mitigation differ depending on your environment. One such solution is AppDynamics with Cisco Secure Application, which is integrated into AppDynamics Java APM agents.

Cisco Secure Application protects your production environment by:

  1. Identifying what libraries your code is actually using in runtime
  2. Detecting the vulnerabilities in those libraries
  3. Detecting attacks while monitoring runtime behavior
  4. Protecting systems with policy to block runtime exploit behavior

The first, most important action to take is to find out where this vulnerability is introducing risk into your production environment. Cisco Secure Application tracks all library usage and the accompanying vulnerabilities.

Figure 1 - Detect vulnerability
Figure 1 – Detect vulnerability

This remote code execution vulnerability allows the attacker to run any code in your application, which could result in any number of malicious runtime behaviors. One of the scariest of those is shell command execution that could allow for complete control of not only your application, but the underlying workload.

Cisco Secure Application will detect this shell command execution out of the box. It can also be configured to stop the command from executing as well as send events to your security team for further investigation.

Figure 2 - Detect and block attack
Figure 2 – Detect and block attack

However, this won’t remove all the risk, so ensure you have plans to fix this vulnerability as soon as possible. Review the details at Log4j’s security disclosure.

Find more information on how AppDynamics with Cisco Secure Application offers full-stack application security that can help protect you from this and other vulnerabilities.


Stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel


Michael Chenetz

Technical Marketing Engineer