As you and your colleagues are shuffling through massive vendor presentation areas at the conferences, chances are that you’ll see one or more of the “C” words (no, not that one): CWE & CVE. 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 CVE, and CWE with some examples and let us look at their uses, abuses and how you should evaluate your Vulnerability Management Strategy on the basis of these terms.
Let’s start with Vulnerability. More specifically, one 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 serialised payload in the body of the request (JSON) and trigger Remote Code Execution. Let’s use this example to explain concepts of CWE, CVE and CVSS.
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 release 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.
As you probably have realised 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.
| This Drupal Vulnerability has been given an ID of CVE-2019-6340.
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, it’s 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.
Learn more: Organising vulnerabilities by category & CWE numbers
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. It is really a categorisation system for vulnerabilities and weaknesses in software. Each category of the 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 categorisation system. CWE Information is hierarchically organised as:
For example, CWE has a View called “Development Concepts”, which is organised 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 child of 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.
The Drupal Scenario – Explained
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 categorised based on the Primary Attack Vector, which they largely are. In this case, clearly, the primary attack vector was Insecure Deserialisation, which is CWE 502. And while this looks like a minor issue, when managing vulnerabilities at scale, this can lead to major inaccuracies.
Uses and Abuses
Most Vulnerability Management Platforms for Apps, use the CWE as the ID that they correlate around, including us, with our product Orchestron, which is an Automated Vulnerability Correlation and Management Platform. The challenges that we (and likely several others) faced were:
- Tools giving conflicting CWE-IDs for Vulnerabilities. For example, BurpSuite might categorise a NodeJS Code Injection triggered by an
eval()function with CWE 94 (Code Injection) while OWASP ZAP, might categorise 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 categorising the flaw, regardless of the tool you throw at it.
Read more: An analytics company used enhanced vulnerability metadata to fix their source code and boost their AppSec
- Incorrect CWE categorisation affects the entire life-cycle of a Vulnerability. Let’s take the Drupal flaw itself. By categorising it as CWE-20, Improper Input Validation, developers might not apply the most appropriate fix.
However, if it had been categorised as
CWE-502(Deserialisation of Untrusted Data), which IMO is the right CWE, developers might actually identify a fix which is more specific and deserialisation centric.
- 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 prioritising 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 way 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 data-sets 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.