Four months ago, the remote code execution hole exposed in the Apache Log4j logging tool still had a wide range of potential victims.
Using the Shodan search engine, Rezilion discovered more than 90,000 Internet-exposed servers with a vulnerable version of the software in the recent period. A Rezilion report published this week highlighted the results of its research, which suggest additional data points that appear to support the firm’s conclusion.
According to iJAM, as of April 20, 2022, 36 percent of Log4j versions are actively downloaded from Maven Central Java. Similar to other well-known security flaws, despite four months, there is still a significant attack surface open to Log4Shell.
The Log4Shell vulnerability (CVE-2021-44228) was published by the Apache Foundation on December 9, 2021, along with an official patch, which Rezilion says is still not too common.
According to many security professionals, the vulnerability is one of the most dangerous to be revealed in recent memory. They have urged organizations to install the updated version as soon as possible. Despite the serious worries, only a few occurrences of the vulnerability being used in a large breach have occurred.
However, attackers may already have quietly exploited it.
Security experts have cited the widespread use of Java, as well as the complexity of finding it — Java files that contain the vulnerability might be deep inside apps.
According to Rezilion, one problem is that many people are unintentionally utilizing insecure versions of Log4j because they don’t have visibility into their software components.
The firm says that it’s possible to find exposed Log4j instances using Shodan and other tools. And some of these may not have been updated because the people responsible for patching them don’t know they’re using a vulnerable version.
Other opinions
According to Perkal, the 90,000 insecure servers discovered via a Shodan search included open-source components with outdated — and, therefore, potentially vulnerable.
“There are probably a lot of servers running these applications on internal networks and hence aren’t exposed on Shodan,” Perkal adds.
The most significant result is that many of the exposed open source components still contained many additional vulnerabilities that had nothing to do with Log4j.
That highlights the need for organizations to conduct ongoing software audits and patch management. It also underscores the critical importance of adopting an automated, proactive approach to security, which can help identify and remediate vulnerabilities quickly.
Many organizations are still facing a problem with detecting flaws because while Log4j is utilized for logging in to many apps, software providers don’t always disclose its usage.
Possible Solutions
Rezilion says that it’s possible to find exposed Log4j servers using Shodan and other tools. Still, some of these may not have been updated because the people responsible for patching them don’t know they’re using a vulnerable version.
It is expected there will be more attacks exploiting the flaw, even though there have been very few so far.