Blog
03.30.2023

CISA’s Catalog Of Known Exploited Vulnerabilities and the Massive Patch Management Problem

CISA has been charged by the US Government with the mission of defending our nation against ever-evolving cyber threats and attacks. This mission is made especially arduous, with hundreds of new vulnerabilities of varying levels of impact getting reported to the National Vulnerability Database (NVD) on a daily basis. What makes the situation even graver is that only a small number of software products that are used by enterprises are covered by the NVD. 

As part of this mission, CISA maintains a catalog of registered vulnerabilities that are being actively exploited. This catalog can be found here. 

Annotated Results:  

Given this highly consequential information that CISA releases from time to time, we decided to dig into the last (as of March 12th, 2023) hundred vulnerabilities placed by CISA into its catalog to see what other nuggets could be extracted from this very valuable data. Sure enough, double-clicking on the data released by CISA surfaced some really interesting insights that we’d like to share with you. The annotated results from this endeavor are available here 

Some Interesting Findings: 

The following represents some of our key findings: 

Are vulnerabilities democratically distributed between workloads and endpoints? 

Software being software, and the population of endpoints being substantially greater than that of workloads, we expected the vulnerabilities to be biased towards endpoints, or at least be evenly spread. Most CISOs also carry this belief and therefore invest heavily in protecting their endpoints with EDR solutions.  

To our surprise, we found 77 out of the first 100 vulnerabilities from the CISA catalog related to vulnerabilities in apps that ran in workloads, not endpoints. In thinking more about this finding, it stands to reason that from a  bad actor’s perspective, when targeting a workload, there is a much greater impact on business continuity and/ or loss of reputation and hence greater willingness on the part of the enterprise to negotiate with the bad actor. 

Fundamentally, an endpoint and a workload are as different as chalk and cheese, even though one may mistakenly believe they are similar. After all, both have compute hardware and run software applications. Nothing could be more different. Workload apps accept connections 24 x 7 from anywhere in the world, whereas endpoint apps are deployed safely behind a home/ business router and only connect to the big bad world when the user chooses to.  

One takeaway from this data point would be that workloads need a different level of protection because they are exposed to the “elements” 24 x 7 and in a more accessible manner. A second takeaway would be that an EDR solution that protects endpoints very well may not automatically protect workloads as well. It is not a given. CISOs/ CIOs need to be more discerning and make that evaluation carefully. 

How seriously should I take CISA’s exploited vulnerability notifications?

Based on this article, on 3/15/23, the victim enterprise learned a very painful lesson even though CISA had warned about this RCE vulnerability being exploited as early as 2/10/23, almost 30 days before. To make matters worse for the victim enterprise, a quick perusal of the vulnerability page on the NVD website shows that an exploit is freely available for download. 

From an attacker’s perspective, a vulnerability that has remote code execution (RCE) attributes is a gift that keeps giving. After all, a vulnerability with RCE capabilities gives the bad actor the ability to execute any arbitrary code of their choosing on the victim's workload. This is exactly what the bad actor wants. When such a vulnerability additionally allows the attacker to escalate their privileges to the administrator level, the damage that will (inevitably) follow will be highly impactful.   

Of the 100 vulnerabilities CISA reported that we examined, we found 92 vulnerabilities had RCE capabilities, with 18 also allowing the attacker to escalate privileges to the highest level. The other 8 vulnerabilities allowed the attacker to: 

  • Bypass credential checking 
  • Drop Malware/ Web Shell (two instances) 
  • Corrupt critical/ confidential data 
  • Exfiltrate critical/ confidential data 
  • Perform a DDoS attack 
  • Phish gullible users 
  • Change critical configuration of the victim 

One takeaway from this data point would be that enterprise need to either patch their applications on a daily basis or deploy a compensating control that takes away an attacker’s ability to gain control of the workload. 

Are some vulnerabilities more critical than others? 

Ultimately it comes down to the attackable surface that a given vulnerability exposes. A vulnerability in the OS or OS vendor-provided runtime code presents a very wide aperture. Such a vulnerability immediately exposes every workload to attacks. 

In examining the last 100 vulnerabilities reported by CISA, we found 10 vulnerabilities that could be traced to Apple’s OSs’ (iOS, iPadOS, macOS) and 27 vulnerabilities related to Microsoft’s Windows OS. 

One takeaway would be that when a vulnerability is in an OS or an OS runtime library, it should be addressed urgently, especially if it has RCE attributes. Hoping that attackers won't visit because your enterprise is too small, is wishful thinking. Bad actors are especially looking for smaller enterprises because an attack on such an enterprise can be more debilitating at a personal level which means the attacker has increased their odds of collecting ransom. A second takeaway would be to have a compensating control in place that acts as a backstop even if the vulnerability is not patched in a timely manner. 

I just patched; can I put my feet up? 

On patching a vulnerability, the enterprise often breathes a sigh of relief. After all, it was not easy to get through the exercise. The CIO is likely thinking, “can I take a break and congratulate my team”? Certainly, but please know that sometimes a patch does not fix the original vulnerability.  

Of the 100 vulnerabilities, we found four vulnerabilities that needed to be re-released. These vulnerabilities are identified by a green highlight in the Vendor Project and Product field. 

One takeaway, especially when exploit code is posted on the Internet, would be to test if the patching exercise delivered the enterprise to the promised land or not. A second takeaway would be to have a Compensating Control for the vulnerability in place as well, just in case the enterprise did not get to the promised land. 

What should I do if the exploited vulnerability is in a cyber security product? 

Everyone expects the cyber security product to be “immune” from vulnerabilities. Ordinarily, one doesn’t expect one’s doctor to be sick. Finding a cyber security product in the list of products being exploited is, therefore, especially painful. who can the enterprise even turn to If the security product starts being the confused deputy? 

We found 15 security products (highlighted in yellow) in this truncated CISA list of the latest 100 vulnerabilities. 

One takeaway is that when CISA notification spans a vulnerability in a cyber security product, please take it very seriously. The very foundation of the building may be beginning to show cracks. A second takeaway would be to have a compensating control that protects the security product. 
 

Are the bad actors abusing the CISA-reported vulnerabilities very sophisticated? 

Bad actors come in all flavors – from nation-state ones to organized criminal enterprises to the script kiddie types. When exploit code is posted on the Internet, even the script kiddie variety of attackers get empowered. 

We found 35 vulnerabilities that had exploit code posted on the Internet.  

One takeaway is that if the vulnerability page in NVD (or the vendor’s advisory) reports that an exploit is available, please treat the matter with the greatest urgency and either patch expeditiously or have a Compensating Control in place. 

How many of these vulnerabilities are Zero Day variety? 

If we were to ask 10 people what a zero-day vulnerability is, we can expect to hear at least 3 to 4 different definitions. A more traditionally accepted definition is that a zero-day vulnerability is one that is previously unknown to those who should be interested in its mitigation, especially the vendor of the target software. An exploit taking advantage of a zero-day vulnerability is called a zero-day exploit, or zero-day attack. 

In examining this truncated version of the latest 100 vulnerabilities in CISA’s disclosure, we found that in the case of 40 vulnerabilities, the date of the CISA disclosure preceded the date the vulnerability was reported in the NVD database. This is very troublesome for the CIO/ CISO.  

One takeaway is to deploy a security control that offers Compensating Control capabilities. Such a control can curtail what a bad actor can do even if the enterprise did not have the luxury of a patch being available.  

There is a lot of talk about a Compensating Control. What is a Compensating Control? 

A compensating control for a vulnerability is a control that can mitigate the impact of the vulnerability. In other words, it can prevent the bad actor from taking over and being able to execute arbitrary code on a victim's workload.  

A security control that leverages allowlisting both at the file as well as process level to protect workloads fits the bill of being a Compensating Control against vulnerabilities with RCE attributes.  

Remember that 77 of 100 CVEs are distributed to workloads, and 92 of the 100 vulnerabilities for which CISA issued notifications had RCE attributes.  OS vulnerabilities, in particular, open a wide aperture to a greater attack surface.    

Virsec Security Platform (VSP)  provides strong Compensating Controls that offer a backstop against vulnerabilities with RCE attributes. 

Please visit us at www.virsec.com to find out more. 

About the Author
Satya Gupta is Virsec’s visionary founder, with over 25 years of expertise in embedded systems, network security and systems architecture. Satya has helped build and guide the company through key growth phases from initial funding (2015), developing core technology with key partners including Raytheon and Lockheed (2016-2018), to launching an enterprise class, GA product (2019). Prior to this, Satya built a highly profitable software design and consulting business targeting data networking, application security and industrial automation projects. He was also Director of Firmware Engineering at Narad Networks and Managing Director and Chief Engineer at Eastern Telecom and Tech Ltd. Satya has more than 40 patents in complex firmware architecture with products deployed to hundreds of thousands of users. He holds a BS degree in Engineering from the Indian Institute of Technology in Kanpur and additional degrees from the University of Massachusetts at Lowell.