Introduction
It’s been just over a year since the infamous log4j vulnerability was publicly disclosed, sending security teams into a patching frenzy as holidays loomed ahead. The vulnerability, dubbed Log4Shell, is a critical remote code execution (RCE) vulnerability in the Apache log4j logging library. It allows a threat actor to send a request with a payload that, when logged by a vulnerable version of log4j, results in remote code execution on the host. Moreover, the payload is executed with permissions at the level of the user running the service (yet another reason to avoid running services as `root`).
The vulnerability was given the highest possible CVSS score of 10 and practitioners were urged to patch and upgrade vulnerable systems immediately. The ubiquity of the log4j library–used in a variety of tools and products–compounded the severity of the vulnerability itself.
Much has been written about this vulnerability since its disclosure, including our initial look at the vulnerability. Presented here is our investigation of how Log4Shell remediation has evolved over time.
Measuring the Internet’s Response to Log4Shell
At Censys, we wanted to better understand how the Internet as a whole responded to this vulnerability. To measure this, we identified a subset of software visible to Censys whose versions we could discern and map to a state of whether it’s likely “vulnerable” or “not vulnerable” to Log4Shell. Specifically, we examined hosts running Metabase, Neo4j, Solr, Pagerduty, and Unifi software. The following analysis does not represent every device vulnerable to Log4Shell in existence but rather what we can see from our passive scans of Internet-facing devices.
The Immediate Aftermath
You may recognize this graph if you’ve seen our 2022 State of the Internet Report (and if you haven’t, you can get your copy here). As discussed in the report, patching upon disclosure was rapid, and we saw a 34% decline in devices running software that appears to be vulnerable to Log4Shell from December 2021, when it was disclosed, to January 2022. However, we were curious how long this sense of urgency would hold.
One Year Later
From December 2021 to December 2022, Censys observed an 78% decrease in hosts that appear to be running software vulnerable to Log4Shell.
While the overall trend of vulnerable versions decreasing is promising, it’s concerning that there are still over 23,000 hosts visible to Censys that appear to be vulnerable. As of December 2022, Wired points out that Chinese and Iranian state-sponsored actors continue to exploit this CVE. Exploitation attempts are likely not limited to state-sponsored actors, either. As of this post, GreyNoise identifies 327 hosts that appear to be actively scanning for the log4j vulnerability.
Vulnerability by Autonomous System and Country
When examining the top 10 Autonomous Systems where log4j appears to remain vulnerable in December 2022, it’s not surprising to see two ASes owned by Amazon topping the list, as they are one of the largest owners of Internet real estate in terms of both host and service counts. Other popular cloud providers, including Digital Ocean, Microsoft, OVH, Google, and Alibaba, are also prominent on this list.
Similar to observations of Amazon having large numbers of services likely vulnerable to Log4Shell, it’s not surprising to see the US topping the list of countries where we observe the most services that are likely vulnerable. However, if the distribution of where we observe vulnerable log4j versions mirrored the distribution of where we see the most services globally overall, we wouldn’t expect to see Brazil so close to the top of this list.
Conclusion
While the security community rallied together a year ago to patch and address the log4j vulnerability, dubbed “arguably the most severe vulnerability ever,” it continues to see exploitation and remains a valuable tool in a threat actor’s toolkit. A non-trivial number of hosts remain vulnerable to exploitation. The best time to patch log4j was a year ago, but if you’re running a vulnerable version, the second best time is now.
Censys ASM customers have access to risks for the software discussed in this post.
