Log4j is so widely used that you may not even realize where in your systems it’s being used.

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.

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.15.0, which has the fix for this vulnerability. Update the library in your project and recompile. If updating the library requires any refactoring of your application that will take too long, you can buy some time by changing the runtime environment to prevent exploits from working.

• In releases >=2.10, the vulnerable behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

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.

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.

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.

References

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel

Share: