In the world of information security, there is one acronym that stands above the rest: CVE®. It stands for Common Vulnerabilities and Exposures, and represents a mechanism to measure, rate, publish, and compare different software vulnerabilities. The use of software in business operations, IT, and even our personal lives has become absolutely pervasive, representing a significant risk to organizations and individuals alike. Businesses and individuals have become reliant on the internet, web applications, mobile apps, streaming services, e-commerce systems, and social networks. Therefore, any vulnerabilities that may exist within these platforms represent a threat to the data those systems store, process, or transmit. The CVE program, launched by the MITRE Corporation in 1999, exists to standardize the process of identifying, reporting, risk-rating, and publishing identified software security weaknesses.
Before the CVE system hit its stride, there was no standardized mechanism for reporting vulnerabilities. If a researcher, or a “hacker,” identified a security weakness in a piece of software, there was no formal way to make this information available to a wider audience. Processes were fragmented, often involving one-to-one communications between the security researcher and the software vendor. While these communications often resulted in the availability of a patch to mitigate the risk associated with the identified vulnerability, many users will fail to apply the patch, and would have no idea that the version of the software they are running might be vulnerable to attack. Further, the lack of a formal system meant that there was no standardized methodology for calculating the risk associated with a vulnerability. This made it nearly impossible for organizations to make informed decisions regarding remediation prioritization or risk acceptance.
As the number of reported security vulnerabilities, and the sheer amount of available software, began to skyrocket in the mid 1990’s, MITRE recognized the need for a more formal approach, and created the CVE program. Under this program, identified security vulnerabilities must undergo a standard review and rating process, as well as a standard process for public disclosure. Each of these components is critical to ensure that the vulnerability information reaches the appropriate audience.
The first step in this process is vulnerability discovery, where a security researcher, hacker, bug bounty hunter, or other user identifies a security weakness in some piece of software. For example, perhaps a researcher is reviewing the software that lies beneath a commercial accounting application that is used by hundreds of medium-sized organizations around the world, and finds that they can bypass authentication by “injecting” some database query-like code into the password field. A vulnerability like this is known as “SQL Injection,” and is a relatively common class of software vulnerabilities. If the security researcher is worth his or her salt, they will report the vulnerability to the vendor so that it can be fixed, BEFORE the vulnerability is publicly disclosed via the CVE Program, though this is not a prerequisite.
The researcher could then submit information related to this vulnerability to MITRE, or an associated CVE Numbering Authority (CNA), for review and assignment of a formal CVE identifier. These submissions are reviewed to ensure that they contain information that would be required to identify the vulnerability in the wild, such as the software vendor name, vulnerable version number, and other technical data that would allow replication of the issue. In this case, the researcher may also submit the actual query they used to bypass authentication. The vulnerability is then rated across a number of areas on the Common Vulnerability Scoring System (CVSS), with the end result being an overall risk rating. Because this score is calculated the same way across all vulnerabilities, it represents a common metric by which most vulnerabilities can be rated and compared with one another.
The CVSS is a complex system in itself, but at a high level, it’s a mechanism to identify just how “risky” a given vulnerability is. For example, it takes into consideration whether a vulnerability can be exploited remotely (i.e. over a network), or if it requires local access to the vulnerable system. Similarly, it takes into consideration whether or not exploitation of the vulnerability requires authentication (i.e. a username and password), or if the vulnerability can be exploited by a user without requiring authentication. Other metrics involved in the CVSS calculation include: attack complexity, confidentiality impact, integrity impact, and availability impact. These last three metrics capture the result of successful exploitation, indicating if the vulnerability may impact the confidentiality of data, the integrity of data, or the availability of data or the system as a whole. After some mathematics, one will arrive at a final risk rating, on a scale of 1 (very low risk) to 10 (critical risk).
The final step in this process is public disclosure. This may seem counterintuitive, because making information about a vulnerability public may lead to misuse of that vulnerability by malicious threat actors. However, it’s been proven time and time again that the information security industry needs collaboration and communication of identified threats to protect the industry as a whole. Security researchers, red teamers, penetration testers, security analysts, and software developers can all leverage the rich vulnerability data that exists within the CVE database to identify known threats in existing software, and learn from these “mistakes” to write secure code from the get-go. Once this process is complete, a formal CVE identifier is assigned to uniquely identify the specific vulnerability in question with the standard format: “CVE-YEAR-#####,” and all the information is publicly posted in multiple sources of vulnerability data on the internet, including MITRE’s own CVE database, as well as the National Institute for Standards and Technology (NIST) National Vulnerability Database (NVD).
During penetration testing engagements, OCD Tech has identified and publicly disclosed three (3) new CVEs over the past two years. By working with the software vendor to fix the vulnerability, and MITRE for public disclosure, OCD Tech seeks to maximize the reach of each vulnerability discovery for the InfoSec community as a whole, while minimizing risk to existing users of the vulnerable software. See the following vulnerability disclosures for more information on the vulnerabilities discovered by OCD Tech:
CVE-2018-11628
CVE-2019-7004
CVE-2019-19774
CVE-2020-12679
CVE-2020-13998
