Reports reveal ‘Long’ road for those looking for Log4J

Nearly five months after the announcement of a major vulnerability in the Java-based logging platform Log4J, two reports show that Web servers and applications—thousands of them, in fact—are still exposed to Log4J-specific exploits.

While patches and technologies exist to secure instances of Log4J, the exposed servers and applications—demonstrated in research from the Israel-based, cloud-protection provider Rezilion and the Sunnyvale, California-based API platform developer Cequence Security—suggest that organizations need better tools, policies, and even “bills” to look inside their applications for vulnerable code.

The reports

As if Log4J needed another letter, a team at Cequence Security found a “Long4J” flaw—one that takes hours to find. Cequence researchers discovered that application logs—and malicious API requests placed within them—can be sent to an unpatched third-party logging service.

Cequence Security’s self-proclaimed “hacker in residence” Jason Kent tested for unpatched Log4J instances by sending API requests containing a DNS lookup request. A vulnerable application carries out that DNS query and resolves the malicious domain.

“We assumed that this was like a five-minute thing,” said Kent. “But what we didn’t realize is that log that we generated, when we made that test, gets then sent to some logging, third-party service, maybe doing analytics, maybe just storage for [the] long term, and they have a vulnerable component in it.”

“And 24 hours later, we see their call come back to us,” Kent told IT Brew.

Hence, the long in Long4J.

In one example from the May findings, an application made calls to “a popular third-party log-analysis cloud service” which still had an unpatched Log4J component. The Cequence researchers found unpatched servers that appeared about 15 hours (not 24) after the initial test results were received.

In a separate April report, a team from Rezilion used tools like Shodan.io, a search engine for internet-connected devices, and dive, an open-source tool for exploring docker container images, to identify more than 90,000 internet-facing applications and more than 68,000 servers open to Log4J exploits.

And that’s just the tip of the Log4J-berg, according to Yotam Perkal, Rezilion’s director of vulnerability research.

“These are only applications that I’m able to see using Shodan that are internet-facing,” Perkal told IT Brew. “There are probably some on internal networks and commercial projects that I don’t have the capability to examine.”

MORE Letters?! Log4J sBOM?!

While the Log4J vulnerability was widely reported in December 2021, and Apache issued a patch shortly after the discovery of the flaw, addressing the problem isn’t as simple as applying the fix. Organizations may depend on software components that they do not directly control, and may not know where to patch.

“You could potentially still be using vulnerable software without knowing it,” said Perkal. “So if you don’t know it’s there, you can’t patch it.”

Tools like log4j-scan, log4j-sniffer, and check-log4j can determine if a Log4J library resides within a host.

If you have a good inventory of your apps and can trace all application components, you’re “at the head of the class,” according to Terry Jost, managing director of security and privacy at the consulting firm Protiviti. The only problem, said Jost: “Almost no one has that.”

For companies at the bottom of the class, Jost said he sees value—and visibility—in a software bill of materials. An sBOM provides details of an entire codebase, including open-source components or out-of-date versions of Log4J.

“The bill of materials is probably something that we should just look at mandating across the industry,” said Jost.

A software bill of materials, according to Kent, addresses a main priority for security managers.

“This goes to step one of every security program: Know what you have,” Kent told IT Brew. “If you don’t have that bill of materials...You’re looking.”–BH