Impact of Log4Shell Bug Was Overblown, Say Researchers

Security researchers have claimed that a vulnerability described as the biggest and most critical ever discovered was far less dangerous than first believed.

Log4Shell was a critical, CVSS 10.0-rated vulnerability in popular open source logging utility Log4j. It was thought to be relatively easy to exploit, enabled remote code execution, and was found in a huge range of proprietary and open source applications.

Some experts predicted that it could be exploited by threat actors for years as organizations struggled to find and patch vulnerable versions hidden within open source dependencies.

However, a new report from VulnCheck released yesterday posited that these fears were “overblown and exaggerated.”

“The reality was that – at the time – very few products using the vulnerable log4j libraries were remotely exploitable for code execution,” the report argued.

Read more on Log4j: Lessons Learned: The Log4J Vulnerability 12 Months On

It claimed that, not including Minecraft, the following list represents the “majority” of products remotely exploitable using Log4Shell:

• 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,” VulnCheck argued.

“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.”

Exploitation is Complex

Although there might be tens of thousands of open source projects out there that depend on vulnerable Log4j libraries, it’s unlikely that they’ll be targeted because exploitation is complicated.

“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,” said VulnCheck.

“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.”

In short, every targeted product is vulnerable to a different set of Java gadgets and some won’t be vulnerable to any, the firm claimed. That leaves a relatively small footprint of products that are remotely exploitable relatively easily in attacks.

As of December 7, there were only 125,000 hosts that hosted software potentially vulnerable to Log4Shell, and 94% of those are now patched, according to VulnCheck.

“That leaves just 7000 potentially vulnerable hosts. With an emphasis on potentially because some of the software have undiscoverable versions (Apache James 3+, OFBiz, and Struts2),” the report concluded.

“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.”