Sensor Intel Series: Top CVEs in December 2023

Introduction

Welcome back to the Sensor Intelligence Series, our recurring monthly summary of vulnerability intelligence based on distributed passive sensor data. It’s a little bit surprising to realize that we’ve been publishing this series since August of 2022. In honor of that, and since it’s the end of the year as far as our available data goes, we’ll spend a little time zooming way out and looking at what the most common type of scanning traffic we saw across all of 2023.

But first, let’s look at the new things we’ve found, and what the overall picture looks like for December 2023.

Six New CVEs in the Data

This month, we found evidence of six more CVEs in our data. That’s a lot more than we have generally found in a single month, which is at least somewhat down to some new techniques we’re using to sift through this data more efficiently. We decided it might be better to split these out into a bullet list for easier reading:

• CVE-2015-8813 – A SSRF vector in the url parameter of the Umbraco web content management system.
• CVE-2019-12987 and CVE-2019-12988 – Remote, unauthenticated command injection vulnerabilities in the Citrix SD-WAN Center.
• CVE-2021-23394 – A remote, unauthenticated code execution vulnerability in the Studio-42 elFinder open-source file manager.
• CVE-2022-21587 – A remote, unauthenticated arbitrary file upload vulnerability in Oracle E-Business Suite (EBS)
• CVE-2022-26134 – A OGNL injection vulnerability in Confluence Server and Confluence Data Center.

As is usual, these are all remote, unauthenticated vulnerabilities that allow for code execution and related means to gain access to compute resources on the targets, which makes sense for the sort of scanning we see.

December Vulnerabilities by the Numbers

Figure 1 shows the traffic for the top 10 CVEs in December. CVE-2022-24847, an RCE in the open-source GeoServer software, and CVE-2022-22947, an RCE in the Spring Cloud Gateway product, continue to hold the top two spots as they did in November. CVE-2020-11625, a vulnerability in AvertX Cameras that allows for username enumeration, continued rising from last month, and ends up in the third position. CVE-2020-8958, a Guangzhou router command injection vulnerability, has thus continued to fall in position, as it did last month and the month before that. October’s top seen vulnerability, CVE-2017-9841, an RCE in PHPUnit, now 5 years old, comes in fifth this month. Overall traffic in the CVEs we track dropped again as it did in November, although not by very much.

Table 1 shows traffic for December, change in traffic from November, CVSS v3.x score, and EPSS scores for the CVEs and other vulnerabilities we’re tracking, if they showed up in the last two months.
 

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 (with one category combining two difficult to distinguish CVEs, CVE-2022-41040 and CVE-2021-34473) shown here represent the top five for each of the twelve months. Notable in this month’s plot, as previously mentioned, is the rise of both CVE-2022-24847 and CVE-2022-22947 over the last two months.

Overall Scanning Traffic Changes

We now look at the overall level of scan traffic we received, to place the above data in context. December saw a decline in total traffic of 5.8% from November, in part attributable to the decrease in scanning for CVE-2016-4945 and CVE-2020-8958.

The full details of the changes in scanning traffic over the last 12 months are shown in the following table.

Long Term Trends

Because Figure 2 only shows high-traffic CVEs, Figure 3 shows traffic for all the CVEs and vulnerabilities we have tracked.

As can be seen below, none of the CVEs and vulnerabilities we’re currently tracking fell off steeply or rose steeply in December, assuming they were present at all in the December data.

25 CVEs which had not appeared in the data for months reappeared this month, which is more than is usually seen.

Zooming Out to Look at 2023

One of the questions we frequently get asked about this data is about attribution, that is, who is doing the scanning. This is a difficult question, because it is quite well understood that many threat actors take great pains to do at least a bit of obfuscation of their activities, and in a situation like this may very well chose to use proxy networks or cloud providers to conceal the origins of their scanning.

However, there are some interesting details that emerge when looking at the entirety of the scan data we have from 2023. In terms of “top talkers” by ASN, we find the following.
 

ASN 202306 is assigned to HostGlobal.Plus Ltd, a hosting company, and 196645 is Hostpro Lab LLC, another hosting company. 14061 is Digital Ocean, and 6939 is Hurricane Electric, LLC. Even a quick look at this data seems to indicate that most scanning traffic is generated out of hosting provider networks at least in our dataset.

There may be several reasons for this. Provisioning VPS infrastructure to perform scanning is relatively easy and can be done on many hosting providers using false information for the account. Further, it is less likely that targets will wish to block large ranges of hosting provider IP space as this might lead to the blocking of legitimate sites.

It’s important to note that even though in the above table 7.27% of all the scanning traffic we observed in 2023 originated from IPs geolocated to Russia, this does not mean that this is evidence of Russian state sponsored activity, only that this hosting provider (which has IP space in both Russia and the UK) has been used by some set of scanners to provide their infrastructure.

Digging in further, we can see that the scans originating from ASN202306 have a relativel small set of target URLs, the top 20 of which are shown below.
 

As can be seen above, the scanning from the most active ASN in our data is almost entirely concerned with finding leaked credentials and other sensitive data.

Conclusions

We again reiterate that 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.

As we noted above, attribution is a somewhat difficult question. We certainly can tell where the majority of scanning activity comes from, but only at the level of IP and associated ASN, which is not enough to make a connection to a specific group, especially as the majority of scanning traffic we observe originates from large hosting providers.

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. Additionally, we see continuous scanning activity that might be most accurately described as reconnaissance; the identification of attack surface, exposed files, and other materials that attackers hope to leverage to enable further attacks.