A new report from Trustwave SpiderLabs has revealed that the number of CVEs published so far this year could be as much as 35% higher than in the same period in 2021. The findings come from the security firm’s 2022 Telemetry Report. While organizations appear to be exhibiting greater awareness of effective patch management compared to last year, if current trends continue, the total number of CVEs published in 2022 will exceed that of 2021. The report also examined several high severity vulnerabilities and the extent to which they remain prevalent.
Top three CWE classifications common in command injection, RCE vulnerabilities
In its report, SpiderLabs estimated that, as of June 16, the number of CVEs published in 2022 is approximately 6% to 35% higher than last year. “The top three Common Weakness Enumeration classifications for the 2022 CVEs are CWE-79, CWE-89, and CWE-787,” it added. “These three weaknesses are common in command injection and remote code execution vulnerabilities.”
Shodan data also showed that some high-profile vulnerabilities are still prevalent, SpiderLabs stated, with both white and black hats continuing to scan the internet to gather information on these vulnerabilities.
High profile vulnerabilities including Log4Shell still vulnerable, exploited
Despite being six months old, the firm found 1,467 instances vulnerable to Log4Shell (CVE-2021-44228), as of June 9, 2022. These vulnerable instances come from the Russian Federation, United States, and Germany with 266 (18%), 215 (15%), and 205 (15%) hosts, respectively.
SpiderLabs stated that “not all affected products are tackled by this report” and the firm only assessed samples of the most popular affected products. “There are still actors attempting to exploit this vulnerability,” and, via internet-wide sensor network GreyNoise6, the firm detected a 30-day trend of 667 unique IP addresses attempting to use Log4Shell on the internet.
Vulnerable instances of the Spring4Shell (CVE-2022-22965) vulnerability, which emerged at the end of the first quarter of 2022, are currently low, according to SpiderLabs. “Out of 452,520 reviewed instances, only 0.0758% are vulnerable. As of June 12, 2022, the top countries with the greatest number of vulnerable instances were China, United States, and Ireland, with 122 (36%), 93 (27%), and 18 (5%), respectively.” Spring4Shell is still being exploited, but not as actively as Log4Shell, with an average of 15 to 20 IPs attempting to exploit Spring4Shell per day, the report added.
Despite having a small footprint on Shodan, vulnerable instances relating to the command execution exploit in the F5 BIG-IP iControl REST interface (CVE-2022-1388), published in May 2022, were detected by SpiderLabs. “Fortunately, only 2.73% of 1,719 are vulnerable,” it wrote, adding that the U.S. had the greatest number of vulnerable instances, 26% of the total. “This vulnerability is being revisited from time to time, but there are days when no attempt for exploitation is recorded,” the report stated.
Atlassian’s Confluence Server and Data Center remote code execution vulnerability (CVE-2022-26134) was released in early June 2022, and as of June 11, only 4.44% of 7,074 hosts found on Shodan were vulnerable, SpiderLabs said. “China, the U.S., and the Russian Federation have the highest number, with 120 (38%), 37 (12%), and 27 (9%) vulnerable instances.” As of June 19, 2,398 unique IP addresses were detected attempting to exploit CVE-2022-26134, with a peak of 607 unique IP addresses doing so on June 6, the report read.
Interestingly, SpiderLabs identified unique IP addresses that attempted to exploit three out of the four vulnerabilities mentioned above, with 525 intersecting IP addresses attempting to exploit both Log4Shell and Atlassian Confluence RCE.
Risks of unpatched vulnerabilities varies among companies
What’s more, upon assessing instances vulnerable to either CVE-2021-44228, CVE-2022-22965, CVE-2022-1388, or CVE-2022-26134, SpiderLabs found that some are still vulnerable to CVEs dating back to 2016, with the most common CVE-2017-15906, a vulnerability in OpenSSH. This suggests that organizations that are vulnerable to newer vulnerabilities could also have failed to patch exploits that are years old.
Speaking to CSO, Ziv Mador, VP security research at Trustwave SpiderLabs, says typically a few scenarios explain why some organizations fail to patch vulnerabilities quickly, or at all. “Some organizations do patch, but it takes them time. For example, they may want to test the patches in their pre-production environment before they deploy them in production. Some organizations may be slow simply because they do not understand the urgency in installing patches.”
Conversely, some organizations may not install patches at all because the patch addresses a vulnerability that (they believe) is not exploitable in their specific configuration/environment, Mador adds. “Alternatively, an organization may not install a patch because their process is broken, or they are ignorant to the risk.”
In certain environments, patches are not installed as it may de-validate the certification of specific systems, Mador says. “This is common with healthcare devices. In this scenario, organizations do not patch because they view the threat as not significant enough.” Indeed, some vulnerabilities are not exploitable in certain configurations, and it can be a legitimate decision to not patch in those cases, Mador admits. “However, it does require the security team in an organization to carefully review the details and confirm that.”