"I found a vulnerability! Now what?"
"Can I request a CVE? How do I do that? Who should I request it from?"
"Do I have to notify the vendor first or can I request it right away?"
These are just some of the questions we get asked when someone finds a vulnerability and decides they want to submit a CVE. With this article we decided to answer all frequently asked questions by providing guidelines on all the steps to follow.
Without getting lost in small talk, let's begin.
The purpose for which the Common Vulnerabilities Enumeration (CVE) was created is clear: to identify, define and catalog publicly disclosed software security vulnerabilities. It is already clear from here that not all vulnerabilities have the relevant CVE, because not all vulnerabilities are disclosed, but the reason is not only this; not for all vulnerabilities is it possible to request a CVE.
According to the glossary on the CVE Program official website , a vulnerability is:
An instance of one or more weaknesses in a product that can be exploited, causing an adverse impact on confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.
Thus, basic requirement is that the vulnerability is on a product. To simplify, we can say that we can request a CVE for any software or hardware whose name, vendor, and version number we can specify. For this reason, if, for example, we found an SQL injection on the neighborhood mechanic's website, we could not request a CVE because a website does not have public versioning and because once the vulnerability is fixed, it simply ceases to exist for anyone, with no way to go back, so it would not make sense to keep track of it on a public system.
Different situation if instead we found a vulnerability on a website that is an instance of a specific version of open source software. In that case, even if the vendor fixed the vulnerability, there would still be the possibility that some user would continue to use an outdated version, thus still vulnerable.
Who can submit a CVE?
"Do you need to be a business or a recognized professional to submit a CVE?"
No, anyone can apply for a CVE, for example:
- Penetration Testers who stumble upon a vulnerability during an engagement;
- Security researchers actively looking for vulnerabilities in software;
- Developers finding vulnerabilities in code they wrote themselves (yes, this should be regulated...);
- Casual surfers of Russian cybersecurity forums unearthing details of a now-public vulnerability for which a CVE has not yet been requested;
- …
From whom should a CVE be submitted?
This one is easy: the list of CVEs is maintained by MITRE, so a request must be submitted only to MITRE. Right? Wrong.
Considering the trend in the number of CVEs required over time, it became necessary to implement a more scalable system.
Broadly speaking, we can think of the hierarchy on which the CVE Program is based in this way: the CVE Program at the top designates organizations as responsible for a specific area of expertise; these are the so-called Root CNAs. In turn, Root CNAs recruit, train and manage other Root CNAs, CNAs or CNA-LRs. CVE Numbering Authorities (CNAs) are entities authorized to assign and publish CVEs within their specific area of responsibility. CNA-LRs (CVE Numbering Authority of Last Resort), as the name implies, are the last resort to turn to. These are CNAs authorized by a Root CNA to assign and publish CVEs within that part of the scope of the Root CNA itself, but which is not already covered by another CNA.
Thus, in order to know from whom to request our CVE we should look for the most specific CNA possible for the product on which we found the vulnerability. If there is no specific CNA, then we need to address the most specific CNA-LR possible. If there are no specific CNAs or CNA-LRs, then we can request CVE from the CNA-LR daughter of the Root CNA of the whole hierarchy: the MITRE.
Said in this way it sounds like a very long and cumbersome process, but in practice it is quite simple and can be summarized as follows:
- It opens the official website of the CVE Program to the page about the partner list;
- You enter in the search bar the name of the vendor related to the product on which a vulnerability was found;
- If we get a result we have found the CNA from which to request the CVE;
- If we get no results (99% of the time) we submit to the CNA-LR "MITRE Corporation."
How do you request a CVE from a CNA?
Clicking on the CNA of interest from the list of partners provides us with details of the CNA, including scope, Root CNA of reference, etc. Among these details we are interested in the links in the "Steps to Report a Vulnerability or Request a CVE ID" section:
Each CNA has its own disclosure policy and method for requesting a CVE. Some present an online form, some require an email to be sent, some require a single step, and others an intricate tangle of Web pages worthy of an OSINT challenge.
How do you request a CVE from the CNA-LR "MITRE Corporation"?
In the case where the CNA of reference is "MITRE Corporation," the way is simple. By clicking on the link in the partner list and then to the link in the detail tab we are taken to the CVE Form. Just choose "Report Vulnerability/Request CVE ID" in the first menu item and it will appear the form, complete with all the fields to be filled in, but not before some warnings:
- the first tells us how to prevent their response from be marked as spam;
- the last one asks us to confirm that we have verified that there is no more appropriate CNA to send the request to and that the vulnerability we are reporting has not already been assigned a CVE;
- the second and most important warning tells us that once we will be assigned a CVE, it will appear in the public list of CVEs as "RESERVED" and without any details. In order for the CVE to be made public, it will be necessary to provide at least a link to a page on which the details of the vulnerability are provided (the manufacturer's "Advisory" page, a blog article, or an issue on Github will suffice).
What information are required in the CVE Form?
Il CVE Form enumera e spiega ogni campo dettagliatamente, ma vediamoli velocemente insieme per fare qualche considerazione in più.
Campi obbligatori
- Vulnerability Type, this field could have been left blank to allow users to write the CWE that best describes the vulnerability, but for some reason the MITRE Corporation decided to make it a drop-down menu that reduces the existing 938 CWEs to a list of only 10 CWEs plus the bonus field "Other." Among these ten we find Buffer Overflow (CWE-119), Cross Site Scripting (CWE-79), SQL Injection (CWE-89), Directory Traversal (CWE-22), XXE (CWE-611), Insecure Permissions (CWE-276), Incorrect Access Control (CWE-284), Integer Overflow (CWE-190), CSRF (CWE-352), and Missing SSL certification verification (CWE-599).
- Vendor name
- Name and version of the vulnerable product
Is that all? Yes. Potentially a valid request for a CVE might be something like "There is a buffer overflow on Mozilla Firefox v123.0.1." Obviously, such a request would be too general to be accepted; moreover, CNAs have to be subject to specific rules (CNA Rules) in which it is specified that a CVE to be valid must contain:
- Type of vulnerability
- Vendor name
- Name and version of the vulnerable product
- Vulnerability description
Yeah...I didn't misspell it, that's exactly what it is...the description is an optional field, but without it the report MUST be rejected. How is this possible? Because, as we shall see, the description we provide is only a suggestion, and it will then be up to those who receive the report to write an appropriate one. Obviously with so little information it is impossible to write a description that complies with the rules, so the only way would be to reject the report.
Optional fields
- Has the vendor confirmed or acknowledged the vulnerability? If we have contacted the vendor to make them aware of the vulnerability and it has been confirmed, answering "yes" will speed up the CVE assignment process because according to the CNA Rules "if a product owner considers an issue reported on one of its products to be a vulnerability, then that report MUST be considered by the CNA as a vulnerability." Otherwise, it will be necessary for the CNA to make internal evaluations that will take time and may cause you to reject the CVE application;
- Attack type, this field allows the choice between "remote," "local," "physical," "context-dependent," or the ever-present "other." The longer the distance from which the vulnerability can be exploited, the higher the CVSS score that will be assigned to the vulnerability;
- Impact, what do we get if we exploit the vulnerability? We can choose from "Code Execution," "Denial of Service," "Escalation of Privileges," "Information Disclosure," and again "Other."
- Vulnerable components, here we can specify, for example, the name of the file or function that contain the vulnerable code. As we will see, this is information that needs to be included in the description, but then why are they asking us for it again? because remember that the description we provide is only a suggestion, and this information is useful in constructing an appropriate description for the CNA Rules;
- Attack vector, here we need to specify how the exploitation of the vulnerability takes place. In case of a SQLi, for example, the vector could be "to exploit the vulnerability the attacker must send a properly crafted HTTP request," or in the case of a Stored XSS it could be "to exploit the vulnerability the victim user must open page X containing the malicious payload inserted by the attacker," etc. A great level of detail is not required, and in general we could generalize by saying that we could write a sentence like this, "to exploit the vulnerability an [actor] must [action] [conditions]";
- Suggested vulnerability description to be used for the CVE, clicking on the information icon in this field provides us with a link to the"Key Details Phrasing" PDF that contains all the specifications that the description will need to have in order to be published. Thus, if we follow the specifications the CVE will most likely be published with our description, otherwise one will be written by those who will evaluate our report, based on the information entered in the other fields.
Two very similar generic templates are proposed in the paper, which are:- "[VULNTYPE] at [COMPONENT] at [VENDOR] [PRODUCT] [VERSION] allows [ATTACKER] to [IMPACT] via [VECTOR]."
- "[COMPONENT] at [VENDOR] [PRODUCT] [VERSION] [ROOT CAUSE], which allows [ATTACKER] to [IMPACT] via [VECTOR]."
- Credits, the name of the person or company that found the vulnerability. Assuming you are requesting a CVE for a vulnerability found by someone else, the other person's name should be entered here, not yours. Remember, however, that this information is only visible in the CVE JSON 5.0 format, but it is not usually included on websites such as CVEdetails.com;
- References, here we will be able to specify links to useful pages, such as the vendor or product page, advisories or even blog articles, etc. If these links include links to public details of the vulnerability, the CVE, if accepted, will be published immediately, otherwise it will remain in the "RESERVED" status until we update the CNA of the publication of the details;
- Additional information, this is a free field; any additional information we would like to give to CNA can be written here.
I applied for CVE, now what?
Having come to this point, all we can do is wait. The request will enter the queue of requests to be handled, a very long queue if we apply to the CNA-LR MITRE Corporation. Once our request is taken care of we will be reserved a CVE ID, which is the initial status for obtaining a CVE. Reserved state means that our vulnerability is assigned an ID in the format CVE-YYY-NNN (with YYYY the current year and NNNN a sequence of at least 4 numbers) that will be used internally by CNA for communication and coordination of verification and management activities. However, the reserved state is not final, and our reporting may still undergo many changes.
If we have not provided all the necessary details, we can also do so later with updates to the request via the CVE Form by selecting the menu item "Request an update to an existing CVE Entry").
When all the details are provided and CNA has made the necessary checks against the compliance of the request, then the CVE can be published in the CVE List.
All communication at these stages will be by email to the address you are asked when you begin filling out the CVE Form.