A Look at CISA’s Top Routinely Exploited Vulnerabilities 

Knowing what vulnerabilities interest malicious actors is a critical step in assessing the risk of vulnerabilities found in your environment.  

On August 3rd, CISA released their Top Routinely Exploited Vulnerabilities report for the year 2022 and inside comes little surprise as to most of the culprits. Bugs tied to ransomware incidents continue to dominate the eyes of the agencies behind these joint advisories in hopes that the number of complete owns will diminish. Plus, this year CISA released a ‘Top 12’ list alongside another ‘other frequently exploited’ category rounding out to a total of 42 issues indicating the most abused bugs observed by the agencies involved. To view the full joint advisory in PDF form, see here. 

The Critical Reality of Existing Vulnerabilities 

A key finding within CISA’s advisory states that attackers are more often exploiting older software vulnerabilities than recently disclosed ones. In fact, the third most common vector in which attackers are accessing networks is exploitation of known vulnerabilities.  

These realities have resulted in an entire industry and community-driven effort surrounding the discovery of existing vulnerabilities, from a major increase in the interest of bug bounty practices and attack surface management, to continuous detection and (of course) the need for a robust vulnerability and patch management process. Staying ahead and decreasing the time to patch on commonly exploited vulnerabilities such as the ones listed in this advisory is critical to the baseline of any security program.  

The security community is aware of the dangers these vulnerabilities pose, and often the bugs listed in these advisories fall in the “if we didn’t patch this, we’d look stupid” bucket if you asked a sysadmin. So, what makes these vulnerabilities so commonly exploited in society? 

This question is one that we as an industry collectively need to ask when we see a set of vulnerabilities persist through multiple advisories that identify the most routinely exploited bugs. For example, if a ransomware group targets organizations with a specific vulnerability, and that vulnerability is able to be exploited against another organization many months or even years later, there are fundamental problems we aren’t covering.  

A Deep Dive into Routinely Exploited Vulns 

With CISA continuing this trend for what is now technically the 4th year — the first Top Routinely Exploited Advisory covered 2016-2019 — we here at Nucleus want to understand what these agencies saw in these bugs, how routine some bugs are since this began, what kind of early warning signs can be used as indicators of widely exploited bugs such as these, and what CISA recommends through the joint advisory. 

To look at just all the vulnerabilities discussed both in the ‘top 12’ list as well as the ‘other’ category, our own Patrick Garrity, Vulnerability Researcher at Nucleus, created this handy summarization of the bugs: 

What Stands Out? 

The last two years saw Microsoft Exchange server being relentlessly ripped for parts by threat actors, as multiple vulnerabilities in the technology rose to the headlines again and again throughout the year.  

In the first half of 2021 alone, at least 60,000 organizations worldwide were affected by incidents involving an Exchange server, and between 2021 and 2022 alone, 49 vulnerabilities were disclosed in Microsoft Exchange. When multiple ransomware-as-a-service (RaaS) and security organizations dog-pile, they truly dog-pile, as you can see from what happened this year with MOVEit. While some of this could have been FUD around real problems, ProxyWhatever attacks were a serious compromiser the last two years.  

Many researchers and others in the community began to question Microsoft after a series of exploits in 2022 on Exchange servers turned out to be caused by the same vector of a previous exploit, just with a slightly adjusted technique. This happens because attackers will often hold on to the same vectors (endpoints, functions, hooks, etc.) and adjust the technique. All it took for ProxyShell to innocently become ProxyNotShell was a workaround on the authorization barrier put in place by Microsoft at the time of disclosing the original bug. Same vector, just a newly added technique to reach the same goal. 

This is part of what makes root cause analysis so critical in the process of squashing security bugs. When something is a known security bug and exposes advantages to an attacker, it’s not uncommon for attackers to come back again and again once a patch lands to see what can still be broken. While Microsoft well exceeded other vendors in rounding out this year’s top exploited bugs according to CISA, this isn’t meant to point fingers at any vendor and call them worse at security than others. The prevalence problem Microsoft faces is complex. 

Of the bucket of 42 security bugs, 66% of them involved the exploitation of some kind of perimeter device or software that can not only land the attacker initial access to the environment, but also additional code execution capabilities. As we know, attackers will spend most of their time where they gain the most advantage, and they don’t have a scope. Once they have assessed your network to their liking or comfortability, they will start to understand where the greatest weaknesses lie. Maintaining controls and defense-in-depth across your entire attack surface is critical to avoiding a complete own due to one of these vulnerabilities.  

Looking Further Down the Rabbit Hole 

CISA included the Common Weakness Enumeration (CWE) IDs for most of the vulnerabilities included in the report. While singular weaknesses are not always 1:1 with exploitation of a vulnerability, we see the following consistency from the associated weaknesses: 

The heavy hitter being Improper Limitation of a Pathname to a Restricted Directory (CWE-22), or easier said, path traversal. This weakness is common amongst the top routinely exploited vulnerabilities for many reasons — one being how pervasive insecure design through lack of validation or inadequate controls is in today’s world mixing modern technological stacks with the ancient texts of the internet.  

Other weaknesses close behind are Server-Side Request Forgery (SSRF) (CWE-918), which recently sprung into the OWASP Top Ten, Injection by Downstream Component (CWE-74), Improper Privilege Management (CWE-269) and Code Injection (CWE-94). (The difference in 74 and 94 being that 74 uses the object that is injected downstream in another component, and 94 is the improper handling in allowing injected code to execute) Many of these weaknesses could be answered for in the design phase of outgoing features with secure-by-design concepts closely intertwined with the development process. Insufficient handling of objects and trusting user-input don’t have to be the death of vulnerability analysts for the rest of our lifetimes. 

CISA Recommendations for Commonly Exploited Vulns 

There are many reasons one could still have one of these vulnerabilities lingering in their environment, considering these are routinely exploited (meaning they still work). The points that CISA highlights aren’t exactly complicated points that no one has ever thought of before, but more along the lines of standards we should all maintain in the daily work we do to better secure the organization.  

This year, CISA split their Mitigations section by stakeholder, leaving advice for vendors and developers when working on their own products or services that assist security practitioners in their work, as well as the end user organizations keeping their own perimeters secure. 

Vendors and Developers:

1. Identify repeatedly exploited classes of vulnerability. We practiced some of this today with this blog, looking at common weaknesses, technical similarities, etc. It’s important to start to analyze these vulnerabilities a step above each one individually, in that you should ask what the entire sample has in common. Understanding frequently exploited vulnerabilities by their characteristics can better enhance defense-in-depth or compensating controls put in place to prevent them. 
2. Ensure business leaders are responsible for security. What CISA describes in this note is the importance of root cause analysis, which we here at Nucleus have harped on plenty of times. When a vulnerability is uncovered, it is only detrimental for everyone involved if the technology in which it was found is not properly assessed for the root cause of the issue. ProxyNotShell is just one of many examples in which a vulnerability is layered over by some control that doesn’t look underneath. Rather than uprooting the possibility for a vulnerability to exist, it is hidden within murkier waters. Attackers know this and will continue to go back to the same places where they have found weaknesses in the past. 
3. Follow the SSDF. The Secure Software Development Framework (SSDF) is the understanding that, from writing code to shipping it, every step of the Software Development Lifecycle (SDLC) must consider the security of what is being produced. The days of sticking the ‘S’ in front of SDLC to call it secure are over, and every step of it considers the security impact with SSDF.  
4. Prioritize secure-by-default configurations. This echos point #3 but is nonetheless critical to raising the bar. As CISA states, steps like eliminating default passwords, implementing SSO, isolation, implementing least-privilege, or even converting your whole organization to FIDO. These modern standards put many trivial attacks to bed and make it even more difficult for the attacker to find one hole in your network that gets them all the way to deployed ransomware. The last thing CISA mentions in this is critical to the success of the security mission in any organization, log your stuff! Logs are the truth of what the system does. Strong audit logging, especially for administrative functions, cannot be harped on enough. If you have good logging, your IR retainers will kneel and thank you. 
5. Ensure published CVEs include the proper CWE field identifying the root cause of the vulnerability. This point is less high level as some of the previous steps and granular to the usage of the CWE field. The CWE attached to a vulnerability adds context, but it may not always lead to the understanding of the root cause in and of itself. To put it simply, identifying the CWE for a vulnerability is not the same as conducting RCA of the impacted code. However, this does give a focus to a point of enrichment that can be improved in the security tooling provided today. 

End-User Organizations:

1. Update software, operating systems, applications, and firmware on IT network assets in a timely manner. Easy, peasy, right? Well, we wouldn’t have an entire industry around helping with this step if it was. Patch management is just a small part of a vulnerability management program, and automating all the steps in this process that you can do is critical to staying on top of your risk. 
2. Routinely perform automated asset discovery. Simply put, you can’t secure what you don’t know exists. You’ll hear us say at Nucleus many times over that, even in our own product, the first step isn’t identifying your vulnerabilities, but rather your assets. A comprehensive understanding of both your attack surface and your scanning coverage is critical in establishing a baseline. Without this baseline, you’re assessing risk on an unknown scale with hidden threats that linger in the dark corners. During my time as a SOC analyst, it was almost like mental bingo when determining the root cause for a security event, and often it would come down to filling in the “Didn’t know we had a 2011 version of ServiceNow running overseas” box. Find the system, find the owner and establish the cycle of doing this everywhere all of the time. 

Secure-by-design is the future we all may seek, but the problems of today are still what they are. Many organizations today, from SMB to large enterprises, struggle just keeping up with asset ownership. The guidance CISA provides are standards and concepts worth implementing where possible now, while the rest of your vulnerability identification and remediation functions can play catch-up.

The goal of security teams should always be to safely enable and never to roadblock. Identifying how security can play a center-stage role in the continuity of business and development ensures that other things like full scan coverage, identification, and ownership don’t act as hurdles but as built-in standards. These things make looking to your vulnerability management and remediation processes as much less of a mountain to climb. Looking at the most routinely exploited vulnerabilities according to numerous government agencies, we still have a bit of ground to cover. We at Nucleus expect there to be quite a few returning faces to the most routinely exploited vulnerabilities of 2023.