Over the last week, cybersecurity experts and developers around the world have scrambled to understand and mitigate a frightening zero-day vulnerability in a popular Java library. The scope and severity of the Log4j vulnerability are both alarming.
Fortunately, teams have been quick to respond with patches to resolve the issue. Unfortunately, due to the type of vulnerability and the ubiquity of the library, implementing these patches is not as simple.
In this blog, we’ll explain what happened, how you can mitigate the situation, and provide you with some resources to help you get started protecting your system.
What Happened?
Log4j is a popular Java logging library that’s used in multiple parts of the Java ecosystem to let developers record activity within their software. Version 2 of Log4j has support for many features, although some of them are combined together in dangerous ways.
The new exploit — commonly called Log4Shell and officially named CVE-2021-44228 — allows attackers to insert code into a log message that manipulates Log4j’s functions within your system. Because modern applications often log untrustworthy data (such as the contents of an HTTP request), there are many ways for an untrustworthy attacker to leverage this vulnerability. And because Java is embedded throughout the entire ecosystem — from your smartphone to the basic infrastructure that supports the public Internet — this vulnerability can have devastating consequences.
Since the vulnerability existed in the default configuration of Log4j, it has affected many organizations, even those who were taking all reasonable precautions against known issues. As a “zero-day” vulnerability, the existence of the problem was unknown before its public disclosure.
Teams have been quick to act, and the mature players in the industry are all actively protecting against this flaw. Your system will need to incorporate any fixes to your third-party providers, and in many cases, your team also will need to respond to protect against the vulnerability in your own codebase.
Should I Worry and How Can I Mitigate This Situation?
Yes, you should worry about this vulnerability as it’s an extremely serious problem. Many groups are actively exploiting it, and if you have vulnerable systems on the public Internet, they may already be compromised.
At the time of writing, the most sure way to avoid these vulnerabilities is to ensure that Log4j cannot use JNDI and does not perform message lookups. The Log4j configuration in version 2.16.0 has defaults which mitigate the problem by disabling both JNDI and message lookups.
You should continue to check third-party software you are running for critical updates, as vendors across the world have been working to patch this vulnerability since its announcement.
Tools like log4j-detector may help monitor systems for attempted exploits. However, this is a fundamentally reactive strategy: once the alarm trips, the horse may already be out of the barn.
For software that is written or maintained in-house, refer to the Log4j Security reference page, which provides details of affected versions and detailed mitigations. It has important information for those implementing fixes, including warnings about some occasionally suggested mitigations that are not sufficient to fix the entire problem.
Have Questions or Concerns?
Reach out. We can help determine if you’re affected, assess your risk, and walk you through mitigation options.
