Log4j Attack Surface Remains Massive

Attackers who want to exploit the critical remote code execution vulnerability disclosed in the Apache Log4j logging tool over four months ago still have a vast array of targets to go after.

In a recent scan using the Shodan search engine, Rezilion found more than 90,000 Internet-exposed servers containing a vulnerable version of the software. The security vendor believes the number represents only a small fraction of available attacker targets because it only considers publicly facing servers running open source software. If internal network servers and servers running proprietary applications are factored in, the total number of vulnerable targets is likely much higher, Rezilion said.

A Rezilion report this week that summarized the results of its study pointed to other data points that appear to bolster the company’s conclusion.

Among them is data from a Google open source scanning service called Open Source Insights, which showed that just 7,140 Java packages out of a total of 17,840 affected packages have been patched for Log4Shell since the flaw was disclosed. Another data point from Sonatype found that as of Apr. 20, 2022, some 36% of Log4j versions being actively downloaded from the Maven Central Java application repository were still vulnerable to Log4Shell — a number that has remained largely unchanged since February.

“Similar to other historic high-profile vulnerabilities, even though four months have passed, there is still a huge attack surface that is vulnerable to Log4Shell,” says Yotam Perkal, director of vulnerability research at Rezilion. “The 90,000 publicly accessible vulnerable servers are probably only the tip of the iceberg in terms of actual vulnerable attack surface.”

The Apache Foundation disclosed the Log4Shell vulnerability (CVE-2021-44228) along with an updated and fixed version of the software on Dec. 9, 2021. The flaw is present in virtually every Java application environment, is considered trivially easy to exploit, and gives attackers a way to gain complete control over vulnerable systems. Many security experts consider the flaw to be one of the most dangerous to be disclosed in recent memory, and they have urged organizations to install the updated and fixed version of the software as soon as possible.

Despite the high concerns, there have been very few publicly reported instances of the flaw being exploited in a major breach. However, there are considerable fears that in many cases attackers may have already quietly exploited the flaw to gain access to enterprise networks and are waiting for an opportune moment to strike.

Security experts have pointed to the ubiquity of the flaw and the difficulty involved in detecting it — Java files containing the flaw can sometimes be buried deep inside applications — as potential reasons for the slow remediation pace so far.

Rezilion said one issue is that many people are unwittingly using software that relies on vulnerable versions of Log4j either because they don’t have visibility into their software components or are using vulnerable third-party software. The Log4j flaw has also proven to be challenging to detect in production environments.

Tip of the Iceberg?
Perkal says that the 90,000 vulnerable servers that Rezilion found via a Shodan search contained open source components with obsolete — and therefore potentially vulnerable — versions of Log4j; components with up-to-date Log4j versions that contained evidence of use of previous, potential vulnerable versions; and public-facing Minecraft servers with vulnerable Log4j versions.

“There are probably a lot of servers running these applications on internal networks and hence not visible publicly through Shodan,” Perkal says. “We must assume that there are also proprietary applications as well as commercial products still running vulnerable versions of Log4j.”

Significantly, all the exposed open source components contained a significant number of additional vulnerabilities that were unrelated to Log4j. On average, half of the vulnerabilities were disclosed prior to 2020 but were still present in the “latest” version of the open source components, he says. Rezilion’s analysis showed that in many cases when open source components were patched, it took more than 100 days for the patched version to become available via platforms like Docker Hub.

Nicolai Thorndahl, head of professional services at Logpoint, says flaw detection continues to be a challenge for many organizations because while Log4j is used for logging in many applications, the providers of software don’t always disclose its presence in software notes. “So, many companies don’t actually know if it is being used in their system or not,” Thorndahl says.

Often, many applications are using old versions of Log4j that are no longer being supported and are vulnerable. “Very few, if any, companies have a [configuration management database] so detailed that it would show where they are using Log4j,” he says.

Thorndahl expects there will be more attacks exploiting the flaw, even though there have been very few so far.

“Most likely what we will see down the line, maybe four months, maybe a year, as we have seen before, is that incidents will be disclosed [where] companies detected they have been breached and the Log4j vulnerability was used and they probably had access for a long period of time,” he says.