Introduction

Memory safety issues have plagued the software industry for decades. The Cybersecurity & Infrastructure Security Agency (CISA) has been leading a charge for secure-by-design and encouraging developers and vendors to utilize memory safe languages like Rust to eradicate this vulnerability class. 

Google Chromium, the engine used by the majority of browsers around the world, reports that approximately 70% of their high severity issues are memory safety issues. Microsoft reports the same percent of issues affecting it’s Windows OS are also memory safety. But, what vulnerabilities are being exploited by threat actors today? CISA maintains and publishes its Known Exploited Vulnerability (KEV) catalog of all vulnerabilities that they have insight into having been exploited by threat actors. 

We have analyzed all critical vulnerabilities from the CISA KEV catalog starting from January 2023 through January 2024, categorized the vulnerability root causes, and attempted to analyze if the current efforts in the information security industry match with the current threat vectors being abused.

Executive Overview

1. Insecure Exposed Functions Lead the CISA KEV

Nearly half of vulnerabilities are enabled by insecure exposed functions. At a strategic level we’ve seen recent pushes for security improvements by pursuing memory safe languages and software bill of materials (SBOM), but a seemingly asymmetric amount of effort or strategy around addressing this vulnerability category.

Figure 1. Vulnerabilities by Root Cause

Vulnerabilities fall into this category when:

• It is not apparent that the developer made any effort to prevent an unauthenticated user from reaching dangerous code
• Often, the exposed dangerous code allows authorization bypass or remote code execution via insecure usage of command execution libraries, unrestricted deserialization, or file operations.

2. Rust Won’t Save Us, But It Will Help Us

Memory safety issues were the second (tied) leading cause of vulnerabilities in the data set, coming in at 20%. Interestingly, 75% of the analyzed memory safety vulnerabilities have been exploited as 0-days by threat actors. Additionally, 25% were discovered by security researchers and retroactively discovered to have been exploited as 0-days. When vulnerabilities are exploited as 0-days they typically have a much more widespread effect on the world given that patches often lag by weeks once they are discovered.

Figure 2. Vulnerabilities due to Memory Corruption

3. Web Routing and Path Abuse Tied for Second

Nearly 20% of vulnerabilities in Figure 1 are the result of routing and path abuse in web applications. These vulnerabilities typically manifest in the “glue” between web frameworks when a developer attempts to route application traffic from one service to another.

Vulnerabilities fall into this category when:

• The developer has made an apparent effort to prevent an unauthenticated user from reaching dangerous code. Developer mistakes include reverse proxy regex issues, framework filter issues, path normalization issues, and internal application path inspection issues.
• Similarly, once this code is reached, developers have abandoned defense-in-depth and secure coding practices which allow abuse of insecure functions.

4. Threat Actors Love Exploiting Appliances

This isn’t a new trend, but its clear from the analysis that they are the target of choice coming in at 49%. They’re commonly found on network boundaries and exposed to the internet. They also have low defender visibility – no PSP’s installed and sparse logging.

Figure 3. Vulnerability by Software Type

For the purpose of this analysis, appliances are any product or software that is commonly deployed as a hardware appliance or as a virtual appliance.

Technical Breakdown

There are 212 vulnerabilities that have been added to the CISA KEV catalog since the start of 2023. Of that, only 41 vulnerabilities are rated critical. Below is a snapshot of those 41 vulnerabilities and the root cause leading to the vulnerability being exploitable.

CVE-2023-34362: Progress MOVEit Transfer

Category: Routing / Path Abuse

Reference: Horizon3.ai

The application exposed an endpoint, /moveitisapi/moveitisapi?action=m2, that attempted to limit functionality to just localhost, but had a header parsing bug leading to any function being reachable.

Figure 4. Header Bypass to Invoke Arbitrary Function

CVE-2023-20887: VMware Aria for Operations for Networks

Category: Routing / Path Abuse

Reference: @SinSinology

A lax rewrite rule in the appliance’s Nginx configuration allowed an attacker to reach services which were meant to be unexposed. The request /saas./resttosaasservlet will route to /resttosaasservlet.

Figure 5. nginx Routing Bypass

CVE-2023-20198: Cisco IOS XE

Category: Routing / Path Abuse

Reference: Horizon3.ai

The appliance’s routing rules for which requests required authentication did not account for double URL encoded paths.

Figure 6. Double URL Encoded Path Authentication Bypass

CVE-2023-33246: Apache RocketMQ

Category: Insecure Exposed Function

Reference: Rapid7

The application insecurely exposed an endpoint that calls Java’s getRuntime().exec() with an attacker controlled variable.

Figure 7. FilterServerUtil getRuntime().exec()

CVE-2023-22515: Atlassian Confluence

Category: Insecure Exposed Function

Reference: Rapid7

The application insecurely exposed an endpoint, /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false, that allows modification to the server’s configuration state. Setting this state to false allows an attacker to re-enter application setup and add an administrative user.

Figure 8. Exposed Configuration Endpoint

CVE-2023-47246: SysAid Server

Category: Insecure Exposed Function

Reference: Huntress

The application exposed an endpoint, /userentry?accountId=/../../../tomcat/webapps/<webshell_dir>, which wrote attacker controlled data to a filepath also influenced by the attacker, but vulnerable to path traversal in the parameter.

Figure 9. Insecure File Write

CVE-2023-1671: Sophos Web Appliance

Category: Insecure Exposed Function

Reference: VulnCheck

The application insecurely exposed an endpoint, /index.php?c=blocked&action=continue, which did not sufficiently sanitize user input which results in second-order command injection.

Figure 10. Sanitization Bypass to Command Injection 

CVE-2023-27350: PaperCut MF / NG

Category: Insecure Exposed Function

Reference: Horizon3.ai

The application insecurely exposed an endpoint, /app?service=page/SetupComplete, used for first time administrator login during the install process.

Figure 11. Exposed SetupComplete formSubmit()

CVE-2023-46747: F5 BIG-IP

Category: Request Smuggling

Reference: Praetorian

The appliance used a custom Apache library which contained a known request-smuggling vulnerability: CVE-2022-26377. By abusing this vulnerability, with specific considerations for the F5 application stack, authentication bypass was achieved.

Figure 12. Request Smuggling Payload

CVE-2023- : Apache SuperSet

Category: Default Secret

Reference: Horizon3.ai

The application sets the underly Flask SECRET_KEY to a default value. This secret key is used to create session tokens, which can be forged when the secret key is known.

Figure 13. Default SECRET_KEY

CVE-2023-38203: Adobe ColdFusion

Category: Insecure Exposed Function

Reference: Project Discovery

The application exposed an insecure function at the endpoint, /CFIDE/adminapi/accessmanager.cfc?method=foo&_cfclient=true, which called a dangerous Java sink with attacker controlled input leading to deserialization.

Figure 14. Call to WDDXDeserialize() with Attacker Controlled Input

Conclusion and Looking Ahead

The lions share of vulnerabilities that are being exploited in the last year are trivial to exploit. While memory safe languages like Rust may help eliminate some of portion of breaches, there is much work to do to address the risk that comes with building complex software systems.

Looking at 2024 and beyond my advice would be:

1. Vendors
   1. Develop the depth of knowledge of your engineers in the frameworks they use
   2. Harden, standardize, and audit the use of those frameworks across products
   3. Enable and expose verbose logging for your products
2. Developers
   1. Assume all code you write is reachable from an unauthenticated context
   2. Practice defense-in-depth programming and don’t make it easy for an attacker to shell out
3. Defenders
   1. Reduce any attack surface exposed to the internet if its not needed there
   2. Proactively enable logging, and remote logging if possible, for all products that touch the internet
4. Researchers
   1. Look for bugs in the places frameworks come together

We’re already seeing similar trends in 2024 with the recently exploited Ivanti Connect Secure vulnerabilities back-to-back – more path abuse and SSRF to “RCE-as-a-feature” code. An interesting attack surface surrounding application re-initialization vulnerabilities has sprung up this last year and I think we’ll continue to see similar vulnerabilities discovered.

Community

This analysis is made possible by the collective information security community publishing their analysis and research to the world. The following organizations or people were referenced while performing this research:

Rapid7, Mandiant, Project Discovery, Praetorian, VulnCheck, Huntress, SonarSource, AssetNote, BishopFox, Lexfo, Palo Alto Networks, and many more.

Analysis Bias

This is an analysis based on my observations as both a software engineer and a vulnerability researcher. The analysis likely has bias and shortcoming stemming from:

1. Only considering the vulnerabilities that have been discovered recently
   1. My assumption is that more recent vulnerabilities are better representative of this issues that affect us today
2. Filtering Vulnerabilities Based on CVSS 3.0 >= 9 Score
   1. There are vulnerabilities in KEV that are not critically scored but can been combined with other vulnerabilities to achieve some critical effect

Raw Data

The full spreadsheet of all 41 vulnerabilities and their analysis can be found here.

RingZer0 Conference

This research was done in preparation for a talk I’ll be giving at RingZer0’s BOOTSTRAP conference on Friday, February 23.  I’ll briefly touch on this research along with vulnerability research I’ve conducted against Fortinet appliances over the last year that fall directly in line with the trends highlighted here.