Log4j/Log4Shell One Year Later: Endemic Vulnerability Indeed
On December 9, 2021, Apache upended the cybersecurity industry by publishing a zero-day vulnerability (CVE-2021-44228) for its ubiquitous Log4j logging utility. Dubbed Log4Shell, the remote code execution flaw (CVSS score:10) allows an attacker to take control of a connected device and run malicious code, access sensitive data or alter its configuration. Because Logj4 is free and easy-to-use, it’s embedded (often deeply) in Java applications used by IT and OT platforms worldwide. Those same characteristics make it attractive to threat actors with few hacking skills.
While not as catastrophic as some experts predicted, the impact of Log4Shell cast a spotlight on vulnerabilities in open-source software and the need for software supply chain transparency, namely through software bills of materials (SBOMs). In January 2022, Microsoft warned that it had observed sophisticated nation-state actors from China, Iran, North Korea and Turkey exploiting Log4Shell to deploy ransomware on internet-facing systems. Six months later, the Cyber Safety Review Board classified Log4j as an endemic vulnerability that will linger for years, coining a term that was adopted industry wide.
Troubling Log4Shell persistence one year later
Now, Log4j and Log4Shell are back in the news. A new telemetry study from Tenable found that one in 10 assets – including servers, web applications, containers and IoT devices – was vulnerable to Log4Shell when it was discovered in December 2021. Ten months later, just 2.5% of assets were vulnerable – but nearly one third (29%) of assets showed recurrences of Log4Shell despite previously achieving full remediation. This last statistic is especially cautionary for security teams.
The Tenable report numbers don’t surprise me. In our threat-hunting engagements this year, the Forescout Frontline team consistently found that adversaries are still actively scanning for exposed devices or a missed server with unpatched Log4Shell. Granted, if those assets have been remediated there’s less concern, but it’s important to know the hackers still consider Log4Shell an entryway. They know how poor hygiene is across the board, even regarding notorious known exploitable vulnerabilities (KEVs) with readily available patches, and that remediation can breed a false sense of security.
How to manage endemic vulnerabilities
COVID was an epidemic that escalated to become a global pandemic and, thankfully, may now be leveling off to an endemic in most of the world. An endemic is an eventual state where the disease is still present or recurring but manageable. Like the flu – which still kills hundreds of thousands of people each year. So, what can organizations do to protect themselves from endemic cyber threats?
- Mind the KEVs.
Security teams are too stretched to chase down and remediate every vulnerability. It’s neither practical nor necessary. As CISA has pointed out, “many vulnerabilities classified as critical are highly complex and have never been seen exploited in the wild – in fact, only 4% of the total number of CVEs have been publicly exploited.” That’s why it’s so important to concentrate on the ones that carry significant risk to your organization. They need constant diligence.
Being able to identify KEVs enables you to prioritize remediation activities and stop active threats. Monitor the KEV catalog, heed the alerts and always apply the latest patches upon availability.
In 2019, the Forum of Incident Response and Security Teams (FIRST) created the Exploit Prediction Scoring System, or EPSS. The EPSS is a “community-driven effort” that combines descriptive, qualitative data about vulnerabilities with evidence of real-world exploitation. Vulnerabilities are processed through EPSS algorithms, and the resulting values help cybersecurity professionals prioritize vulnerabilities that have a greater likelihood of exploitation. In addition to the KEV, the EPSS is another tool vulnerability managers could use to aid in their vulnerability response program.
- Remediation isn’t “one and done.”
Constant diligence also applies to remediated environments. As the Tenable survey shows, vulnerabilities are continuously being reintroduced, often because of larger process and operational issues that need attention. That may relate to faulty configuration management, periodic rather than continuous compliance scans, and the lack of a complete enterprise repository of connected devices, such as a configuration management database, or CMDB.
The good news is that by automating best practices you can harden your environment to protect against new threats while still being vigilant against old ones that are still in play.
- Take an outside-in approach.
Forescout recommends organizations take an outside-in approach to securing their attack surface. Look at what assets are facing the internet and make sure you’re continuously remediating those vulnerable instances. Ideally (with the help of SBOMs, where available), you want to also understand what libraries exist in those internet-facing assets and whether they can be exploited by an adversary.
When a vulnerability hits the market with the ferocity we’ve witnessed with Log4Shell, you’re going to see adversaries keep looking for it for as long as they can find it. If it’s top of mind for them, it’s got to be top of mind for you.
The Forescout Continuum Platform automates the discovery, assessment and governance of ALL cyber assets in your environment, including IT, IoT, OT/ICS and IoMT, from campus to cloud to data center to edge.