The IT Nerd

In Rust Won’t Save Us: An Analysis of 2023’s Known Exploited Vulnerabilities, new research from Horizon3.ai, Chief Attack Engineer Zach Hanley analyzes all critical vulnerabilities from the CISA KEV catalog starting from January 2023 through January 2024, categorizing vuln root causes to see whether  current efforts in the information security industry match with the current threat vectors being abused.

He says: “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 actually being abused.”

Key findings:

1. Insecure Exposed Functions Lead the CISA KEV: Nearly half of vulnerabilities are enabled by insecure exposed functions. Vulnerabilities fall into this category when: a) It is not apparent that the developer made any effort to prevent an unauthenticated user from reaching dangerous code, or b) Often, the exposed dangerous code allows authorization bypass or remote code execution via insecure usage of command execution libraries, unrestricted deserialization, or file operations.  (more online)
2. Rust Won’t Save Us, But It Will Help: Memory safety issues were the second (tied with 3) 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.
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 it’s clear from the analysis that they are the target of choice coming in at 49%.

Hanley notes: “The lion’s share of vulnerabilities exploited in the last year are trivial to exploit. While memory safe languages like Rust may help eliminate some portion of breaches, there is much work to do to address the risk that comes with building complex software systems. We’re already seeing similar trends in 2024 with the recently exploited Ivanti Connect Secure vulnerabilities back-to-back…” (continues online).

Hanley recommends:

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

This entry was posted on February 6, 2024 at 11:30 am and is filed under Commentary with tags horizon3.ai. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.