Abhay Bhargav

Disassembling CVE and CWE for No Fun and No Profit

Abhay Bhargav -

There's a good chance that you or your colleague(s) will be shuffling through the massive vendor presentation areas at RSA next week. Chances are that, as you make your way through the booths with shiny screens with Dashboards and fancy-looking charts, you'll see one or more of these "C" words. And while some of you know these terms and what they mean, some of you don't. Also, it doesn't help when people use some of these terms interchangeably. Let's look at the CVE and CWE with some examples and lets look at their uses, abuses and how you should evaluate your Vulnerability Management Strategy on the basis of these terms

Let's start with a Vulnerability. More specifically, a recent jaw-dropping vulnerability in Drupal (a popular Content Management System) that led to an attacker being able to perform Remote Code Execution and escalate privileges to the backend-server and other resources based on how the server is configured.

In this scenario, the attacker can leverage an unauthenticated GET request to the target Drupal site's RESTful API service. The attacker can use a serialized payload in the body of the request (JSON) and trigger Remote Code Execution. [1] Let's use this example to explain concepts of CWE, CVE and CVSS.

Let's start with the CVE. The CVE stands for Common Vulnerabilities and Exposures. This is an initiative by the National Cybersecurity FFRDC, managed by the MITRE Corporation in the US, with funding from the US Department of Homeland Security. This essentially is a database of vulnerabilities identified against publicly released software packages (like Drupal).

Security researchers commonly identify flaws with public software packages like Drupal, NodeJS, Oracle database, etc. When these flaws are identified, researchers might choose to file this finding as a CVE. The researcher generates an entry with the details of the vulnerability. MITRE reviews this information, and after vulnerability embargo (Embargo of a security issue means that the issue will not be publicly disclosed for some time by the vendor/discoverer), an ID like CVE-2019-12345 is assigned to it and its released as part of the CVE Database.

The CVE Database does not have risk, fix information, exploit information and so on. It contains the nature of the flaw, a short description, some additional analysis (if required), a CVSS score, a CWE ID and some references to third party sites that might have a more detailed explanation of the flaw, like SecurityFocus, or the vendor's website related to the flaw. [2]

As you probably have realized by now, the CVE list is NOT a comprehensive list of all possible flaws against publicly available software packages. Researchers/Attackers may choose to not disclose these flaws, but to sell them to the highest bidder/willing party.

It might also be that the flaw takes time to investigate, in which case, the vulnerability against an application might be active, but the CVE for it may not be filed for a few weeks, depending on the complexity/legal implications, etc

A lot of vulnerability scanning and exploit tools claim to be CVE compliant. Their signatures look to find conditions that are similar to the ones identified as part of the CVE. For example, a Vulnerability Scanner looks for Drupal CMS, versions 8.6.9 and below and flags that as a vulnerable Drupal deployment. In this case, its reasonably simple, but many vulnerability scanners flag a single flaw against multiple CVEs. For example, if Apache 2.10 is vulnerable against 30 CVEs, these are flagged as a single flaw, making it hard to manage vulnerabilities.

A common misnomer about CVEs, is that your custom-built application should have one as well. They will not. CVEs are only given to publicly distributed software packages. For example, Drupal has CVEs, MySQL has CVEs, whereas that custom plugin your team has built for Drupal thats only used by your Drupal deployment will NOT have CVEs assigned to it.

This Drupal Vulnerability has been given an ID of CVE-2019-6340

Let's talk about the CWE. The CWE is short for Common Weakness Enumeration. This is a project managed by MITRE as well. The CWE is not a database of vulnerabilities. Its really a categorization system for vulnerabilities and weaknesses in software. Each category of type of flaw has an ID assigned to it. For example, CWE-79 refers to Cross-Site Scripting (XSS) flaws. CWE-89 refers to SQL Injection flaws.

In addition, CWE also has a nested categorization system. CWE Information is hierarchically organized as: 

Views
------> Categories
------------------> Weaknesses

For example, CWE has a View called "Development Concepts", which is organized based on weaknesses identified during software development. Under this, they have several Categories and under each Category, they have several weaknesses (vulnerabilities). The Weakness and Categories have a Many-to-Many relationship.

For example CWE-16, which relates to Misconfiguration Weaknesses is a childOf the view Development Concepts and also the view OWASP Top Ten 2017 Category A6 - Security Misconfiguration. We'll look at the complexities caused by this, a little later.

Tools like BurpSuite, ZAP, Checkmarx, etc typically provide CWE Data along with the vulnerabilities they flag. This is essential in trying to manage these vulnerabilities. However, there's a significant twist in the tale.

This Drupal flaw, namely CVE-2019-6340 has been assigned CWE-20, which refers to Improper Input Validation. And this is where I begin to differ with CWE. As you can gather, "Improper Input Validation" is a pretty broad (and vague) category for a vulnerability. There are thousands of possibilities for "Improper Input Validation". In my opinion, CWEs should be categorized based on the Primary Attack Vector, which they largely are. In this case, clearly the primary attack vector was Insecure Deserialization, which is CWE 502. And while this looks like a minor issue, when managing vulnerabilities at scale, this can lead to major inaccuracies.

Most Vulnerability Management Platforms for Apps, use the CWE as the ID that they correlate around, including us, with our product Orchestron, which is a Automated Vulnerability Correlation and Management Platform. The challenges that we (and likely several others) faced were:

  1. Tools giving conflicting CWE-IDs for Vulnerabilities. For example, BurpSuite might categorize a NodeJS Code Injection triggered by an eval() function with CWE 94 (Code Injection) while OWASP ZAP, might categorize this as CWE 95 (Eval Injection). Neither of these are particularly wrong. However, this can cause mayhem with a pure CWE based vulnerability management framework. This prompted us to develop our own taxonomy and advanced automated correlation system, which is broadly based on CWE, but has multiple other checks before correctly categorizing the flaw, regardless of the tool you throw at it
  2. Incorrect CWE categorization affects the entire lifecycle of a Vulnerability. Let's take the Drupal flaw itself. By categorizing it as CWE-20, Improper Input Validation, developers might not apply the most appropriate fix. However, if it had been categorized as CWE-502 (Deserialization of Untrusted Data), which IMO is the right CWE, developers might actually identify a fix which is more specific and deserialization centric.
  3. Tools and projects not having CWEs included. There are several commercial and open-source that deem it unnecessary to include CWEs. This causes a greater challenge in prioritizing and managing vulnerabilities. For example, the SAST tool for Python, Bandit, does not provide CWE values when it identifies a flaw in your python source. This not only increases the chance of duplicates, but affects false positive management as well. And in a DevSecOps pipeline, this can be a  reason to even abandon security efforts. I am glad projects like the OWASP Application Security Verification Standard (ASVS) in its 4.0 avatar lists CWEs next to each item

CWE and CVE are both great projects. Without them, the security industry would definitely be wayyy more chaotic than it is currently. However, there is much to be done by our industry at large, to create a more functional, error-proof set of categories, taxonomies and weaknesses that can be used consistently by all the tools and projects across the industry, right from SAST Tools to Vulnerability Management tools. In addition, both these projects should consider making their datasets more easy to integrate into tools. Several folks use open-source security tools, and most of these tools lack this information. Easy Integrations could be a game-changer in the way vulnerabilities are identified and detailed.