Criminals want your data. One of the many ways they can obtain this data is by finding and exploiting vulnerabilities in software products that store your data. Since the adoption of the internet, there have been many such instances where criminals have exploited vulnerabilities, resulting in stolen banking information, health information, and corporate and state secrets.

Before we examine vulnerabilities, let’s get a good idea of what software is. It’s best to think about software as instructions that tell a computer what to do. Software can include any instructions or programs written for a device or machine. These instructions enable and empower users to do work such as word processing, sending emails, browsing the internet, and using social media sites such as Facebook and Twitter. Software isn’t necessarily limited to just user-facing components in the form of applications. Software is built to power hardware components and microcontroller devices. Think about modern cars and consumer electronics – if you’ve bought anything with any semblance of computing technology in the 21st century, it’s likely software has been written and is running these devices.

Software vulnerabilities, simply defined, are the defects and shortcomings of software. Think of vulnerabilities as logical errors or loopholes in the instructions we give to our computers. These errors or loopholes can impact three critical areas concerning vulnerabilities in software. In the information security industry, this is commonly referred to as the CIA Triad. CIA is an acronym for confidentiality, integrity, and availability, as illustrated in the following figure:

Figure 1.1 – The CIA Triad

Let’s discuss these factors because they’ll be essential to understanding how vulnerabilities are organized by severity.

The CIA Triad

Confidentiality is the extent to which data is kept private and hidden. Vulnerabilities that can impact this vector often manifest in ways that allow unauthorized users to view or export data they should not have access to. Exploits that impact this vector often disclose data that should not otherwise be disclosed.

Integrity refers to whether data is the same as when it was originally inserted into the software. Vulnerabilities that impact integrity often result in the changing of data. Consider the importance of information related to your banking or health information and how the integrity of those values is important. Exploits to this vector often include changing values from their original sets in a way that benefits the goals of an attacker.

Availability relates to whether the data can be accessed. Vulnerabilities in availability often result in downtime of the application or the disablement of certain features. Bad actors exploiting these vulnerabilities aim to disrupt the access or use of data and systems. Exploits here often result in legitimate users not being able to access data.

When thinking about vulnerabilities, it’s important to know that they impact one or more of these factors in a way that is detrimental to the software. So, now that we understand what the three core concepts are in weighing and measuring vulnerabilities in software, how do they get organized and prioritized?

Organizing impacts

To help us organize and prioritize vulnerabilities, security researchers have developed methods and systems for scoring the impact of vulnerabilities. The most common scoring method you’ll come across is the Common Vulnerability Scoring System (CVSS). The CVSS is an open source specification acting as an equalizing language that helps explore the severity of vulnerabilities and the impacts on the CIA Triad. In addition, the scoring system can be used as a sort of calculator that defines key base metrics about how bad vulnerabilities are. The calculation considers the following factors:

• Impact on confidentiality
• Impact on integrity
• Impact on availability
• How the vulnerability is exploited
• Complexity of the exploit
• Access needed to exploit the vulnerability
• Whether user interaction is required for exploitation

This set of data is calculated with a CVSS calculator (see Figure 1.2) and is usually attached to vulnerabilities in a vulnerability database:

Figure 1.2 – An example of a CVSS score calculator

While we’ll dig into different databases in future chapters, it’s important to be aware of the most common vulnerability dataset, the MITRE Common Vulnerabilities and Exposures (CVE) list. Vulnerable software that has been publicly disclosed is assigned ID numbers through the CVE list. The CVE list feeds into large security vulnerability databases such as the US National Vulnerability Database (NVD) and many others. Each vulnerability in the list is simply called a CVE. Each vulnerability is assigned a CVE ID number, a CVSS score, and details relating to the vulnerability such as exploitation, research, a brief description of the vulnerability, and any other related information. A typical CVE record will look like this:

Figure 1.3 – An example of a CVE record, CVE-2021-2021

Every year, thousands of CVEs are added to the MITRE CVE list, then reported to the NVD. These vulnerabilities can impact various software, services, hardware, and more.

Note

The CVE list, CVE records, and subsequent datasets do not track vulnerabilities for software as a service (SaaS) products. For a vulnerability in this list and dataset, the software in question must be a customer-controlled product. So, for example, Google Docs is an office productivity solution that primarily operates as a web application that does not consist of installed elements under user control. Therefore, Google Docs is not eligible for CVE assignments and registration in vulnerability databases that house CVEs. Similarly, office productivity applications such as Microsoft Office now have similar cloud-based services – but they also provide thick-client installs of applications like Microsoft Word. In this example, the version of Microsoft Word that is installed on a computer is eligible for publishing on the CVE list, but not the cloud-based version.

Now we know how to find information on vulnerabilities and how that research is organized. So, how can security professionals leverage these resources?

Many of the exploited vulnerabilities used today are known vulnerabilities registered in the CVE list and have an associated vulnerability score, CVE ID, and details about the vulnerabilities. As of writing this sentence, over 20 million vulnerabilities have been registered in this list. While it’s entirely possible to gather information about the software used and then cross-reference it by searching through a CVE list, the practice would be relatively inefficient and impractical to do regularly.

To solve this problem, software developers have built solutions to detect these vulnerabilities. These kinds of applications are typically referred to as vulnerability scanners. Despite what you might be told by an enthusiastic vendor on the latest security features of their vulnerability scanner, these scanners are typically passive and do not discover otherwise unknown vulnerabilities. Instead, they only identify known flaws by running scripts that search for information about software. The scanners then compare versions of software to the published list of vulnerabilities to determine whether there are known vulnerabilities in the software installed.

Software development teams have been able to get these tools to work with detecting hardware, software versions, and even vulnerable networking equipment such as firewalls. In addition, vulnerability scanning systems let system administrators know what software needs security fixes to avoid the exploitation of vulnerable software. Modern systems usually do this in well-organized ways that prioritize the highest risk and provide reports and dashboards that various audiences can consume.

Vulnerability scanners allow cybersecurity professionals to identify, classify, and prioritize risks. There are many vulnerability scanning tools available to help identify these vulnerabilities. So, what are these common vulnerability scanning tools?

Common vulnerability scanning tools

This section introduces some of the common vulnerability scanning tools that are used by security practitioners. The list is not exhaustive, but it should give you a solid introduction to the basics of these tools and help with your understanding of the common tooling you’ll likely find when you begin researching and using these tools.

Nmap

Nmap or Network Mapper is a free, open source network scanning tool created by the software developer Gordon Lyon. Take a look at the type of output Nmap typically generates when a user runs a scan:

Figure 1.4 – A screenshot of Nmap output using the Nmap-vulners script

The tool can scan for a range of different services on a target host. It can be used to scan a single host or multiple hosts on a local area network or the internet. To say it’s a vulnerability scanning tool is a bit reductive to the complexity of Nmap, but it’s often used with scripts that specifically probe for vulnerabilities. Command-line inputs drive it, and scripts must be specifically requested to determine whether something is vulnerable.

OpenVAS

The Open Vulnerability Assessment System, more commonly known as OpenVAS, is a free, open source tool spun off the commercial product Nessus. OpenVAS’s interface is pictured in the following figure with the Greenbone Security Assistant interface:

Figure 1.5 – The OpenVAS Greenbone Security Assistant dashboard

OpenVAS can help system administrators scan for well-known vulnerabilities against various operating systems and platforms. While it’s open source, it’s a well-supported tool. However, critics or detractors of OpenVAS often point out that the support for enterprises is poor, and extracting data out of the system can be difficult.

Nikto

Nikto is an open source command-line tool that can scan a webserver for vulnerabilities. Its usage is strictly limited to web servers and will require open web services to be of use. The output and interfaces are similar to Nmap, as seen in the following figure:

Figure 1.6 – A screenshot of Nikto output from the command line

Nevertheless, it’s a great tool to use to check in on websites to get a better idea of what they might have for vulnerabilities. Much like Nmap, the output is limited, and detractors anecdotally point out that the rate of false positives is high.

Nessus

Nessus is one of the most deployed vulnerability assessment solutions across the information security industry. The easy-to-use interface and dashboard looks like this:

Figure 1.7 – Nessus scan example

Nessus works much like OpenVAS, allowing an operator to detect and audit the configuration and vulnerabilities on client computers, web servers, and more. This commercially available product also offers easy-to-export reports on the data it finds and various plugins that extend the scanning tools’ functions.

Rapid7 Nexpose

Rapid7 Nexpose is a vulnerability scanner that can scan various targets for a wide range of vulnerabilities and misconfigurations. Take a look at the dashboard to compare and contrast it with Nessus in the following figure:

Figure 1.8 – Rapid7 Nexpose dashboard

It provides operators with a dashboard of results and tie-ins with other Rapid7 tooling used by penetration testers.

Qualys Vulnerability Management

Qualys Vulnerability Management is a commercial vulnerability scanner. Security analysts use this tool much like the other scanners previously mentioned. This aids in assessing the severity of the vulnerabilities so that they can be prioritized and corrected. It works much like OpenVAS, Nessus, and Nexpose.

Note

However powerful security vulnerability scanners are, they are strictly limited in their ability to search through their databases for known vulnerabilities. If there’s not a scripted check for the vulnerability, it cannot be detected.

Now that we’ve talked about vulnerability scanners, let’s get up to speed on the common kinds of software vulnerabilities you’ll see in the wild.

While an exhaustive list of common software vulnerabilities is out of scope for this book, we should cover some of the most common software vulnerabilities that are being found and exploited. We’ll split this up into two separate groups, web applications and client-server applications.

Web applications

Web applications are one of the most common entry points where organizations get breached. One of the most notable breaches of all time is the Equifax data breach in 2017. This breach occurred because Equifax had a vulnerable website that got exploited. This exploitation of vulnerable software was chained together with other vulnerabilities and exploits to ultimately result in the theft of confidential data. Organizations commonly have websites that feature tools and applications that help them conduct business with their customers and other organizations. These are just some of the common kinds of vulnerabilities found in these popular and widely adopted technologies.

Broken authentication and authorization

Broken authentication and authorization are one of the more common issues found in modern web applications. As a result of the vulnerability, attackers can access data they shouldn’t be allowed to access through a valid account to the website or no account at all. A good example of broken authentication would be if an attacker could bypass the login page for the website to access and or manipulate data that doesn’t belong to them. In contrast, broken authorization might result in an attacker logging in to that website with their own account, but when they access their account information, they could manipulate the application session to access the account information of another user.

Cross-site scripting

Cross-site scripting (XSS) is a technique used to inject malicious content into a website that can be used to run arbitrary JavaScript on a user’s browser session. Attackers do this by finding poor input validation in code. This can be accomplished by finding places on websites that reflect information back to the users either through persistent storage or reflected values that can be present in a URL. There are three widely accepted variants of this vulnerability we’ll briefly discuss:

• Persistent XSS: This vulnerability is exploited when users load websites that contain stored values with malicious JavaScript. To exploit this, attackers find places to submit data into the application in a way that saves those values as valid JavaScript, which is then, in turn, reflected back to a user.
• Reflected XSS: This variation of the XSS vulnerability allows attackers to exploit vulnerable inputs by giving victims URLs that contain malicious JavaScript. Typically, this kind of vulnerability is commonly present in search functions of websites.
• DOM-based XSS: This vulnerability exists when there is poor input handling in JavaScript, which exploits controls in something called the Document Object Model (DOM). The DOM is a representation of windows and elements on a website and how data flows through these objects. To exploit these vulnerabilities, attackers need to insert malicious JavaScript, which can take advantage of how the objects are processed.

SQL and NoSQL injection

SQL/NoSQL injection is a type of vulnerability that exploits queries made to a connected database. Attackers exploit this kind of vulnerability by manipulating how data is queried in forms and/or requests to the server. When used, the vulnerability results in the disclosure of data such as passwords and personal information. In some cases, these vulnerabilities can be exploited in a way that allows an attacker to take over the underlying server that hosts the database. A variant of this vulnerability referred to as NoSQL injection is related to similar methods used to exploit non-tabular database systems that are connected to applications. The techniques have similar results but are executed in very different ways.

Command injection

Command injection is a type of vulnerability that is a lot like SQL injection. In command injection, though, attackers attempt to insert values into fields or processes in the web application that, if exploited, can run arbitrary commands on the server. This can give an attacker the ability to take complete control over the server and provide them with a foothold into networks they may otherwise not have access to.

Cross-site request forgery

Cross-site request forgery (CSRF) is a vulnerability that, when exploited, can cause users to perform actions for attackers. Standard exploitation techniques involve attackers sending users malicious links that serve requests if used by a user. One of the expected outcomes of distributing these malicious links to victims is actions that change the victim’s password, email address, or other account information to initiate an account takeover.

Server-side request forgery

Server-side request forgery (SSRF) is a type of attack that exploits the trust that a server has in its client. It’s very similar to the CSRF vulnerability type, but the specific focus of this vulnerability is the server and the trust it has with clients and other servers instead of the end user. Exploiting this type of vulnerability can result in the server making authenticated elevated privilege requests to itself or other internally accessible endpoints.

Business logic flaws

Business logic flaws are vulnerabilities introduced by failing to anticipate unexpected behavior or input in routine business processes. There’s never a typical way to exploit these vulnerabilities. These vulnerabilities don’t always follow similar patterns because the application developers always design the logic that dictates how an application ought to be used, and any attack patterns that emerge from the design must be considered on a case-by-case basis. Software developers often introduce these vulnerabilities by not handling the unexpected inputs and states that users may encounter.

Note

What’s prevalent in web application security has changed significantly over the last decade. For the most up-to-date list of common security flaws found in web applications, please refer to the OWASP Top 10 list, which is updated frequently at the following link: https://www.owasp.org/www-project-top-ten.

Client-server applications

Unlike web applications, which seem to have incoming and outgoing trends in software flaws, traditional client-server applications, often known as thick clients or thick applications, change less frequently. These applications differ due to the fact that they are primarily used on an operating system, and the application typically needs to be installed or configured to run on that operating system. These applications often power web application components in server deployments, but they also help users accomplish tasks locally with the processing power of their workstations.

Information disclosure

This happens when applications require passwords, API keys, and personal information to be stored. Sometimes these details are stored in plain-text or encoded files, which can easily be accessed through decompiling applications or decoding the content.

Process hijacking

When applications are installed on operating systems, oftentimes, they are configured with incorrect or insecure permissions on their files, scheduled services, libraries, and more. Attackers can take advantage of these configuration problems by hijacking these components, often impersonating a legitimate application or user session.

Cleartext communications

This vulnerability refers explicitly to communications the application might be making over network protocols. Like our previous category of information disclosure, applications might be transmitting information that is unencrypted and contains sensitive values, which can be exploited if an attacker can intercept the network communication between the client and its network host.

Web application vulnerabilities

Sometimes, traditional applications install web applications that allow users to interact with components of the locally installed application. With these kinds of applications, even if the application is accessed locally, all the issues previously mentioned in the web application section can apply here.

Now that we have a good idea of what kind of vulnerabilities we might find out in the wild, let’s examine the life cycle vulnerabilities typically have.

The life cycle of vulnerabilities isn’t always linear, but there are common themes that emerge, which we will explore through a discussion of the phases of this cycle. We’ll talk about these in four stages that often overlap and or begin their execution simultaneously, as shown in the following figure:

Figure 1.9 – The stages rarely follow a specific order, but they are consistent through the inception and depreciation of vulnerabilities

Let’s explore each stage in detail over the next few sections.

Inception

The first stage we’ll cover is inception. In the life cycle, vulnerabilities get introduced through malicious or non-malicious activities during the inception stage. For example, developers might write insecure code, system administrators could deploy weak configurations, or malicious actors may purposefully embed vulnerabilities and back doors into the software. Understanding inception at times is difficult due to the various paths that vulnerabilities take when they’re introduced.

For software and systems to be deployed securely, engineers need to know how to securely write code and deploy systems, or they should receive guidance from security practitioners. Security literacy, or rather the lack of it, may be why vulnerabilities get introduced, but it’s not usually the only contributing factor. Developing software and maintaining operations is expensive, and organizations often seek to save money through various practices meant to accelerate product deployment. As a result, software developers and operation engineers are often stretched thin on projects, and products are rushed to get features and functionality embedded to acquire new customers or satisfy current customers. This pressure combined with poor security culture and/or education in the organization can often lead to outcomes where steps are skipped or security is placed on hold to ensure the product makes it to market. Remember, security always comes at a cost, and that cost often gets cut when businesses push to get applications or features to customers quickly.

Another factor to consider is the complexity of software systems and their deployed or supported infrastructure. If a system is complex, there are more opportunities for weaknesses to be introduced into the configuration and code.

Finally, malicious actors inserting vulnerabilities into code isn’t as uncommon as one might think. It can take a few different forms. Attackers are often aided by an insider threat, such as a disgruntled employee who sells access to attackers. In other instances, sophisticated state-sponsored attacks often gain a foothold into the software of companies they seek to exploit. In 2020, such a campaign made worldwide headlines when attackers targeted the business software, SolarWinds Orion, resulting in CVE-2020-10148. This vulnerability identified highly sophisticated actors implementing a trojan in the Orion software, which was then deployed thousands of times to customers. While these types of attacks and their impact are difficult to quantify, many believe the full effects of this kind of vulnerability are often unseen and potentially have catastrophic outcomes when exploited by attackers.

Discovery

During the discovery phase, vulnerabilities are discovered through security research, where motivated actors seek to understand whether something is vulnerable. They do this by using various methods that test the software for the types of vulnerabilities mentioned in the common vulnerabilities section. The motivations for discovery can vary. Some people are simply looking to discover vulnerabilities to improve the security of software, while others seek to exploit software with other goals in mind.

Depending on the actor’s motivations, the discovery stage presents the researchers with a choice to make. First, they need to decide how and whether they’ll communicate their vulnerabilities to responsible parties. Once discovered, researchers would notify the software publisher directly in ideal circumstances. Once informed, the publisher can begin work on fixing the problems in the remediation stage. Unfortunately, disclosing and determining the next steps for vulnerabilities is rarely this simple or rewarding.

In many cases, the vulnerabilities are never communicated to software publishers. It’s worth mentioning that disclosure decisions (if made at all) sometimes take an ethically questionable path. For example, there are some cases where security researchers decide to sell vulnerability research to security firms. Some of these firms specialize in the acquisition of vulnerabilities and operational exploits. These firms will buy exploits to incorporate into their security toolsets that they, in turn, sell to other software vendors, the original software vendor, or even nation-states that can incorporate these exploits in their cyber arsenals.

Exploitation and remediation

The exploitation and remediation stages can occur shortly after discovery. These two are linked in our life cycle and appear depending on how things unfold after discovering the vulnerability.

In some cases, a vulnerability is discovered, and then the researchers who found the vulnerability will inform vendors of their findings. Vendors will then create remediation plans or even software patches that they’ll publish to customers that patch the security vulnerability.

Suppose information or software patches are released but they do not directly mention how the vulnerabilities work. In these cases, researchers sometimes try to reverse engineer the vulnerability based on the documentation or patches through careful observation to build functional exploits. This is quite common for security researchers working on or studying popular software products such as the operating system Windows. For example, with the disclosed vulnerability CVE-2019-0708, commonly known as BlueKeep, Microsoft released a patch in May 2019. Researchers reverse-engineered the patch to construct a working exploit in July, with the mainstream exploit kits receiving a working exploit later in the year during the month of September.

In other cases, some bug hunters can immediately release the exploitation information about their vulnerabilities to the public – sometimes for free and sometimes as something sold, as previously discussed in the discovery phase. Vulnerabilities that receive immediate releases can (and have) lead to widespread exploitation events.

Modern attack patterns typically show mass exploitation isn’t far behind when vulnerabilities are discovered and information about them is released. Bad actors often begin scanning public resources on the internet for vulnerable software versions that match the vulnerability discovery. Provided exploitations are created and reliable, they’re often added to hacker tools that can exploit the vulnerability.

Perhaps one of the most troubling attributes of this is how the public learns about these vulnerabilities. Even in the ideal circumstances of a researcher reaching out and sharing vulnerability information with companies, these actions, if not carried over public channels, can result in the vendor patching problems without any notice to the public or users about the impacted software and the risks associated with using outdated software. Unfortunately, this practice is insidiously common in the industry.

Deprecation

Much like in any life cycle, things end. Over time, software and vulnerable versions of that software will fall away from usage. Patches or remediations are provisionally added to newer versions. Eventually, legacy vulnerabilities will fall out of the purview of hackers, vulnerability scanners, or people looking for vulnerabilities.

Keep in mind that the process of eventual deprecation can take a lot of time, and older vulnerabilities should always be thought of and considered when reviewing technology. For example, the common bug Shellshock or CVE-2014-7169 is commonly found almost a decade after its public release. The vulnerability had been present in the software for over 30 years before being discovered, and the software is widely deployed throughout the worldwide technology ecosystem.

Another culprit for long deprecation cycles is unsupported but required services or systems. Consider for a moment the healthcare industry. Hospitals and healthcare organizations will often invest in blood chemistry analyzers, the hardware used for X-rays, and other imaging technology such as MRIs. These investments can amount to millions of dollars. Unfortunately, healthcare software publishers may not support the software on these devices for as long as a hospital intends to use the equipment it made investments in. These gaps can lead to issues where investments are not protected against exploitation, or exploitation is handled with other mitigating factors. Anecdotally, it’s not uncommon to see software that is 15 to 20 years old on large equipment or major technology investments such as industrial control systems that power critical infrastructure deployments in the public sector.

Hopefully, this has helped you understand the life cycles of vulnerabilities and what you can expect when a vulnerability eventually appears in software.

In this chapter, you’ve learned about vulnerabilities, what they are, and how they relate to core concepts in the information security industry. First, we reviewed the standard tools industry professionals use to scan and find vulnerable components. We then discussed common vulnerabilities found in different types of applications. Finally, we discussed the usual life cycle of vulnerabilities.

Getting you familiar with these concepts lays a foundation that will be crucial if you’re looking to research and report vulnerabilities yourself. Generally speaking, security practitioners need to understand vital foundational concepts around vulnerabilities, how they’re ranked and organized, what tools to use to scan for them, and what course of action is taken when security researchers discover them. Now that you’re armed with this foundational knowledge of vulnerabilities, you’re prepared to learn more through research and how to approach your own vulnerabilities.

In the next chapter, we’ll discuss the classification of vulnerabilities called zero-days and review case studies about their impacts on vulnerable software.

• MITRE CVE list – https://cve.mitre.org/cve/
• Common Vulnerability Scoring System Calculator – https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
• Known Exploited Vulnerabilities Catalog – https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Nmap – https://nmap.org/
• Nikto – https://cirt.net/Nikto2
• Nessus – https://www.tenable.com/products/nessus
• Rapid7 Nexpose – https://www.rapid7.com/products/nexpose/
• Qualys Vulnerability Management – https://www.qualys.com/
• OWASP Top 10 Web Application Vulnerabilities – https://owasp.org/www-project-top-ten/