Log4Shell vulnerability continues to menace developers

The high-profile Log4Shell security vulnerability continues to go unpatched in a number of applications and modules.

That’s according to researchers at security company Rezilion, who analyzed Log4J code samples on the Maven Central code repository and found that 38% of the packages on the distribution site were still relying on vulnerable versions of the Java software package.

By downloading vulnerable versions of Log4j, developers are in turn exposing their applications to CVE-2021-44228, a remote code execution vulnerability related to the ability for remote attackers to run commands creating log entries.

The flaw, also referred to as Log4Shell, has been patched for months. Despite the availability of patched versions, however, many developers continue to be presented with older versions of the code library and in turn are leaving their applications vulnerable.

Yotam Perkal, director of vulnerability research at Rezilion, told SearchSecurity that the findings are particularly alarming given that Log4Shell is already under active attack, albeit in limited numbers.

"This means that organizations are still at risk, and that is why the China APT was not surprising," Perkal explained.

"It will not be surprising; we will see a few more of those in the near future."

While developers could help alleviate the risk by making sure they are using the latest version of the Log4j library, things are not as easy for administrators who rely on those apps. With so many open source projects likely using vulnerable versions of Log4j, many are likely to be still vulnerable without their customers realizing the danger.

In particular, Perkal said there some of the lesser-known applications that might not get the sort of care and attention of more popular applications. Such was the case in one recent real-world attack on Log4Shell.

"The application that was abused was something that is less known," he explained.

"It probably did not get as much attention, and I am sure there are other projects along those lines."

Things will get even more complex for closed-sourced projects and applications that rely on Log4J for certain functions. To that end, companies will need to internally check all their applications for possible instances of vulnerable Log4j installations.

This, of course, will be a particularly meticulous and time-consuming task, which could leave many enterprises vulnerable to attack for some time.

Companies also face danger from things like Docker containers, where vulnerable versions of Log4j can be bundled in, and updates can be slow to arrive as both the package and the container need to receive formal updates in order for the fix to be implemented.

"This is something that I am not sure everyone is aware of, but unless you keep actively monitoring, what you are doing is pulling vulnerable components into your environment," Perkal said.

"I am not sure everyone still actively monitors, it is like whack-a-mole."