Attack Vector Metric

The attack vector metric describes how an attacker would exploit the vulnerability and is assigned according to the criteria shown in Table 5.1.

Attack Complexity Metric

The attack complexity metric describes the difficulty of exploiting the vulnerability and is assigned according to the criteria shown in Table 5.2.

Privileges Required Metric

The privileges required metric describes the type of account access that an attacker would need to exploit a vulnerability and is assigned according to the criteria in Table 5.3.

User Interaction Metric

The user interaction metric describes whether the attacker needs to involve another human in the attack. The user interaction metric is assigned according to the criteria in Table 5.4.

Confidentiality Metric

The confidentiality metric describes the type of information disclosure that might occur if an attacker successfully exploits the vulnerability. The confidentiality metric is assigned according to the criteria in Table 5.5.

Integrity Metric

The integrity metric describes the type of information alteration that might occur if an attacker successfully exploits the vulnerability. The integrity metric is assigned according to the criteria in Table 5.6.

Availability Metric

The availability metric describes the type of disruption that might occur if an attacker successfully exploits the vulnerability. The availability metric is assigned according to the criteria in Table 5.7.

Scope Metric

The scope metric describes whether the vulnerability can affect system components beyond the scope of the vulnerability. The scope metric is assigned according to the criteria in Table 5.8. Note that the scope metric table does not contain score information. The value of the scope metric is reflected in the values for the privileges required metric, shown earlier in Table 5.3.

Interpreting the CVSS Vector

The CVSS vector uses a single-line format to convey the ratings of a vulnerability on all six of the metrics described in the preceding sections. For example, recall the CVSS vector presented in Figure 5.1:

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

This vector contains nine components. The first section, CVSS:3.0, simply informs the reader (human or system) that the vector was composed using CVSS version 3. The next eight sections correspond to each of the eight CVSS metrics. In this case, the SSL vulnerability in Figure 5.1 received the following ratings:

• Attack Vector: Network (score: 0.85)
• Attack Complexity: Low (score: 0.77)
• Privileges Required: None (score: 0.85)
• User Interaction: None (score: 0.85)
• Scope: Unchanged
• Confidentiality: High (score: 0.56)
• Integrity: None (score: 0.00)
• Availability: None (score: 0.00)

Summarizing CVSS Scores

The CVSS vector provides good detailed information on the nature of the risk posed by a vulnerability, but the complexity of the vector makes it difficult to use in prioritization exercises. For this reason, analysts can calculate the CVSS base score, which is a single number representing the overall risk posed by the vulnerability. Arriving at the base score requires first calculating the exploitability score, impact score, and impact function.

Calculating the Impact Sub-Score (ISS)

The first calculation analysts perform is computing the impact sub-score (ISS). This metric summarizes the three impact metrics using the formula:

Plugging in the values for our SSL vulnerability, we obtain

Calculating the Impact Score

To obtain the impact score from the impact sub-score, we must take the value of the scope metric into account. If the scope metric is Unchanged, as it is in our example, we multiply the ISS by 6.42:

If the scope metric is Changed, we use a more complex formula:

Calculating the Exploitability Score

Analysts may calculate the exploitability score for a vulnerability using this formula:

Plugging in values for our SSL vulnerability, we get

Missing Patches

Applying security patches to systems should be one of the core practices of any information security program, but this routine task is often neglected due to a lack of resources for preventive maintenance. One of the most common alerts from a vulnerability scan is that one or more systems on the network are running an outdated version of an operating system or application and require security patches.

Figure 5.6 shows an example of one of these scan results. The server located at 10.64.142.211 has a remote code execution vulnerability. Though the scan result is fairly brief, it does contain quite a bit of helpful information:

• The description tells us that this is a flaw in the Windows HTTP stack.
• The service information in the Output section of the report confirms that the server is running an HTTPS service on TCP port 443.
• We see in the header that this is a critical vulnerability, and this is confirmed in the Risk Information section, where we see that it has a CVSS base score of 10.

Fortunately, there is an easy way to fix this problem. The Solution section tells us that Microsoft released patches for the affected operating systems, and the See Also section provides a direct link to the Microsoft security bulletin (MS15-034) that describes the issue and solution in greater detail.

Unsupported Operating Systems and Applications

Software vendors eventually discontinue support for every product they make. This is true for operating systems as well as applications. Once they announce the final end of support for a product, organizations that continue running the outdated software put themselves at a significant risk of attack. The vendor simply will not investigate or correct security flaws that arise in the product after that date. Organizations continuing to run the unsupported product are on their own from a security perspective, and unless you happen to maintain a team of operating system developers, that's not a good situation to find yourself in.

Perhaps the most famous end of support for a major operating system occurred in July 2015 when Microsoft discontinued support for the more-than-a-decade-old Windows Server 2003. Figure 5.7 shows an example of the report generated by Nessus when it identifies a server running this outdated operating system.

We can see from this report that the scan detected two servers on the network running Windows Server 2003. The description of the vulnerability provides a stark assessment of what lies in store for organizations continuing to run any unsupported operating system:

Lack of support implies that no new security patches for the product will be released by the vendor. As a result, it is likely to contain security vulnerabilities. Furthermore, Microsoft is unlikely to investigate or acknowledge reports of vulnerabilities.

The solution for organizations running unsupported operating systems is simple in its phrasing but complex in implementation. “Upgrade to a version of Windows that is currently supported” is a pretty straightforward instruction, but it may pose a significant challenge for organizations running applications that simply can't be upgraded to newer versions of Windows. In cases where the organization simply must continue using an unsupported operating system, best practice dictates isolating the system as much as possible, preferably not connecting it to any network, and applying as many compensating security controls as possible, such as increased monitoring and implementation of strict network firewall rules.

Buffer Overflows

Buffer overflow attacks occur when an attacker manipulates a program into placing more data into an area of memory than is allocated for that program's use. The goal is to overwrite other information in memory with instructions that may be executed by a different process running on the system.

Buffer overflow attacks are quite commonplace and tend to persist for many years after they are initially discovered. For example, the 2016 Verizon Data Breach Investigation Report identified 10 vulnerabilities that were responsible for 85 percent of the compromises in their study. Among the top 10 were four overflow issues:

• CVE 1999-1058: Buffer overflow in Vermillion FTP Daemon
• CVE 2001-0876: Buffer overflow in Universal Plug and Play (UPnP) on Windows 98, 98SE, ME, and XP
• CVE 2002-0126: Buffer overflow in BlackMoon FTP Server 1.0 through 1.5
• CVE 2003-0818: Multiple integer overflows in Microsoft ASN.1 library

The four-digit number following the letters CVE in each vulnerability title indicates the year that the vulnerability was discovered. In a study of breaches that took place in 2015, four of the top 10 issues causing breaches were exploits of overflow vulnerabilities that were between 12 and 16 years old!

Cybersecurity analysts discovering a buffer overflow vulnerability during a vulnerability scan should seek out a patch that corrects the issue. In most cases, the scan report will directly identify an available patch.

Privilege Escalation

Privilege escalation attacks seek to increase the level of access that an attacker has to a target system. They exploit vulnerabilities that allow the transformation of a normal user account into a more privileged account, such as the root superuser account.

In October 2016, security researchers announced the discovery of a Linux kernel vulnerability dubbed Dirty COW. This vulnerability, present in the Linux kernel for nine years, was extremely easy to exploit and provided successful attackers with administrative control of affected systems.

In an attempt to spread the word about this vulnerability and encourage prompt patching of Linux kernels, security researchers set up the dirtycow.ninja website, shown in Figure 5.8. This site provides details on the flaw and corrective measures.

Rootkits are hacking tools designed to automate privilege escalation attacks. An attacker who gains access to a normal user account may use a rootkit to exploit a vulnerability and perform a privilege escalation attack, seeking to gain administrative privileges.

Arbitrary Code Execution

Arbitrary code execution vulnerabilities allow an attacker to run software of their choice on the targeted system. This can be a catastrophic event, particularly if the vulnerability allows the attacker to run the code with administrative privileges. Remote code execution vulnerabilities are an even more dangerous subset of code execution vulnerabilities because the attacker can exploit the vulnerability over a network connection without having physical or logical access to the target system.

Figure 5.9 shows an example of a remote code execution vulnerability detected by Nessus. Notice that the CVSS access vector shows that the access vector for this vulnerability is network based. This is consistent with the description of a remote code execution vulnerability. The impact metrics in the vector show that the attacker can exploit this vulnerability to completely compromise the system.

Fortunately, as with most vulnerabilities detected by scans, there is an easy fix for the problem. Microsoft issued patches for the versions of Windows affected by the issue and describes them in Microsoft Security Bulletin MS14-066.

Insecure Protocol Use

Many of the older protocols used on networks in the early days of the Internet were designed without security in mind. They often failed to use encryption to protect usernames, passwords, and the content sent over an open network, exposing the users of the protocol to eavesdropping attacks. Telnet is one example of an insecure protocol used to gain command-line access to a remote server. The File Transfer Protocol (FTP) provides the ability to transfer files between systems but does not incorporate security features. Figure 5.10 shows an example of a scan report that detected a system that supports the insecure FTP protocol.

The solution for this issue is to simply switch to a more secure protocol. Fortunately, encrypted alternatives exist for both Telnet and FTP. System administrators can use Secure Shell (SSH) as a secure replacement for Telnet when seeking to gain command-line access to a remote system. Similarly, the Secure File Transfer Protocol (SFTP) and FTP-Secure (FTPS) both provide a secure method to transfer files between systems.

Debugging Modes

Many application development platforms support debug modes that give developers crucial information needed to troubleshoot applications in the development process. Debug mode typically provides detailed information on the inner workings of an application and a server, as well as supporting databases. Although this information can be useful to developers, it can inadvertently assist an attacker seeking to gain information about the structure of a database, authentication mechanisms used by an application, or other details. For this reason, vulnerability scans do alert on the presence of debug mode on scanned servers. Figure 5.11 shows an example of this type of scan result.

In this example, the target system appears to be a Windows Server supporting the ASP​.NET development environment. The Output section of the report demonstrates that the server responds when sent a DEBUG request by a client.

Solving this issue requires the cooperation of developers and disabling debug modes on systems with public exposure. In mature organizations, software development should always take place in a dedicated development environment that is only accessible from private networks. Developers should be encouraged (or ordered!) to conduct their testing only on systems dedicated to that purpose, and it would be entirely appropriate to enable debug mode on those servers. There should be no need for supporting this capability on public-facing systems.

Missing Firmware Updates

Operating systems and applications aren't the only devices that require regular security updates. Vulnerability scans may also detect security problems in network devices that require firmware updates from the manufacturer to correct. These vulnerabilities result in reports similar to the operating system missing patch report in Figure 5.6 and typically direct administrators to the location on the vendor's site where the firmware update is available for download.

SSL and TLS Issues

The Secure Sockets Layer (SSL) protocol and its successor, Transport Layer Security (TLS), offer a secure means to exchange information over the Internet and private networks. Although these protocols can be used to encrypt almost any type of network communication, they are most commonly used to secure connections to web servers and are familiar to end users as the “S” in HTTPS.

Domain Name System (DNS)

The Domain Name System (DNS) provides a translation service between domain names and IP addresses. DNS allows end users to remember user-friendly domain names, such as apple.com, and not worry about the mind-numbing IP addresses actually used by those servers.

DNS servers are a common source of vulnerabilities on enterprise networks. Despite the seemingly simple nature of the service, DNS has a track record of many serious security vulnerabilities and requires careful configuration and patching. Many of the issues with DNS services are those already discussed in this chapter, such as buffer overflows, missing patches, and code execution vulnerabilities, but others are specific to the DNS service.

Figure 5.15 shows an example of a vulnerability scan that detected a DNS amplification vulnerability on two servers on an organization's network. In this type of attack, the attacker sends spoofed DNS requests to a DNS server that are carefully designed to elicit responses that are much larger in size than the original requests. These large response packets then go to the spoofed address where the DNS server believes the query originated. The IP address used in the spoofed request is actually the target of a denial-of-service attack and is bombarded by very large responses from DNS servers all over the world to queries that it never sent. When conducted in sufficient volume, DNS amplification attacks can completely overwhelm the targeted systems, rendering them inoperable.

Internal IP Disclosure

IP addresses come in two variants: public IP addresses, which can be routed over the Internet, and private IP addresses, which can be used only on local networks. Any server that is accessible over the Internet must have a public IP address to allow that access, but that address is typically managed by a firewall that uses network address translation (NAT) to map that public address to the server's true, private IP address. Systems on the local network can use the server's private address to access it directly, but remote systems should never be aware of that address.

Servers that are not properly configured may leak their private IP addresses to remote systems. This can occur when the system includes its own IP address in the header information returned in the response to an HTTP request. The server is not aware that NAT is in use, so it uses the private address in its response. Attackers can use this information to learn more about the internal configuration of a firewalled network. Figure 5.16 shows an example of this type of information disclosure vulnerability.

Virtual Private Network Issues

Many organizations use virtual private networks (VPNs) to provide employees with secure remote access to the organization's network. As with any application protocol, administrators must ensure that the VPN services offered by the organization are fully patched to current levels. In addition, VPNs require the use of cryptographic ciphers and suffer from similar issues as SSL and TLS when they support the use of insecure ciphers.

VM Escape

Virtual machine escape vulnerabilities are the most serious issue that may exist in a virtualized environment, particularly when a virtual host runs systems of differing security levels. In an escape attack, the attacker has access to a single virtual host and then manages to leverage that access to intrude on the resources assigned to a different virtual machine (VM). The hypervisor is supposed to prevent this type of access by restricting a VM's access to only those resources assigned to that machine. Escape attacks allow a process running on the VM to “escape” those hypervisor restrictions.

Management Interface Access

Virtualization engineers use the management interface for a virtual infrastructure to configure the virtualization environment, set up new guest machines, and regulate access to resources. This management interface is extremely sensitive from a security perspective, and access should be tightly controlled to prevent unauthorized individuals from gaining access. In addition to using strong multifactor authentication on the management interface, cybersecurity professionals should ensure that the interface is never directly accessible from a public network. Vulnerability scans that detect the presence of an accessible management interface will report this as a security concern.

Virtual Host Patching

This chapter already discussed the importance of promptly applying security updates to operating systems, applications, and network devices. It is equally important to ensure that virtualization platforms receive security updates that may affect the security of virtual guests or the entire platform. Patches may correct vulnerabilities that allow VM escape attacks or other serious security flaws.

Virtual Guest Issues

Cybersecurity analysts should think of each guest machine running in a virtualized environment as a separate server that requires the same security attention as any other device on the network. Guest operating systems and applications running on the guest OS must be promptly patched to correct security vulnerabilities and be otherwise well maintained. There's no difference from a security perspective between a physical server and a virtualized server.

Virtual Network Issues

As datacenters become increasingly virtualized, a significant amount of network traffic never actually touches a network! Communications between virtual machines that reside on the same physical hardware can occur in memory without ever touching a physical network. For this reason, virtual networks must be maintained with the same attention to security that administrators would apply to physical networks. This includes the use of virtual firewalls to control the flow of information between systems and the isolation of systems of differing security levels on different virtual network segments.

Injection Attacks

Injection attacks occur when an attacker is able to send commands through a web server to a backend system, bypassing normal security controls and fooling the backend system into believing that the request came from the web server. The most common form of this attack is the SQL injection attack, which exploits web applications to send unauthorized commands to a backend database server.

Web applications often receive input from users and use it to compose a database query that provides results that are sent back to a user. For example, consider the search function on an e-commerce site. If a user enters orange tiger pillows into the search box, the web server needs to know what products in the catalog might match this search term. It might send a request to the backend database server that looks something like this:

SELECT ItemName, ItemDescription, ItemPrice
FROM Products
WHERE ItemName LIKE '%orange%' AND
ItemName LIKE '%tiger%' AND
ItemName LIKE '%pillow%'

This command retrieves a list of items that can be included in the results returned to the end user. In a SQL injection attack, the attacker might send a very unusual-looking request to the web server, perhaps searching for

 orange tiger pillow'; SELECT CustomerName, CreditCardNumber FROM Orders; --

If the web server simply passes this request along to the database server, it would do this (with a little reformatting for ease of viewing):

SELECT ItemName, ItemDescription, ItemPrice
FROM Products
WHERE ItemName LIKE '%orange%' AND
ItemName LIKE '%tiger%' AND
ItemName LIKE '%pillow';
SELECT CustomerName, CreditCardNumber
FROM Orders;
--%'

This command, if successful, would run two different SQL queries (separated by the semicolon). The first would retrieve the product information, and the second would retrieve a listing of customer names and credit card numbers.

The two best ways to protect against SQL injection attacks are input validation and the enforcement of least privilege restrictions on database access. Input validation ensures that users don't provide unexpected text to the web server. It would block the use of the apostrophe that is needed to “break out” of the original SQL query. Least privilege restricts the tables that may be accessed by a web server and can prevent the retrieval of credit card information by a process designed to handle catalog information requests.

Vulnerability scanners can detect injection vulnerabilities, such as the one shown in Figure 5.18. When cybersecurity analysts notice a potential injection vulnerability, they should work closely with developers to validate that the vulnerability exists and fix the affected code.

Cross-Site Scripting

In a cross-site scripting (XSS) attack, an attacker embeds scripting commands on a website that will later be executed by an unsuspecting visitor accessing the site. The idea is to trick a user visiting a trusted site into executing malicious code placed there by an untrusted third party.

Cross-site scripting attacks arise in three different forms:

• Persistent XSS attacks occur when the attacker is able to actually store the attack code on a server. This code remains on the server, waiting for a user to request the affected content. These attacks are also known as stored XSS attacks.
• Reflected XSS attacks occur when the attacker tricks a user into sending the attack to the server as part of a query string or other content. The server then sends the attack back to the user (reflecting it), causing the code to execute.
• Document Object Model (DOM)-based XSS attacks occur within a database maintained by the user's web browser. These attacks are particularly insidious because they occur entirely on the user's computer and are never seen by the remote web server.

Figure 5.19 shows an example of an XSS vulnerability detected during a Nessus vulnerability scan.

Cybersecurity analysts discovering potential XSS vulnerabilities during a scan should work with developers to assess the validity of the results and implement appropriate controls to prevent this type of attack, such as input validation.

Directory Traversal

In a directory traversal attack, the attacker inserts filesystem path values into a query string, seeking to navigate to a file located in an area not normally authorized for public access. These attacks may occur when filenames are included in query strings. For example, if a web application retrieves policy documents from a remote storage device, it might include the name of the policy in a query string, such as this one:

http://www.myserver.com/policy?document='aup.pdf'

The web application might see this query string and then go to the policy store and retrieve a document called aup.pdf. If an attacker knows that the policy store is located on the same server as payroll records, they might try using the following query string to retrieve Mike's payroll records:

http://www.myserver.com/policy?document='../payroll/mike.pdf'

This query string seeks to traverse the directory structure of the storage server, navigating up to the parent directory of the policy folder and then down into the payroll directory.

Developers and security professionals should implement three types of controls to protect against directory traversal attacks. First, application designs should avoid including filenames in user-manipulatable fields, such as query strings. Second, input validation should prevent the use of special characters required to perform directory traversal. Finally, access controls on storage servers should restrict the web server's access to files authorized for public access.

Password Reuse

Two common authentication vulnerabilities arise because of the propensity of users to reuse the same passwords across multiple sites:

• Password spraying attacks occur when an attacker uses a list of common passwords and attempts to log into many different user accounts with those common passwords. The attacker only needs to find one valid username/password combination to gain access to the system. This attack is successful when users do not choose sufficiently unique passwords.
• Credential stuffing attacks occur when an attacker takes a list of usernames and passwords that were stolen in the compromise of one website and uses them to attempt to gain access to a different, potentially unrelated, website. Credential stuffing attacks are successful when users reuse the same password across many different sites.

In addition to encouraging strong password management practices, administrators can further protect themselves against password reuse vulnerabilities by requiring the use of multifactor authentication on sensitive systems.

Impersonation

Impersonation attacks occur when an attacker takes on the identity of a legitimate user. Security issues like OAuth open redirects, discussed in Chapter 8, “Identity and Access Management Security,” can allow impersonation to occur. Preventing impersonation may require stronger session handling techniques like those found in the OWASP session management cheat sheet at cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html. Other types of impersonation may be prevented by securing session identifiers that attackers might otherwise acquire, either on the local workstation or via the network.

Man-in-the-Middle

Man-in-the-middle (MitM) attacks occur when an attacker is able to interfere in the communication flow between two systems. For example, imagine that a user named Alice is seeking to communicate with her bank's web server, as shown in Figure 5.20.

Figure 5.20 shows the normal communication, where Alice sets up an HTTPS connection and then communicates securely with the web server. If an eavesdropper sees the network traffic related to this connection, they cannot read the communications because they are encrypted.

However, if an attacker is able to impersonate the bank's web server, as shown in Figure 5.21, the attacker can accept Alice's connection request and then establish their own connection to the legitimate bank server. The attacker then sees all of the requests coming from Alice and passes them on to the legitimate server, impersonating Alice. The attacker then sends the bank's responses to Alice. The attacker is serving as the man-in-the-middle.

End-to-end encryption of sessions or network links can help reduce the chance of a successful MitM attack, unless attackers control endpoints or have the encryption keys.

Session Hijacking

Session hijacking focuses on taking over an already existing session, either by acquiring the session key or cookies used by the remote server to validate the session or by causing the session to pass through a system the attacker controls, allowing them to participate in the session. Much like impersonation and MitM attacks, securing the data that an attacker needs to acquire to hijack the session, either via encrypting network sessions or links or on the local system, can help limit opportunities for session hijacking.