Skip to content

Best Practices for Responding to the Log4j Vulnerability and Preparing for the Next

IT teams need to act now, not just to find and fix Log4Shell, but also to implement tools and processes to prepare for the next

Perspective

On Friday, December 10, 2021, the Apache Foundation announced a serious security vulnerability (CVE 2021-44228) in most versions of its open source Log4j utility, a popular logging utility that has been embedded in thousands — if not hundreds of thousands — software applications and services.

The Java Naming and Directory Interface (JNDI) API allows Java applications to look up data and resources from external directory services, including LDAP or DNS. An attacker can leverage the JNDI functionality and trigger a victim system to retrieve an external library from a server the attacker controls. Those commands could be used to install malware, erase data, exfiltrate data, copy credentials, or perform other malicious actions.

The implications are enormous. Thousands of software applications, including well-known commercial applications from some of the biggest names in enterprise software, are vulnerable to being hacked and used for malicious purposes.

The software is even found in everyday devices like TVs and store kiosks. Google estimates about 4% of the Maven Central Java repository, the most significant Java package repository around, is compromised by this vulnerability.

Attacks can be launched through web browsers, command lines and other types of inputs. One security researcher even suggested that presenting a carefully-crafted QR code to a store price-checking kiosk could give attackers control of the store’s IT systems.

For an in-depth look at understanding and mitigating Log4j threats, watch our recorded webinar. 

Security teams are racing to prevent Log4j attacks

Apache has issued patches to Log4j that fix this problem.

Now the race is on: Can IT security teams find all the instances of Log4j in all their software on all their endpoints before attackers take advantage of this vulnerability to launch attacks?

Attackers aren’t standing idly by. Within 72 hours of the vulnerability being announced, over 800,000 attacks on applications were launched. And the threat landscape is only getting worse.

Vulnerable Log4j software might be installed on any endpoint’s desk. Worse, it might also be present in backups and gold images, meaning that Log4j instances removed this month might reappear in the future when a system needs to be restored or new systems need to be provisioned.

The FTC expects companies to patch vulnerabilities or face regulatory penalties

Because the impact of the vulnerability is so sweeping, the U.S. Federal Trade Commission (FTC) stepped in. On January 4, 2022, it issued a statement, pointing out that Log4j jeopardized the protection of consumer data, and reminding companies that “the duty to take reasonable steps to mitigate known software vulnerabilities implicates laws including, among others, the Federal Trade Commission Act and the Gramm Leach Bliley Act.”

To ensure that no one mistakes the seriousness of its warning, the FTC cites its $700 million fine against Equifax in 2017 for that company’s failure to patch a known Apache Struts vulnerability. That lapse in patch management led to a data breach that eventually exposed the private information of 143 million consumers and tarnished the Equifax brand.

The FTC doesn’t see the Log4j as a unique occasion for regulatory scrutiny. Rather, it expects companies to discover and promptly mitigate similar risks in the future. The FTC couldn’t be more clear: “The FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.”

The bottom line for security teams: The tools and processes that IT security teams put in place now to address the Log4j vulnerability should be used continuously in the future to detect and mitigate similar risks.

An ongoing problem requires an ongoing solution

Even aside from the inevitability of other vulnerable software components, the work of cleaning up Log4j is going to require a long-term effort from IT teams. Here’s why.

First, over a month after the vulnerability was announced, over 40% of recent downloads of Log4J are versions still vulnerable to compromise. That’s 40% of over 10 million downloads, creating a lot of opportunities for attackers.

Second, scans of enterprise networks are finding not only recent, vulnerable versions of Log4j but also 1.x versions of the utility, which Apache officially declared end of life in August 2015. It’s also a sign that there are probably copies of Log4j lurking in unsuspected places across an enterprise.

Third, even if an IT team manages to find and remove all vulnerable instances of the JndiLookup.class in Log4j, they still need to be on the watch for vulnerable instances being restored from backups or golden images. They also need to worry about employees downloading vulnerable copies from the internet or third parties using vulnerable versions that end up creating opportunities for attackers to penetrate the network.

Beyond Log4j to continuous threat hunting

This ongoing practice is broader than just discovering and remediating Log4j vulnerabilities themselves. With the FTC committed to penalizing companies that leak data because of any vulnerabilities similar to Log4j, a major regulatory agency is signaling that longstanding lapses in patch management will no longer be tolerated. Failure could result in fines up to hundreds of millions of dollars.

IT teams need to act now, not just to find and fix Log4j vulnerabilities, but also to implement tools and processes for finding software component vulnerabilities generally. If six months from now, another open-source software component is found to contain a security flaw, security teams will need to respond quickly to detect and fix all instances of that component.

Organizations of all kinds need a fast, effective and comprehensive way of detecting vulnerable software components and remediating their threats. Simply running shell scripts to search for filenames won’t solve the problem.

Such scripts, while easy to write or download from a security site, will almost certainly miss software dependencies and embedded components. And worse, they’ll spike CPUs on critical systems across the network. IT security teams need to search quickly and thoroughly without crashing the systems being searched.

How Tanium can help

Tanium helps protect against the Log4j vulnerability with the only platform that provides complete, accurate and high-fidelity endpoint data trusted by the most demanding and complex organizations in the world.

The Tanium platform identifies vulnerable instances of Log4j.

  • Tanium Reveal identifies vulnerable instances, including those repackaged by third-party vendors, in just minutes.
  • Tanium Interact makes it easy to tag affected endpoints and initiate recovery plan workflows.

Tanium also detects signs of exploitation.

  • Tanium Threat Response detects incidents that indicate exploitation attempts across all endpoints. Use Threat Response to isolate endpoints that show evidence of compromise or other suspicious activity.

Tanium helps security teams remediate threats and harden endpoints against compromise.

  • Tanium Deploy automates software upgrades as soon as vendors release packages.
  • Tanium Interact makes it easy to apply systems’ variable hotfixes.

Tanium also reports on exposure to Log4j and other threats.

  • Tanium Comply reports on all endpoints for security configuration exposures and software vulnerabilities using live data.
  • Tanium Asset to create comprehensive reports of your online and offline assets as you identify and track vulnerable software versions.

In 94% of enterprises, endpoint management solutions are missing up to 20% of endpoints requiring protection. Tanium discovers these overlooked endpoints and provides a fast, workable solution for discovering and mitigating Log4j threats.


Tanium can help you determine if this vulnerability is impacting your environment. We’re offering capabilities to help organizations identify Log4j free of charge. Contact us today.

Melissa Bischoping

Melissa Bischoping is Director, Endpoint Security Research at Tanium. Presenter, author, and cyber SME, she offers guidance on attack behaviors and emerging threats.

Tanium Subscription Center

Get Tanium digests straight to your inbox, including the latest thought leadership, industry news and best practices for IT security and operations.

SUBSCRIBE NOW