Log4j Webinar Recap: What Your Scanner is Missing

Log4j continues to be a thorn in the side of security leaders, who have spent the last several months battling the recently discovered flaw in Apache’s Log4j software. In a recent webinar, Yotam Perkal, director of vulnerability research at Rezilion, said the implications of the bug are far-reaching and will likely be exploited for years to come.

Apache Log4j is an open source Java logging library used in millions of Java applications worldwide. It’s one of the most popular logging libraries for Java.

The Log4 vulnerability has actually been lurking since 2013 and exploits a specific functionality in the Log4j library, which allows the application owner to add context to the logs by adding certain variables to the log messages, Perkal said. By the time the actual logging takes place these variables are replaced by system data.

No Vulnerability Scanner is Perfect When It Comes to Detecting Log4j

As the exploit became more prevalent, Perkal and his team tested some vulnerability scanners, including some specifically aimed at uncovering Log4j.

All of the tools were developed “with good intentions, yet these tools are usually written in a rush and based on partial knowledge because the research progresses and you keep learning new things about the vulnerability,’’ Perkal noted. He and his team assumed that would impact the effectiveness of those tools and they wanted to validate that, as well as make people aware of any gaps they found.

The findings were eye-opening.

“We actually found that there were, indeed, various detection gaps in all of the tools that were tested,’’ which included also various open source vulnerability scanners.

There wasn’t a single scanner – either open source or commercial — that was able to detect all the instances of the vulnerable log project components, he said.  

Perkal and his team weren’t surprised by the results, since they assumed that they would identify detection gaps. They also assumed that not all vendors would be aware of them.

Once they made the findings public, “several vendors reached out … and they actually let us know that they have addressed some of the issues that we have raised,’’ Perkal said. “It was very nice to see that our findings were taken seriously and that a lot of the gaps have been addressed.”

This will help improve the overall security posture of many organizations that are relying on or have relied on these tools for detection, he said.

There are still gaps in scanning tools, Perkal adds, “but we are in a better place than we were before we published the research.” Log4j is such a pervasive bug, there are still many organizations with blindspots, he notes.

What Can Organizations Do To Protect Themselves from Log4j

There are three steps security teams should take, according to Perkal. First, identify all the vulnerable instances in your environment. If you’re using open source tools for detection, make sure they are kept current, he said.

Perkal reiterated that even though vendors have improved their detection capabilities, be mindful of their limitations and don’t trust them blindly.

Once a problem has been identified, it’s time to remediate vulnerable components. “You can actually remediate or upgrade to the latest Log4j version, which isn’t vulnerable.” But every Java environment is a bit different. For Java 8, for example, it’s version 2.17.1, for Java 6, it’s 2.3.2, and for Java 7, it’s 2.12.4, Perkal said.

“If you cannot remediate all instances, what cannot be patched needs to be mitigated.”

For example, if you have an application that cannot afford downtime or you’re using third-party software such as a container and are waiting on a vendor to release a patch, recognize that the container is vulnerable. “In this case, you need to make sure that you mitigate the risk until you are able to patch it.”

In terms of other approaches, AWS has developed is a tool that performs a process called hot patching, which identifies running Java processes and injects a Java agent that intercepts the vulnerable class, he said. This can be done when a patch cannot be applied.

You can also buy yourself time when a piece of vulnerable third-party code is discovered by removing the vulnerability class from the Java binary, he said.

Log4j Implications in the Future

Even with all the attention and coverage being paid to the Log4j vulnerability, Perkal said there are still people who haven’t heard of it and it is likely that some systems “will remain unpatched for years to come.”

This is because there is both a lack of proper patch management programs in certain organizations and also an inherent fear of upgrading legacy systems. There may also be “a basic lack of visibility into proprietary systems or third-party systems, so all of these facts combined means that we’ll probably be hearing about [Log4j] in the future.”

We will continue to see a lot of focus around supply chain security and open source security best practices in general,’’ because attackers will keep trying to compromise the software supply chain, Perkal said.

Now, with the Biden Administration’s executive order about the importance of improving security standards, he stresses that organizations should create a proper Software Bill of Materials (SBOM). That way, when vulnerabilities like Log4j are discovered and need to be patched, there will be better processes in place, and “we’ll be more prepared.”

Watch the full webcast, Log4j: What’s Your Scanner Missing, on-demand or read the research, Log4j Blindspots.