The rush to patch systems affected by the landmark Log4Shell vulnerability has coincided with a wider improvement in patching rates for the most critical flaws, a report has found.
The remote code execution (RCE) flaw in Apache Log4j (CVE-2021-44228), the near-ubiquitous open source Java logging utility, sent organizations across the ecosystem scrambling to fix applications or patch systems after it emerged in December 2021.
Eight months on, the 2022 Trustwave SpiderLabs Telemetry Report has concluded that organizations “finally understand the necessity of having a solid security posture”.
Shodan searches performed by Trustwave SpiderLabs researchers revealed a sharp fall in the proportion of affected instances vulnerable to 2022’s highest profile vulnerabilities versus 2021’s equivalent flaws.
“Vulnerability disclosure-to-patch times have decreased,” Alex Rothacker, director of research and security scanning at Trustwave, told The Daily Swig.
Celebrity factor
He also noticed that security flaws’ “level of celebrity” was tied to both patching rates and patching speeds, with Log4j and Spring Framework instances outscoring what Rothacker said are lower profile issues in F5’s BIG-IP and Atlassian’s Confluence on these fronts.
For instance, only 0.36% of 405,993 instances of the most popular products running Log4j were vulnerable to the first Log4Shell patch (as opposed to the subsequent bypass) six months after exploits surfaced.
Equivalent numbers were 0.075% of 452,520 instances running unpatched versions of Spring Framework, another popular open source Java component, in regard to ‘Spring4Shell’ (CVE-2022-22965) three months after its disclosure.
Instances vulnerable to RCEs in F5’s BIG-IP (CVE-2022-1388) and Atlassian Confluence Server and Data Center (CVE-2022-26134) were 2.73% of 1,719 after disclosure and 4.44% of 7,074 hosts respectively – although disclosure was much more recent in these cases.
By contrast, Trustwave’s 2021 report found that more than 50% of instances were vulnerable in relation to each of three similarly impactful vulnerabilities, weeks or months after patch release.
“Log4Shell seems to have been a call to action for many organizations,” said Rothacker. “The volume of questions and requests for remediation help that we received from customers for Log4Shell was unprecedented.”
Critical mass
This year is on course to comfortable eclipse 2021 in terms of both number of CVEs published and the proportion of which that are critical, the report found.
For instance, Rothacker said that August has already surpassed all previous months in 2022 and 2021, with 3,779 CVEs published as of August 26, while July and June also saw high numbers of 2,226 and 2,377 respectively.
Critical vulnerabilities account for 18% of 2022 CVEs, up from 13% of CVEs in 2021.
The report also discovered that some affected instances were still vulnerable to CVEs dating back as far as 2016, with the most widespread bug being CVE-2017-15906, an issue in encrypted remote login tool OpenSSH.
Despite being distributed in most Linux distributions by default, the bug’s medium severity means “it is most likely that many organizations do not see it as a significant issue and are de-prioritizing fixing it” said Rothacker.
“Other listed vulnerabilities either are for less commonly deployed software e.g CVE-2018-15199, or do have other mitigations, or constraints e.g CVE-2018-1312, that make it less likely that they will be exploited,” he added.
The top three CWE classifications for 2022 are cross-site scripting (XSS), SQL injection, and out-of-bounds write bugs.
