How Do I Find My Servers With the Log4j Vulnerability?

Question: How do I find servers in my organization that have the vulnerable Log4j component?

For enterprise IT and security teams tasked with updating Java applications containing the vulnerable Log4j, the difficult part is accurately assessing whether they have any affected applications in the first place. Any Java application using a version of Log4j before 2.14.1 has the vulnerability (CVE 2021 44228) -- and the fact that Java is so widely used in the enterprise means there is a very large attack surface. There are obvious places to look, such as Java applications and Web application frameworks such as Struts. But then there are less obvious usages, such as administrator consoles for hardware appliances.

Even if an organization is certain that Log4j is not officially used by its developers because they use a custom or alternative logging tool, it's still necessary to check and verify that is the case. Even with an official policy in place, some teams may have used Log4j independently on a specific project. This Tech Tip describes a tool that can help with this process.

Tools for Finding Systems
Several vendors have released different tools to help organizations find vulnerable applications and systems, such as one from Randori. Another interesting tool comes from Thinkst Canary. Users can create a DNS-based token on the CanaryToken interface, which they add into the jndi:ldap string. This string can be pasted into search boxes and fields that will potentially be parsed by logging libraries. If the system is vulnerable, the Canarytoken will email the vulnerable server’s hostname, the company says.

“We see this as a quick hack to help defenders through some pain," Thinkst Canary said on Twitter.

Another tool is ThreatMapper, an open source, cloud-native security observability platform from Deepfence, that hunts for vulnerabilities and ranks them based on the risk of exploitation at runtime. Security teams can see which workloads are affected by the vulnerability in Log4j, and which of those workloads are at the greatest risk of exploit. The list includes virtual machines and pods that are directly and indirectly exposed to the internet. Those are the systems security teams need to fix right now, says Deepfence.

"ThreatMapper helps organizations narrow down from potentially hundreds of nodes to be patched to a handful which might be one or two hops away from the Internet and need fixing immediately," says Sandeep Lahane, CEO of Deepfence.

Block the Traffic
One thing that organizations can do while they are investigating is to use the firewall rules to block suspicious egress traffic, says Casey Ellis, CEO of Bugcrowd. “When the first stage of Log4Shell is triggered, this triggers a lookup to an attacker-controlled server,” Ellis says. The lookup, which retrieves the second-stage Java payload or exfiltrates sensitive information, can use a variety of JDNI-supported protocols, including LDAP and DNS. Those are the protocols to pay attention to.

“Blocking systems with Log4J on them from egressing a network in this way mitigates retrieval of the second stage and limits the potential for data exfiltration via successful first-stage execution,” Ellis says. “We’ve seen both bounty hunters and malicious attackers using DNS as the preferred mechanism for data exfiltration, as DNS egress from a network is very rarely blocked. It is either allowed to pass through a firewall, or is passed forward by resolvers.”

There are very limited circumstances under which LDAP traffic should be leaving the network, so blocking this type of traffic ensures that attacks are blocked.