Threat actors use vulnerabilities to launch their attacks. By exploiting vulnerabilities, attackers can gain access to systems, networks, and devices. Vulnerabilities enable attackers to steal and ransom sensitive and corporate information, as well as eavesdrop to confidential communication.
Vulnerabilities can be created as a result of software error, or as forced injections like SQL injection attacks and OS command injections. Other common vulnerability attacks are buffer and integer overflow, which involve the alteration of code by the attacker. Every day, more and more vulnerabilities are discovered. In 2019 alone, over 22,000 vulnerabilities were disclosed.
Due to the huge number of vulnerabilities, discovering and patching every single vulnerability can be an overwhelming task. The Common Vulnerability Scoring System (CVSS) was developed for the purpose of helping developers and security professionals assess the threat levels of vulnerabilities, and prioritize mitigation accordingly.
What Is a Software Vulnerability?
A software vulnerability is any issue in the codebase that can be exploited by attackers. This includes vulnerabilities created by bugs or those created by malicious changes to code, typically performed with malware or code injections.
Software vulnerabilities can provide attackers with the opportunity to steal data, infiltrate systems, and abuse resources. This is why it’s important for software development and testing teams to identify vulnerabilities before software release. It is also why teams need to create patches when vulnerabilities are discovered after release.
Examples of Software Vulnerabilities and Attacks
Many types of software vulnerabilities can be exploited. However, there are a few vulnerabilities that are more commonly exploited than others. These include the following.
SQL injection
SQL injection vulnerabilities enable attackers to use SQL statements to insert malicious code or commands. They do this by submitting code via forms or other web site inputs which the server then interprets in the same way as code supplied by the developers. This type of attack is possible when inputs are accepted from users without proper validation or restriction.
OS command injection
OS command injection, also known as shell injection, is a similar vulnerability to SQL injection. Attackers can exploit this vulnerability by tacking shell commands onto URLs used by sites to return information to the user. For example, adjusting a query in a URL to return sensitive information. Like SQL injection, these vulnerabilities can be exploited to gain access to your entire system.
Buffer overflow
Buffer overflow happens when you or an attacker try to write more data to your application’s buffer than is allowed by the storage capacity. By exploiting this vulnerability, attackers can add malicious code to your program, overwrite or corrupt existing data, or crash your application.
This is most frequently an issue with programs written in C or C++ since these languages do not have built-in protection against buffer overflow. This is in contrast to higher level languages like Python, Java, or C#.
Integer overflow
Integer overflow occurs when an integer is altered to a value that is larger than its allotted space allows. For example, if an 8-bit integer is used (allowing up to 256 values) and the integer is changed to 257. This can result in an integer value being converted to a smaller or negative number. Attackers can exploit this vulnerability to change a variety of program behaviors, including control looping, memory allocation, and copying.
Like buffer overflow vulnerabilities, this is an issue in lower level languages but not higher level ones. This is primarily exploited in C and C++ programs.
What Is the Common Vulnerability Scoring System (CVSS)?
CVSS is a set of open standards for scoring the severity of vulnerabilities. It was created by MITRE, and is used by a wide variety of vulnerability researchers, databases, and security professionals. The scale ranges from 0.0 to 10.0 with 10.0 representing the most critical vulnerability level. The most recent version of CVSS is CVSSv3, released in 2015.
The purpose of CVSS is to create a uniform method of identifying and addressing the threat associated with a given vulnerability. This enables security communities to more easily prioritize and collaborate on addressing vulnerabilities.
How CVSS Scoring Works
When CVSS scores are assigned, the score is determined by a combination of elements. These elements include the base score, temporal score, and environmental metrics. Only the base score is required to create a CVSS score but it is recommended to use all measures for greater accuracy
Base Score
The base score is a representation of the inherent qualities of the vulnerability. These qualities are not dependent on time or a vulnerability’s environment. It is composed of three subscores—exploitability, impact, and scope.
Exploitability subscore
This score is based on a combination of the following metrics. These metrics define how easily a vulnerability can be exploited.
- Attack vector (AV)—describes how easily a vulnerability can be accessed by attackers. Lower values are given for vulnerabilities that require proximity to a system while higher scores are given for vulnerabilities that can be exploited remotely.
- Attack complexity (AC)—describes necessary conditions for exploitation. Lower scores are given when reconnaissance or additional information is required from an attacker while higher scores are given when vulnerabilities can be easily or repeatedly exploited.
- Privileges required (PR)—describes the level of privilege needed to exploit a vulnerability. Lower scores are given when higher-level (i.e. administrative) privileges are needed while higher scores are given when no or minimal privileges are required.
- User interaction (UI)—describes whether exploitation is dependent on the actions of a user. For example, the installation of an application. This metric is binary. Either user interaction is required or not.
Impact subscore
The impact score is a representation of the effects of an exploited vulnerability. It includes increased access, escalation of privileges, and other negative outcomes and measures the change from pre exploit to post. The impact subscore is composed of three elements:
- Confidentiality (C)—describes the impact of the exploit on the loss of confidentiality of data. Scores include none, low (some loss limited by type of information or breadth), and high (total loss or a serious, direct impact).
- Integrity (I)—describes the impact of the exploit on the trustworthiness and truthfulness of data. Scores include none, low (limited modification of data or no control over impact), and high (total loss or direct consequence).
- Availability (A)—describes the impact of the exploit on the availability of the affected component. Scores include none, low (reduced performance or no serious impact), and high (loss of availability or serious impact).
Scope subscore
Scope is a metric that describes whether a vulnerability has an impact on components outside of its security scope. A security scope is the bubble of components that fall under a single security authority or set of access controls. When attackers can exploit vulnerabilities to manipulate components outside of the scope of the vulnerable component, the severity of a vulnerability increases.
Temporal Score
The temporal score is a representation of the existence of known exploit techniques, patches or updates, and confidence in the vulnerability description. It is based on:
- Exploit code maturity (E)—describes the availability of attack tools and methods to exploit the vulnerability. Scores from low to high include proof of concept, functional, unproven, high, and not defined.
- Remediation level (RL)—describes the level of remediation or negation available to correct a vulnerability. Scores from low to high include official fix, workaround, temporary fix, unavailable, not defined.
- Report confidence (RC)—describes the degree of certainty of the accuracy of the vulnerability report. Scores from low to high include unknown, reasonable, confirmed, not defined.
Environmental Metrics
Environmental metrics enable you to customize CVSS scores based on how critical a vulnerable component is to your organization. These metrics are modified versions of the metrics used to calculate the base score. The modifications are made according to a component’s placement in your system and your security configurations and practices.
Conclusion
Because there are so many vulnerabilities, assessing risk levels can be a difficult challenge. Is this vulnerability an immediate threat or is there another vulnerability that requires immediate patching?
The CVS system uses assessments like base score, temporal score, as well as environmental metrics, to provide a standard risk level for each vulnerability. This standard is then used by the community of professionals, when assessing the risk levels of vulnerabilities. CVSS v3.1 is the latest update of the CVSS standards, which you can use when prioritizing mitigation.
Infrastructure Visibility and Monitoring Trial
With employees now working remote due to quarantining efforts, business’s IT organizations are stretched to the limit with new challenges and without the tradition visibility they have into their infrastructure. CCSI would like to shine a light into the new dark and previously underutilized areas of your organization’s infrastructure. Whether it is a now overworked VPN gateway or a server that was just moved to the cloud to try to gain better access for remote users, CCSI can shine a light on the performance and availability of these services and alert staff to any problems.
A 30-day no cost Proof of Concept of our Infrastructure Visibility and Monitoring solution. This includes:
- Continuous monitoring of up to 10 devices either on premise or in the cloud
- Dashboard access
- Alerting via email, SMS, Slack, MS Teams, PagerDuty, VictorOps, etc.
Author Bio: Eddie Segal is an electronics engineer with a Master’s Degree from Be’er Sheva University, a big data and web analytics specialist, and also a technology writer. He writes on subjects ranging from cloud computing to agile development to cybersecurity and deep learning. He
Eddie is a guest blogger, all opinions are his own.
