‘Less obvious’ uses of Log4j pose a major risk

Log4Shell, the Apache Log4j vulnerability that has sent every security team scrambling since its disclosure on Thursday, brings massive cybersecurity risk because the flaw is so easy to exploit and the usage of Log4j is widespread in software. But the wide deployment of Log4j, on its own, is not why the Log4Shell flaw is so troubling. The most concerning part may be the fact that much of Log4j’s usage is essentially buried, making it extraordinarily difficult to detect and fix.

Log4j is an open source logging library that is often packaged in with other pieces of software to make those additional pieces work. But in many cases, there’s no real or obvious boundaries between Log4j and the pieces of software it powers, said John Hammond, senior security researcher at Huntress.

“Log4j is versatile and makes up an important foundational block for lots of software — and it’s those less obvious pieces that make this such a troublesome situation,” Hammond said. “The way that Log4j is packaged up with other software or programs makes it harder to spot which applications may potentially be vulnerable.”

Hard to detect

Research from Snyk has found that among Java applications using Log4j, 60% use the logging library “indirectly” — meaning that they use a Java framework that contains Log4j rather than directly using Log4j itself.

“That does indeed make it harder to detect that you’re using it — and harder to remediate,” said Guy Podjarny, cofounder and president of Snyk.

The Log4Shell vulnerability impacts a broad swath of enterprise software and cloud services, and many applications written in Java are potentially vulnerable. The remote code execution (RCE) vulnerability can ultimately enable an attacker to remotely access and control devices. Researchers have disclosed exploits so far including deployment of malware and installation of Cobalt Strike, a popular tool with cybercriminals that is often seen as a precursor to deploying ransomware.

Hiding in code

Internal research from Wiz suggests that more than 89% of all environments have vulnerable Log4j libraries, according to Wiz cofounder and chief technology officer Ami Luttwak. And “in many of them, the dev teams are sure they have zero exposure — and are surprised to find out that some third-party component is actually built using Java,” Luttwak said.

Dor Dali, director of information security at Vulcan Cyber, agreed that the widespread adoption of Log4j “makes it likely that it is hiding in a lot of code.”

While not unique to the Log4j situation, “developers not fully knowing what software they are running” is an issue likely to be exposed again by this vulnerability, Dali said.

The whole objective of development libraries, of course, is to make a developer’s life easier by reducing the repetitive tasks and providing some abstraction, said Vitor Ventura, senior security researcher at Cisco Talos.

However, in this situation, “it is perfectly feasible that the developer doesn’t know that Log4j is being used on some of the components they are using, whether it is a library or an application server,” Ventura said.

Fix what you know

Casey Ellis, founder and chief technology officer at Bugcrowd, said that during the initial phases of responding to the vulnerability, “it’s important to focus on what you ‘do’ know and ‘can’ fix first.”

“But organizations — especially larger ones — would be wise to operate on the assumption that they have unknown vulnerable Log4j in their environment, and make plans to mitigate the risks created by these as well,” Ellis said.

Controls that can help reduce the risk posed by “shadow” Log4j include blocking known malicious Log4Shell attempts using web application firewall (WAF) technology and other similar filtering technology, as well as egress filtering of outbound connections at the firewall and internal DNS, according to Ellis.

Inbound filtering will deal with the noise and limit the ability of a casual attacker to land an exploit on an unknown Log4j instance, and egress filtering will limit the impact of data exfiltration — or retrieval of a second-stage payload — should an attacker be successful against a vulnerable instance, he said.

Layered defense

Davis McCarthy, principal security researcher at Valtix, said businesses should stick to the principles of layered defense and assume that it’s not “if” but “when” you get hacked.

Along with WAF technology, another approach for “virtual patching” can include implementing an intrusion prevention system (IPS), McCarthy said. Businesses should also enable workload segmentation and traffic filtering to ensure that only allowed connections happen to and from their applications, he said.

“It often takes weeks or longer to patch a vulnerability like this, and we haven’t necessarily seen the worst of it,” McCarthy said.

In a world where vendors “don’t report or aren’t even aware of all the software used in their solutions, defenders must fall back to detection and response,” said Rick Holland, chief information security officer at Digital Shadows. Zero-trust principles of network segmentation, monitoring, and least privilege are the controls that defenders must leverage to minimize these risks, Holland said.

Software Bill of Materials

Longer-term, businesses should collectively pressure vendors to provide a Software Bill of Materials (SBOM), which details all the components in a piece of software, Holland said.

SBOMs would help in a situation like this because they would show all of the transitive dependencies of an application, along with the original open source library that was purposefully brought into the app, said Brian Fox, chief technology officer at Sonatype.

Ultimately, “if you’re not paying attention to your transitive dependencies, you’re not really protecting yourself fully,” Fox said. “This is a fixable thing though. With the right tools, and automation in place, companies and vendors can stay on top of this. And it all starts with a software bill of materials for every single application in your organization.”