“It is by far the single biggest, most critical vulnerability ever.”

• Amit Yoran

Exploitability is the only thing that matters

Two years ago, CVE-2021-44228 sent the security industry into a panic. The vulnerability, better known as Log4Shell, had security professionals working overtime through the holidays hunting down vulnerable log4j libraries. At the time, there was fear and confusion around what software was affected, which were exploitable, and where attackers would attack next.

The reality was that – at the time – very few products using the vulnerable log4j libraries were remotely exploitable for code execution. Two years after disclosure, we believe the following list is the majority of products that were remotely exploitable using Log4Shell (we left off Minecraft, because it’s a game, and a few lesser known products that we couldn’t confirm code execution against):

• Apache Druid
• Apache James
• Apache JSPWiki
• Apache OFbiz
• Apache Skywalking
• Apache Solr
• Apache Struts2
• Ivanti MobileIron
• ManageEngine ADManager
• Ubiquiti UniFi Controller
• VMware Horizon
• VMware vCenter

Many security companies will make a big deal about the 300 million+ downloads of vulnerable log4j libraries over the last two years. The idea being, a lot of projects are vulnerable because they use the vulnerable library. That’s not right though.

The reality is the short list above is the set of actually exploitable software, and only a subset of those products have been linked to exploitation in the wild. VulnCheck currently associates Log4Shell exploitation with 40 APT, ransomware groups, and/or botnets, but only four of the products above are associated with those attacks: MobileIron, Ubiquiti UniFi Controller, VMware Horizon, and VMware vCenter.

Maybe there are tens of thousands of projects that depend on vulnerable log4j libraries, but of those tens of thousands of projects only these four products are tied to actual exploitation in the wild. That’s largely because exploitation of Log4Shell for code execution is much more complicated than just finding victims that use the vulnerable library.

Log4Shell is a two stage attack. The first stage triggers a connection to an attacker-controlled server when an attacker-controlled string is logged by the victim software. Almost every exploit that we index in VulnCheck XDB stops here. But it’s important to realize that completing the first stage does not achieve code execution. For code execution (the second stage), the attacker-controlled server must provide new code for the victim to execute. This is a non-trivial task in Java, and requires using dependencies and serialized gadgets that may not work against the victim software.

For example, VulnCheck-developed Log4Shell exploits use the following gadgets to achieve code execution:

Each product is vulnerable to a different set of Java gadgets and some encountered products won’t be vulnerable to any. Exploitation for code execution using Log4Shell, even after exploiting the first stage, is not guaranteed. Your favorite clout chaser on Twitter may claim their Log4Shell canary token is triggered by sending a JNDI string through email, but they have not proven anything when it comes to actual code execution. Landing Log4Shell for code execution is complicated and that’s why real world exploitation has been limited to so few products.

Very few Log4Shell targets remain

New reports of Log4Shell exploitation have surfaced as recently as December 11, 2023. Cisco Talos tied a recent Lazarus campaign to Log4Shell exploitation against VMware Horizon (See?). It begs the question, “After two years, what is the internet footprint of the products that are known to be exploitable by Log4Shell?” At VulnCheck we actually track this and as of December 7, 2023 there were ~125,000 hosts that hosted software that was potentially vulnerable to Log4Shell. What we mean by “potentially vulnerable” is that the software was known to be exploitable for code execution at some time (e.g. VMware Horizon).

Internet-Facing Software Potentially Vulnerable to Log4Shell (December 7, 2023)

125,000 hosts is a decent pool of potential victims, but it isn’t really that many. Just to understand the scale of things on the internet: there are approximately 30x more Hikvision cameras and 300x more nginx servers on the internet. 125,000 is a drop in the sea.

Additionally, very few of those 125,000 hosts are currently vulnerable to Log4Shell. Using VulnCheck developed version scanners we examined the installed versions of the internet-facing software and we found ~94% of the hosts are patched against Log4Shell.

Internet-Facing Software Potentially Vulnerable to Log4Shell (Post Version Scan)

That leaves just 7,000 potentially vulnerable hosts. With an emphasis on potentially because some of the software have undiscoverable versions (Apache James 3+, OFBiz, and Struts2). Additionally, Apache Solr typically (but not always) has authentication enabled, making it a poor initial access target. It’s also difficult to fingerprint the number of the remaining hosts that are honeypots, but we assume it’s a measurable amount.

The number of actually vulnerable hosts is probably half as many, given the caveats listed above. Which means the security community has done a decent job of cleaning up after this particular vulnerability. There do appear to be some remaining targets (and we’ll likely continue to see reports like Cisco Talos’ recent Lazarus writeup), but the possibility for widespread exploitation is clearly declining overall, and the tail-end is coming to a close as well. Soon, Log4Shell should become a distant memory.

Conclusion

Log4Shell was described as “the single biggest, most critical vulnerability ever”, but in actuality we see multiple vulnerabilities with a similar impact every year (Fortinet CVE-2023-27997, Cisco CVE-2023-20198, and Citrix CVE-2023-3519 all had comparable impact in 2023). Log4Shell never had an overwhelming amount of internet-facing targets, and, because of a strong effort by the security community, very few exploitable targets remain. The king of vulnerabilities remains Eternal Blue whose financial impact remains breath-taking almost eight years later (see Maersk and Merck).

Log4Shell has an interesting place in security history because it accelerated the conversation around Software Supply Chain Security & SBOM. But the impact of the vulnerability itself was, and still is, overblown and exaggerated.

About VulnCheck

Are you interested in the vulnerabilities that actually matter? Do you want to track the vulnerabilities attackers are exploiting in the wild? If so, VulnCheck's Exploit & Vulnerability Intelligence is for you. Register and demo our data today.