2022 Trustwave SpiderLabs Telemetry Report

As organizations go about their regular routine of finding and adding new technologies to help increase their overall success, each organization must keep in mind the security implications of each move, along with the fact that much of their current technology stack has to be maintained with a well-thought out and quickly implemented patching program.

This ever-changing landscape means that it is crucial for organizations to keep up with security changes as they add new technology. Security staffers must keep in mind that attackers are almost always a few steps ahead in leveraging the issues accompanied by these changes. Last year, we had a report on some high-profile vulnerabilities for Internet-facing targets¹. This report checks if organizations improved their security posture by using the recent high-profile vulnerabilities in the past few months.

Key observations from this report show that companies finally understand the necessity of having a solid security posture. For example, some of the high severity vulnerabilities that we picked for this report still affect less than 10% of the sampled hosts from Shodan, but we see that companies are likely to patch their systems in a timely manner, or that they are more aware of their security than they were last year¹.

The chart below (Figure 1) shows the number of 2021 CVEs and 2022 CVEs published in NVD with a breakdown of the vulnerability impact. The 2022 CVEs are only 36% of the total 2021 CVEs even though we are already in mid-2022, there is a 5% increase in the critical vulnerabilities from last year’s 13%.

Figure 1: Number of 2021 and 2022 CVEs (As of June 16, 2022)

The number of CVEs published in 2022 are approximately 6% to 35% higher than last year (Figure 2). And just a note, these CVEs also include older vulnerabilities (e.g., CVE-2021-0060)². If this trend continues, we expect that the total published CVEs this year will exceed the number published in 2021.

[1] 2021 Trustwave SpiderLabs Telemetry Report

[2] See data feed from NVD

Figure 2: Number of vulnerabilities in NVD per month in 2021-2022 (As of June 16, 2022)

As seen in Figure 3, the top three Common Weakness Enumeration classifications for the 2022 CVEs are CWE-79, CWE-89, and CWE-787. These three weaknesses are common in command injection and remote code execution vulnerabilities.

Figure 3: CWE Breakdown for 2022 CVEs

High Profile Vulnerabilities

One of our tasks was to pick and gather telemetry on a few high-profile vulnerabilities using Shodan to review vulnerable publicly accessible instances on the Internet (Figure 4)³. Among our choices we included the Apache Log4j2 Remote Code Execution (RCE) vulnerability since it was still trending at the beginning of 2022. Proofs-of-Concept (POCs) are being published during or a day after the release of the vulnerabilities. We also see both white and black hat folks scanning the Internet to gather information on these vulnerabilities to help their companies and organizations protect their assets.

Figure 4: Some High-Profile Vulnerabilities since 2021 Q4 – 2022 Q2 

Apache Log4j2 Remote Code Execution aka Log4Shell

(CVE-2021-44228)

Apache Log4j is a known logging library used by many Java applications. On December 9, 2021, the Log4Shell exploit was discovered that affected millions of applications. A day later, NVD published CVE identifier (CVE-2021-44228)⁴. This vulnerability had been reported by a security researcher two weeks before the exploit was made known to the public⁵. Log4Shell takes advantage of the library’s feature allowing requests to LDAP and JNDI servers, which enables attackers to execute Java code remotely.

Six months after the zero-day was made known, vulnerable instances remain accessible on the Internet. Possible instances vulnerable to Log4Shell are gathered from Shodan, but not all affected products are tackled by this report. We only get samples of the most popular affected products. As seen in Figure 4, only 0.3613% of 405,993 instances we reviewed are vulnerable to Log4Shell (CVE-2021-44228). After the first patch for CVE-2021-44228, researchers around the globe further dismantled the library and found another vulnerability (CVE-2021-45046). However, we focused on the first CVE in this report.

As of June 9, 2022, we found 1,467 instances vulnerable to Log4Shell. These vulnerable instances come from the Russian Federation, United States, and Germany with 266 (18%), 215 (15%), and 205 (15%) hosts, respectively (Figure 5).

[3] Non-malicious packets are used to check if the instances are vulnerable. This heuristic approach is used to avoid non-intended effects in the instances. This could have different results if full exploitation of the vulnerability is used, but our approach should provide good approximation for telemetry.

[4] CVE-2021-44228 Detail

[5] The human toll of log4j maintenance

Figure 5: Heatmap of Vulnerable Hosts to Log4Shell (As of June 9, 2022)

Despite being six-months old, there are still actors attempting to exploit this vulnerability. Using GreyNoise⁶, the trend for the past 30 days (As of June 20, 2022) of unique IP addresses attempting to use Log4Shell on the Internet is shown in Figure 6.

Figure 6: Trend from GreyNoise Attempted to exploit Log4Shell⁶

[6] An internet-wide sensor network that passively collects network activity of Internet scanners.

[7] Apache Log4j RCE Attempt

Spring Framework Core Remote Code Execution aka Spring4Shell

(CVE-2022-22965)

Another popular component of Java applications, Spring Framework, had a critical vulnerability, which emerged at the end of the first quarter of 2022. The impact is on par with the Log4Shell vulnerability, which resulted in naming this vulnerability Spring4Shell. This vulnerability exposes a class member of the object parameter it is bound to, allowing attackers to write arbitrary code to the server leading to a Remote Code Execution (RCE).

That said, using the same approach with telemetry for Log4Shell, we used the most popular affected products to gather information⁸. It is encouraging to see that after three months of the exploit being published, the vulnerable instances are very low. 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 are China, United States, and Ireland, with 122 (36%), 93 (27%), and 18 (5%), respectively (Figure 7).

Figure 7: Heatmap of Vulnerable Hosts to Spring4Shell (As of June 12, 2022)

[8] Overview of software (un)affected by vulnerability

As with Log4Shell (Figure 6), this vulnerability is still being exploited. However, it is not as active with Spring4Shell, which has an average of 15-20 IPs attempting to exploit per day.

Figure 8: Trend from GreyNoise Attempted to exploit Spring4Shell⁹

F5 BIG-IP iControl REST Remote Code Execution

(CVE-2022-1388)

On May 4, 2022, a critical vulnerability was published for F5 BIG-IP. Attackers can bypass iControl REST authentication and execute arbitrary system commands on the affected product.

Despite having a small footprint of these devices found on Shodan, we still found vulnerable instances. Fortunately, only 2.73% of 1,719 are vulnerable. The U.S. has the greatest number of vulnerable instances, 26% of the total (Figure 9). This makes sense since 30% of all instances found on Shodan are from the U.S., as well (Figure 10).

[9] Spring Core RCE Attempt

Figure 9: Heatmap of Vulnerable Hosts to F5 BIG-IP iControl REST RCE (CVE-2022-1388) (As of June 13, 2022)

Figure 10: Top 20 Countries with F5 BIG-IP Instances

This vulnerability is being revisited from time to time as seen in Figure 11, but there are days when no attempt for exploitation is recorded. However, this lack of interest may be due to the limited instances available on the Internet.

Figure 11: Trend from GreyNoise Attempted to exploit F5 BIG-IP iControl REST RCE (CVE-2022-1388)¹⁰

[10] F5 BIG-IP iContron REST Authentication Bypass

Atlassian Confluence Server and Data Center Remote Code Execution

(CVE-2022-26134)

Atlassian released a security advisory on June 2, 2022¹¹. One of their products, Confluence Data Center and Server, is vulnerable to unauthenticated remote code execution via OGNL injection.

As of June 11, 2022, only 4.44% of 7,074 hosts found on Shodan are vulnerable³. China, the U.S., and the Russian Federation have the highest number, with 120 (38%), 37 (12%), and 27 (9%) vulnerable instances (Figure 12).

Figure 12: Heatmap of Vulnerable Hosts to Atlassian Confluence RCE (CVE-2022-26134) (As of June 11, 2022)

A few days after the release of the security advisory¹¹, various sources attempted to exploit this vulnerability, with a peak of 607 unique IP addresses on June 6, 2022 (Figure 13, 2022). Also, the peaks on June 13 and 15 are the same pattern seen in the Log4Shell trend in Figure 6.

[11] Confluence Security Advisory 2022-06-02

Figure 13: Trend from GreyNoise Attempted to exploit Atlassian Confluence RCE (CVE-2022-26134)¹²

GreyNoise Tagged IPs for Exploit Attempt

Reviewing the trend from GreyNoise, there are unique IP addresses that attempted to exploit 3 out of 4 vulnerabilities we mentioned in this report. GreyNoise tagged these IP addresses once they attempted to exploit a vulnerability. With further analysis, we can see in Figure 14 that there are 525 (13.52%)¹³ intersecting IP addresses that attempted to exploit both Log4Shell and Atlassian Confluence RCE.

Figure 14: GreyNoise Unique IP tags on each mentioned Vulnerabilities

[12] Atlassian Confluence Server CVE-2022-26134 OGNL Injection Attempt

[13] Percentage out of all IPs tagged with either of the four vulnerabilities in this report.

GreyNoise Tagged IPs for Exploit Attempt

Additionally, we checked if the instances vulnerable to either of the four vulnerabilities discussed in this report are vulnerable to old CVEs. As per Shodan’s data, Figure 15 shows that some are still vulnerable to CVEs dating back to 2016. The highest number is CVE-2017-15906, a vulnerability in OpenSSH.

Figure 15: Top 30 old Vulnerabilities Affecting the Vulnerable Hosts

Summary

Technology and software are introduced at an ever-increasing pace. The unfortunate result of this is the number of critical vulnerabilities that are found is keeping pace with these introductions. These vulnerabilities are generally unintentional and are due to bugs missed by the developers, but they still leave an organization open to attack, especially when threat actors find and leverage the vulnerabilities before ethical hackers find the issues.

Threat actors continuously scan the Internet to gain the advantage of those organizations with slow or outdated patching processes. Therefore, a proactive approach to identifying vulnerabilities is incredibly important. Knowing which new and old vulnerabilities should be a concern, and acting at the right time, are two critical factors that must be in place to have a good security posture. As seen in this report, more and more organizations are getting involved in protecting their assets as more critical vulnerabilities emerge in public domain.

Recommendations

With this information in mind, we recommend organizations be more proactive by keeping an eye on the latest security updates as Proofs-of-Concept, for most critical vulnerabilities are released n-days after the vulnerability is made known.

• Security staff should conduct a regular review of assets by means of audits, scans, and/or penetration tests, prioritize patching on key systems
• Limit access to the systems and apply the principle of least privilege
• Provide as much support as possible for the security teams responsible for protecting and applying these concepts.

Implementing just these basic steps will go far to improve the security posture of any organization, which is increasingly important in an ever-changing threat landscape.