Sensor Intel Series: Top CVEs in September 2023

Welcome back to the Sensor Intelligence Series, our recurring monthly summary of vulnerability intelligence based on distributed passive sensor data. We’ll start off this month’s analysis with a look at some activity from the August dataset, which demonstrates some of the oddities we occasionally see, and then dig into the changes we saw in September for the CVEs we track.

First, an Aside From August

The sensors from which we gather Sensor Intel Series data are passive, meaning they do not have any DNS names associated with them, and that they do not respond to traffic. This means that most of the traffic we receive is broad, Internet-wide scanning activity, not particularly targeted to specific business or organization. Additionally, we’re focused on detecting attempts to exploit CVEs, so we typically don’t look very closely at traffic that isn’t targeting specific vulnerabilities.

It’s always a bit of a surprise when we see what looks like targeted activity. In preparation for this article, reviewing August 2023 data, we noticed an anomaly that was an interesting exception to the general rule.

Starting on August 15^th, 2023, at 05:21 UTC, and ending on August 23^rd, at 19:30 UTC, we saw a determined credential stuffing attack take place against one of our sensors located in Greece.

Over the course of these 8 days and 14 hours, we observed a steady stream of POST requests to the URI “/”, each containing the username of “root” or “admin” and a varying password string, most of which were only sent once. There wasn’t any indication of a particular software platform being targeted. The specific POST parameters which were used were “input_user”, “input_pass”, and “submit_login.”

This strikes us as notable for a few reasons. First, this traffic was seen on only one sensor. Secondly, it was relatively slow. Each request was separated from the next by 1 second or more. Third, the attack was sourced from a mere 18 IP addresses in just two ASNs. While there was some traffic observed from these IPs and ASNs targeting other sensors with other traffic, no other sensors saw this cred stuffing activity.

Table 1 shows the IPs and ASNs involved in this attack, along with the source and destination countries, and counts of traffic observed.
 

Once the attack ended, we didn’t see it again. In fact, we went back through all the 2023 data we have so far, and this specific pattern of cred stuffing attack only appears this once.

The biggest question we had was “Why would such a determined attack be launched at a sensor that wouldn’t ever respond?” In typical credential stuffing attacks, an attacker will monitor their results, looking for a “200 Success” or a “302 Redirect” response, or even just a size difference between successful and unsuccessful attempts, to be able to determine which username and password pair was valid. In this case, no responses whatsoever were seen by the attacker.

One possibility is that the attacker’s targeting was simply wrong. Perhaps they were targeting a netblock where they had identified a possibly valid target, and our sensor was caught up in an overly broad range of IPs. Perhaps they simply mistyped the target IP address, or used a DNS name which was incorrectly pointed towards our sensor. At the end of the day, we don’t have enough information to really say for certain.

Nevertheless, we did manage to capture some 6600 unique username and password pairs that this attacker used for their attempt and can now keep an eye out for more activity.

September Vulnerabilities by the Numbers

Figure 1 shows the traffic for the top 10 CVEs in September. CVE-2020-8958, a Guangzhou router command injection vulnerability, has been our top seen CVE for much of the past year, returning to the top last month, and continuing its dominance this month. Second place remained unchanged: CVE-2022-34847, an RCE in the open-source GeoServer software. In fact, only two of our top contenders changed their position this month. CVE-2022-42475, a heap-based buffer overflow in Fortinet SSL-VPNs dropped from 3^rd to 4^th position, and CVE-2017-9841, an RCE vulnerability in PHPUnit, dropped another position, continuing a downward trend we started observing in August. Overall traffic in the CVEs we track dropped again, but not as precipitously as it did in August.

Table 2 shows traffic for September, change in traffic from August, CVSS v3.x score, and EPSS scores for 75 CVEs. Our list of CVEs with confirmed attack or scanning traffic currently stands at 81, but 6 vulnerabilities saw no traffic in either July or August and so don’t make this table.

Targeting Trends

To better assess rapid changes in attack traffic, Figure 2 shows a bump plot, which plots both traffic volume and changes in rank. The 12 CVEs shown here represent the top five for each of the twelve months. Notable in this month’s plot is the complete lack of observed activity for CVE-2016-4945. Last month we observed its dramatic drop, and this month, it simply disappeared.

It turns out that this traffic was only seen from one IP address, 68.1.19.59, an IP out of ASN 22773 in the United States. It first emerged in March 2023, scaled up its scanning over several months and peaked in July, and now, seems to have been taken down or stopped on its own accord on August 7^th, 2023.

The last several months of observations really show how even modest changes in scanning activity can affect the overall traffic patterns we observe. A single IP, scanning broadly and quickly across the whole internet, can generate a significant amount of traffic.

Long Term Trends

Because Figure 2 only shows high-traffic CVEs, Figure 3 shows traffic for all 81 CVEs we have tracked. In this view, most of our tracked CVEs can be seen to be holding at a relatively steady rate, with a few others dropping off from relatively low volume in previous months, such as CVE-2022-36914, an RCE vulnerability in Teclib GLPI.

Conclusions

This month we added a signature for CVE-2020-0618, a remote code execution vulnerability in Microsoft SQL Server Reporting Services, and observed CVE-2016-4945 fall completely out of our data.

Our sensors are passive, and they do not respond to requests, nor do they pretend to be any specific platform or software stack. They are simply an open socket on port 80 and 443, with just enough of a webserver to be able to record the requests made to them and negotiate any required TLS connection. They do not have DNS names, although it’s certainly possible they may once have had them. Sometimes IP blocks are reassigned, and old DNS records remain that continue to point to them.

Given this, we expect to see traffic that is primarily composed of scanning and exploitation attempts that require little sophistication. Occasionally, however, we see other activity, such as the cred stuffing activity we analyzed this month.

Even with the above limitations, we can observe quite a lot, from the effects of an exploit being developed and shared for a new vulnerability, to the effect of an ISP taking down scanning infrastructure, if indeed this is what happened in the case of CVE-2016-4945.

In fact, the sudden disappearance of a CVE from our dataset does give some credence to the idea that reporting IP addresses we see conducting hostile activity to the ISPs responsible for them may lead to good outcomes. Certainly, some ISPs and hosting providers simply don’t care, and will take no action, but it is probably worth a try. It may not help you directly, but less hostile activity on the Internet seems to us to be a net benefit for all, although there are no guarantees that the hostile activity won’t reemerge.

For those new to the Sensor Intelligence Series, we will conclude by repeating some old but valid observations. We see a continuing focus on IoT and router vulnerabilities, as well as easy, essentially one-request remote code execution vulnerabilities. These typically result in the installation of malware, crypto miners, and DDoS bots. See you in November.