Log4j Vulnerabilities Are Here to Stay — Are You Prepared?

The widespread vulnerability that first appeared in Apache Log4j in 2021 will continue to be exploited, potentially even in worse ways than we’ve seen to date. The more worrisome aspect of these threats is that there’s a good chance they’ll continue to be exploited months or years into the future.

The Department of Homeland Security’s Cyber Safety Review board debuted in 2021, and in 2022 released its inaugural safety report (PDF). In it, the board called Log4j an “endemic vulnerability,” chiefly because there isn’t a comprehensive “customer list” for Log4j, making keeping up with vulnerabilities a near-impossible task. One federal Cabinet department even spent 33,000 hours on its Log4j response.

And many organizations and security solutions on the market fail to identify the difference between exploitability and vulnerability — leaving an opportunity for attackers to carry out malicious activity.

Exploitability vs. Vulnerability

One of the key issues with cybersecurity today is understanding the difference between vulnerabilities and their severity. When it comes to measuring exploitability versus a vulnerability, there’s a big difference between whether a security threat is exploitable within your business or if it’s just “vulnerable” and cannot hinder the business or reach a critical asset. Security teams spend too much time not understanding the difference between the two and fix each vulnerability as it comes, instead of prioritizing those that are exploitable.

Every company has thousands of common vulnerabilities and exposures (CVEs), many of which score high on the Common Vulnerability Scoring System (CVSS), so it’s impossible to fix them all. To combat this, the hope is that risk-based vulnerability management (RBVM) tools will make prioritization easier by clarifying what is exploitable.

However, security prioritization approaches that combine CVSS scores with RBVM threat intel don’t provide optimal results. Even after filtering and looking just at what is exploitable in the wild, security teams still have too much to handle because the list is long and unmanageable. And just because a CVE doesn’t have an exploit today doesn’t mean that it won’t have one next week.

In response, companies have been adding predictive risk AI, which can help users understand if a CVE might be exploited in the future. This still isn’t enough and leads to too many issues to fix. Thousands of vulnerabilities will still show to have an exploit, but many will have other sets of conditions that have to be met to actually exploit the problem.

For example, with Log4j, the following parameters need to be identified:

• Does the vulnerable Log4j library exist?
• Is it loaded by a running Java application?
• Is the JNDI lookup enabled?
• Is Java listening to remote connections, and is there a connection for other machines?

If the conditions and parameters aren’t met, the vulnerability isn’t critical and shouldn’t be prioritized. And even if a vulnerability could be exploitable on a machine, so what? Is that machine extremely critical, or maybe it isn’t connected to any critical or sensitive assets?

It’s also possible the machine isn’t important yet it can enable an attacker to continue toward critical assets in stealthier ways. In other words, context is key — is this vulnerability on a potential attack path to the critical asset? Is it enough to cut off a vulnerability at a chokepoint (an intersection of multiple attack paths) to stop the attack path from reaching a critical asset?

Security teams hate vulnerability processes and their solutions, because there are more and more vulnerabilities — nobody can ever fully wipe the slate clean. But if they can focus on what can create damage to a critical asset, they can have a better understanding of where to start.

Combating Log4j Vulnerabilities

The good news is that proper vulnerability management can help reduce and fix the exposure to Log4j-centric attacks by identifying where the risk of potential exploitation exists.

Vulnerability management is an important aspect of cybersecurity and is necessary for ensuring the security and integrity of systems and data. However, it’s not a perfect process and vulnerabilities can still be present in systems despite best efforts to identify and mitigate them. It’s important to regularly review and update vulnerability management processes and strategies to ensure that they are effective and that vulnerabilities are being addressed in a timely manner.

The focus of vulnerability management should not only be on the vulnerabilities themselves, but also on the potential risk of exploitation. It is important to identify the points where an attacker may have gained access to the network, as well as the paths they may take to compromise critical assets. The most efficient and cost-effective way to mitigate the risks of a particular vulnerability is to identify the connections between vulnerabilities, misconfigurations, and user behavior that could be exploited by an attacker, and to proactively address these issues before the vulnerability is exploited. This can help to disrupt the attack and prevent damage to the system.

You should also do the following:

• Patch: Identify all your products that are vulnerable to Log4j. This can be done manually or by using open source scanners. If a relevant patch is released for one of your vulnerable products, patch the system ASAP.
• Workaround: On Log4j versions 2.10.0 and above, in the Java CMD line, set the following: log4j2.formatMsgNoLookups=true
• Block: If possible, add a rule to your Web application firewall to block: “jndi:”

Perfect security is an unachievable feat, so there’s no sense making perfect the enemy of good. Instead, focus on prioritizing and locking down potential attack paths that continuously improve security posture. Identifying and being realistic about what actually is vulnerable versus what is exploitable can help do this, since it will allow the ability to strategically funnel resources toward critical areas that matter the most.