Cybersecurity analysts spend a significant amount of time analyzing and interpreting the reports generated by vulnerability scanners. Although scanners are extremely effective at automating the manual work of vulnerability identification, the results that they generate require interpretation by a trained analyst to eliminate false positive reports, prioritize remediation activities, and delve into the root causes of vulnerability reports. In this chapter, you will learn how cybersecurity analysts apply their knowledge and experience to the review of vulnerability scan reports.
Vulnerability scan reports provide analysts with a significant amount of information that assists with the interpretation of the report. In addition to the high-level report examples shown in Chapter 4, “Designing a Vulnerability Management Program,” vulnerability scanners provide detailed information about each vulnerability that they identify. Figure 5.1 shows an example of a single vulnerability reported by the Nessus vulnerability scanner.
Let's take a look at this report, section by section, beginning in the top left and proceeding in a counterclockwise fashion.
At the very top of the report, we see two critical details: the name of the vulnerability, which offers a descriptive title, and the overall severity of the vulnerability, expressed as a general category, such as low, medium, high, or critical. In this example report, the scanner is reporting that a server is running an outdated and insecure version of the SSL protocol. It is assigned to the high severity category.
Next, the report provides a detailed description of the vulnerability. In this case, the report provides a detailed description of the flaws in the SSL protocol and explains that SSL is no longer considered acceptable for use.
The next section of the report provides a solution to the vulnerability. When possible, the scanner offers detailed information about how system administrators, security professionals, network engineers, and/or application developers may correct the vulnerability. In this case, the reader is instructed to disable SSL 2.0 and 3.0 and replace their use with a secure version of the TLS protocol.
In the section of the report titled “See Also,” the scanner provides references where administrators can find more details on the vulnerability described in the report. In this case, the scanner refers the reader to several blog posts, Nessus documentation pages, and Internet Engineering Task Force (IETF) documents that provide more details on the vulnerability.
The output section of the report shows the detailed information returned by the remote system when probed for the vulnerability. This information can be extremely valuable to an analyst because it often provides the verbatim output returned by a command. Analysts can use this to better understand why the scanner is reporting a vulnerability, identify the location of a vulnerability, and potentially identify false positive reports. In this case, the output section shows the specific insecure ciphers being used.
The port/hosts section provides details on the server(s) that contain the vulnerability as well as the specific services on that server that have the vulnerability. In this case, the server's IP address is obscured for privacy reasons, but we can see that the server is running insecure versions of SSL on both ports 443 and 4433.
The vulnerability information section provides some miscellaneous information about the vulnerability. In this case, we see that the SSL vulnerability has appeared in news reports.
The risk information section includes useful information for assessing the severity of the vulnerability. In this case, the scanner reports that the vulnerability has an overall risk factor of High (consistent with the tag next to the vulnerability title). It also provides details on how the vulnerability rates when using the Common Vulnerability Scoring System (CVSS). You'll notice that there are two different CVSS scores and vectors. We will use the CVSS version 3 information, since it is the more recent rating scale. In this case, the vulnerability has a CVSS base score of 7.5 and has the CVSS vector
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
We'll discuss the details of CVSS scoring in the next section of this chapter.
The final section of the vulnerability report provides details on the vulnerability scanner plug-in that detected the issue. This vulnerability was reported by Nessus plug-in ID 20007, which was published in October 2005 and updated in March 2019.
Although this chapter focuses on interpreting the details of a Nessus vulnerability scan, the process is extremely similar for other vulnerability scanners. The format of the reports generated by different products may vary, but they generally contain the same information. For example, Figure 5.2 shows the output of a Qualys vulnerability report.
The Common Vulnerability Scoring System (CVSS) is an industry standard for assessing the severity of security vulnerabilities. It provides a technique for scoring each vulnerability on a variety of measures. Cybersecurity analysts often use CVSS ratings to prioritize response actions.
Analysts scoring a new vulnerability begin by rating the vulnerability on eight different measures. Each measure is given both a descriptive rating and a numeric score. The first four measures evaluate the exploitability of the vulnerability, whereas the last three evaluate the impact of the vulnerability. The eighth metric discusses the scope of the vulnerability.
The attack vector metric describes how an attacker would exploit the vulnerability and is assigned according to the criteria shown in Table 5.1.
TABLE 5.1 CVSS attack vector metric
Value | Description | Score |
Physical (P) | The attacker must physically touch the vulnerable device. | 0.20 |
Local (L) | The attacker must have physical or logical access to the affected system. | 0.55 |
Adjacent Network (A) | The attacker must have access to the local network that the affected system is connected to. | 0.62 |
Network (N) | The attacker can exploit the vulnerability remotely over a network. | 0.85 |
The attack complexity metric describes the difficulty of exploiting the vulnerability and is assigned according to the criteria shown in Table 5.2.
TABLE 5.2 CVSS attack complexity metric
Value | Description | Score |
High (H) | Exploiting the vulnerability requires “specialized” conditions that would be difficult to find. | 0.44 |
Low (L) | Exploiting the vulnerability does not require any specialized conditions. | 0.77 |
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.
TABLE 5.3 CVSS privileges required metric
Value | Description | Score |
High (H) | Attackers require administrative privileges to conduct the attack. | 0.270 (or 0.50 if Scope is Changed) |
Low (L) | Attackers require basic user privileges to conduct the attack. | 0.62 (or 0.68 if Scope is Changed) |
None (N) | Attackers do not need to authenticate to exploit the vulnerability. | 0.85 |
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.
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.
TABLE 5.4 CVSS user interaction metric
Value | Description | Score |
None (N) | Successful exploitation does not require action by any user other than the attacker. | 0.85 |
Required (R) | Successful exploitation does require action by a user other than the attacker. | 0.62 |
TABLE 5.5 CVSS confidentiality metric
Value | Description | Score |
None (N) | There is no confidentiality impact. | 0.00 |
Low (L) | Access to some information is possible, but the attacker does not have control over what information is compromised. | 0.22 |
High (H) | All information on the system is compromised. | 0.56 |
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.
TABLE 5.6 CVSS integrity metric
Value | Description | Score |
None (N) | There is no integrity impact. | 0.00 |
Low (L) | Modification of some information is possible, but the attacker does not have control over what information is modified. | 0.22 |
High (H) | The integrity of the system is totally compromised, and the attacker may change any information at will. | 0.56 |
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.
TABLE 5.7 CVSS availability metric
Value | Description | Score |
None (N) | There is no availability impact. | 0.00 |
Low (L) | The performance of the system is degraded. | 0.22 |
High (H) | The system is completely shut down. | 0.56 |
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.
TABLE 5.8 CVSS scope metric
Value | Description |
Unchanged (U) | The exploited vulnerability can only affect resources managed by the same security authority. |
Changed (C) | The exploited vulnerability can affect resources beyond the scope of the security authority managing the component containing the vulnerability. |
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:
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.
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
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:
Analysts may calculate the exploitability score for a vulnerability using this formula:
Plugging in values for our SSL vulnerability, we get
With all of this information at hand, we can now determine the CVSS base score using the following rules:
In our example, the impact score is 3.60 and the exploitability score rounds to 3.9. Adding these together, we get a base score of 7.5, which is the same value found in Figure 5.1.
Many vulnerability scanning systems further summarize CVSS results by using risk categories rather than numeric risk ratings. These are usually based on the CVSS Qualitative Severity Rating Scale, shown in Table 5.9.
TABLE 5.9 CVSS Qualitative Severity Rating Scale
CVSS Score | Rating |
0.0 | None |
0.1–3.9 | Low |
4.0–6.9 | Medium |
7.0–8.9 | High |
9.0–10.0 | Critical |
Continuing with the SSL vulnerability example from Figure 5.1, we calculated the CVSS score for this vulnerability as 7.5. This places it into the High risk category, as shown in the header of Figure 5.1.
Cybersecurity analysts interpreting reports often perform their own investigations to confirm the presence and severity of vulnerabilities. These investigations may include the use of external data sources that supply additional information valuable to the analysis.
Vulnerability scanners are useful tools, but they aren't foolproof. Scanners do sometimes make mistakes for a variety of reasons. The scanner might not have sufficient access to the target system to confirm a vulnerability, or it might simply have an error in a plug-in that generates an erroneous vulnerability report. When a scanner reports a vulnerability that does not exist, this is known as a false positive error.
When a vulnerability scanner reports a vulnerability, this is known as a positive report. This report may either be accurate (a true positive report) or inaccurate (a false positive report). Similarly, when a scanner reports that a vulnerability is not present, this is a negative report. The negative report may either be accurate (a true negative report) or inaccurate (a false negative report).
Cybersecurity analysts should confirm each vulnerability reported by a scanner. In some cases, this may be as simple as verifying that a patch is missing or an operating system is outdated. In other cases, verifying a vulnerability requires a complex manual process that simulates an exploit. For example, verifying a SQL injection vulnerability may require actually attempting an attack against a web application and verifying the result in the backend database.
When verifying a vulnerability, analysts should draw on their own expertise as well as the subject matter expertise of others throughout the organization. Database administrators, system engineers, network technicians, software developers, and other experts have domain knowledge that is essential to the evaluation of a potential false positive report.
In some cases, an organization may decide not to remediate a vulnerability for one reason or another. For example, the organization may decide that business requirements dictate the use of an operating system that is no longer supported. Similarly, development managers may decide that the cost of remediating a vulnerability in a web application that is exposed only to the internal network outweighs the security benefit.
Unless analysts take some action to record these exceptions, vulnerability scans will continue to report them each time a scan runs. It's good practice to document exceptions in the vulnerability management system so that the scanner knows to ignore them in future reports. This reduces the level of noise in scan reports and increases their usefulness to analysts.
Vulnerability scanners often supply very detailed information when run using default configurations. Not everything reported by a vulnerability scanner represents a significant security issue. Nevertheless, scanners provide as much information as they are able to determine to show the types of information that an attacker might be able to gather when conducting a reconnaissance scan.
Figure 5.3 provides an example of a high-level report generated from a vulnerability scan run against a web server. Note that about two-thirds of the vulnerabilities in this report fit into the “Info” risk category. This indicates that the plug-ins providing results are not even categorized according to the CVSS. Instead, they are simply informational results. Most organizations do not go to the extent of removing all possible sources of information about a system because it can be difficult, if not impossible, to do so.
A cybersecurity analyst encountering the scan report in Figure 5.3 should first turn their attention to the high-severity SQL injection vulnerability that exists. Once that is remediated, seven medium-severity vulnerabilities require attention. The remaining informational vulnerabilities can likely be left alone. Many organizations will adopt a formal policy regarding how they handle these informational messages. For example, some organizations may decide that once a message appears in two or three consecutive scans, they will create a journal entry documenting the actions they took in response to the message or the reasons they chose not to take actions. This approach is particularly important for highly audited organizations that have stringent compliance requirements. Creating a formal record of the decision-making process satisfies auditors that the organization conducted due diligence.
Vulnerability scans should never take place in a vacuum. Cybersecurity analysts interpreting these reports should also turn to other sources of security information as they perform their analysis. Valuable information sources for this process include the following:
Each of these information sources can prove invaluable when an analyst attempts to reconcile a scan report with the reality of the organization's computing environment.
Trend analysis is also an important part of a vulnerability scanning program. Managers should watch for overall trends in vulnerabilities, including the number of new vulnerabilities arising over time, the age of existing vulnerabilities, and the time required to remediate vulnerabilities. Figure 5.4 shows an example of the trend analysis reports available in Nessus SecurityCenter.
Each vulnerability scanning system contains plug-ins able to detect thousands of possible vulnerabilities, ranging from major SQL injection flaws in web applications to more mundane information disclosure issues with network devices. Though it's impossible to discuss each of these vulnerabilities in a book of any length, cybersecurity analysts should be familiar with the most commonly detected vulnerabilities and some of the general categories that cover many different vulnerability variants.
Chapter 4 discussed the importance of regularly updating vulnerability scanners to make them effective against newly discovered threats. Although this is true, it is also important to note that even old vulnerabilities can present significant issues to the security of organizations. Each year Verizon conducts a widely respected analysis of all the data breaches they investigated over the course of the prior year. Figure 5.5 shows some of the results from the 2016 Data Breach Investigations Report. (Note that Verizon does continue to produce these reports on an annual basis, but they no longer include year of discovery data.)
Figure 5.5 underscores the importance of addressing old vulnerabilities and the stark reality that many organizations fail to do so. Many of the vulnerabilities exploited during data breaches in 2015 exploited vulnerabilities discovered more than a decade earlier. That's an astounding statistic.
Computer systems are quite complex. The operating systems run on both servers and endpoints comprising millions of lines of code, and the differing combinations of applications they run make each system fairly unique. It's no surprise, therefore, that many of the vulnerabilities detected by scans exist on server and endpoint systems, and these vulnerabilities are often among the most complex to remediate.
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:
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.
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 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:
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 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 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.
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.
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.
Modern interconnected networks use a complex combination of infrastructure components and network appliances to provide widespread access to secure communications capabilities. These networks and their component parts are also susceptible to security vulnerabilities that may be detected during a vulnerability scan.
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.
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.
SSL is no longer considered secure and should not be used on production systems. The same is true for early versions of TLS. Vulnerability scanners may report that web servers are using these protocols, and cybersecurity analysts should understand that any connections making use of these outdated versions of SSL and TLS may be subject to eavesdropping attacks. Figure 5.12 shows an example of a scan report from a network containing multiple systems that support the outdated SSL version 3.
The administrators of servers supporting outdated versions of SSL and TLS should disable support for these older protocols on their servers and support only newer protocols, such as TLS version 1.2.
SSL and TLS are commonly described as cryptographic algorithms, but in fact, this is not the case. The SSL and TLS protocols describe how cryptographic ciphers may be used to secure network communications, but they are not cryptographic ciphers themselves. Instead, they allow administrators to designate the cryptographic ciphers that can be used with those protocols on a server-by-server basis. When a client and server wish to communicate using SSL/TLS, they exchange a list of ciphers that each system supports and agree on a mutually acceptable cipher.
Some ciphers contain vulnerabilities that render them insecure because of their susceptibility to eavesdropping attacks. For example, Figure 5.13 shows a scan report from a system that supports the insecure RC4 cipher.
Solving this common problem requires altering the set of supported ciphers on the affected server and ensuring that only secure ciphers are used.
SSL and TLS rely on the use of digital certificates to validate the identity of servers and exchange cryptographic keys. Website users are familiar with the error messages displayed in web browsers, such as that shown in Figure 5.14. These errors often contain extremely important information about the security of the site being accessed but, unfortunately, are all too often ignored.
Vulnerability scans may also detect issues with the certificates presented by servers that support SSL and/or TLS. Common errors include the following:
The error shown in Figure 5.14 indicates that the user is attempting to access a website that is presenting an invalid certificate. From the URL bar, we see that the user is attempting to access bankofamerica.com
. However, looking in the details section, we see that the certificate being presented was issued to southwestwifi.com
. This is a typical occurrence on networks that use a captive portal to authenticate users joining a public wireless network. This example is from the in-flight Wi-Fi service offered by Southwest Airlines. The error points out to the user that they are not communicating with the intended website owned by Bank of America and should not provide sensitive information.
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.
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.
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.
Most modern datacenters make extensive use of virtualization technology to allow multiple guest systems to share the same underlying hardware. In a virtualized datacenter, the virtual host hardware runs a special operating system known as a hypervisor that mediates access to the underlying hardware resources. Virtual machines then run on top of this virtual infrastructure provided by the hypervisor, running standard operating systems such as Windows and Linux variants. The virtual machines may not be aware that they are running in a virtualized environment because the hypervisor tricks them into thinking that they have normal access to the underlying hardware when, in reality, that hardware is shared with other systems.
Figure 5.17 provides an illustration of how a hypervisor mediates access to the underlying hardware resources in a virtual host to support multiple virtual guest machines.
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.
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.
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.
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.
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.
In some environments, cybersecurity analysts may encounter the use of supervisory control and data acquisition (SCADA) systems, industrial control systems (ICSs), and other examples of the Internet of Things (IoT). These systems allow the connection of physical devices and processes to networks and provide tremendous sources of data for organizations seeking to make their business processes more efficient and effective. However, they also introduce new security concerns that may arise on vulnerability scans.
The IoT world also extends to include systems related to the management of physical infrastructure. For example, physical access control systems often interact with IoT devices at turnstiles, doors, gates, and other facility entry points. Building automation systems interact with heating, ventilation, and air conditioning (HVAC) systems, fire suppression systems, and other building controls. All of these systems tie together with workflow and process automation systems designed to reduce the burden on human staff.
Industrial control systems rely on a series of sensors and controllers distributed throughout the organization, collecting information and controlling activities. Programmable logic controllers (PLCs) are specialized hardware controllers designed to operate in an IoT environment. PLCs often use a specialized communication protocol called Modbus to communicate with sensors and other IoT components over wired serial interfaces. In addition to PLCs, you should be familiar with some other technology components that make up IoT deployments as you prepare for the CySA+ exam:
Some of the most critical IoT deployments are those found on vehicles and drones. These systems have a dramatic impact on the safety of human life and should be carefully monitored for security issues.
As with any other device on a network, IoT devices may have security vulnerabilities and are subject to network-based attacks. However, it is often more difficult to patch IoT devices than their traditional server counterparts because it is difficult to obtain patches. IoT device manufacturers may not use automatic update mechanisms, and the only way that cybersecurity analysts may become aware of an update is through a vulnerability scan or by proactively subscribing to the security bulletins issued by IoT device manufacturers.
Web applications are complex environments that often rely not only on web servers but also on backend databases, authentication servers, and other components to provide services to end users. These web applications may also contain security holes that allow attackers to gain a foothold on a network, and modern vulnerability scanners are able to probe web applications for these vulnerabilities.
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.
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:
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.
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.
There are a few common methods of targeting identity and access management systems as well as the use of identity information, each with common protection methods that can help to remediate them. These include password spraying, credential stuffing, impersonation, man-in-the-middle, and session hijacking attacks.
Two common authentication vulnerabilities arise because of the propensity of users to reuse the same passwords across multiple 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 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 (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 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.
Vulnerability management programs produce a significant amount of information that requires analysis by trained cybersecurity professionals. Cybersecurity analysts must be familiar with the interpretation of vulnerability scan results and the prioritization of remediation efforts to provide value to their organizations.
Vulnerability scanners usually rank detected issues using the Common Vulnerability Scoring System (CVSS). CVSS provides six measures of each vulnerability: the access vector metric, the access complexity metric, the authentication metric, the confidentiality metric, the integrity metric, and the availability metric. Together, these metrics provide a look at the potential that a vulnerability will be successfully exploited and the impact it could have on the organization.
As analysts interpret scan results, they should be careful to watch for common issues. False positive reports occur when the scanner erroneously reports a vulnerability that does not actually exist. If an analyst is suspicious about the accuracy of a result, they should verify it manually. When verifying a vulnerability, analysts should draw on their own expertise as well as the subject matter expertise of others throughout the organization.
To successfully interpret vulnerability reports, analysts must be familiar with the vulnerabilities that commonly occur. Common server and endpoint vulnerabilities include missing patches, unsupported operating systems and applications, buffer overflows, privilege escalation, arbitrary code execution, insecure protocol usage, and the presence of debugging modes. Common network vulnerabilities include missing firmware updates, SSL/TLS issues, DNS misconfigurations, internal IP disclosures, and VPN issues. Virtualization vulnerabilities include virtual machine escape vulnerabilities, management interface access, missing patches on virtual hosts, and security misconfigurations on virtual guests and virtual networks.
Explain how vulnerability scan reports provide critical information to cybersecurity analysts. In addition to providing details about the vulnerabilities present on a system, vulnerability scan reports also offer crucial severity and troubleshooting information. The report typically includes the request and response that triggered a vulnerability report as well as a suggested solution to the problem. Analysts must understand how to identify, validate, and remediate vulnerabilities that occur.
Know the purpose of the Common Vulnerability Scoring System (CVSS). The CVSS base score computes a standard measure on a 10-point scale that incorporates information about the access vector required to exploit a vulnerability, the complexity of the exploit, and the authentication required to execute an attack. The base score also considers the impact of the vulnerability on the confidentiality, integrity, and availability of the affected system.
Explain how servers and endpoint devices are a common source of vulnerability. Missing patches and outdated operating systems are two of the most common vulnerability sources and are easily corrected by proactive device maintenance. Buffer overflow, privilege escalation, and arbitrary code execution attacks typically exploit application flaws. Devices supporting insecure protocols are also a common source of vulnerabilities.
Know that network devices also suffer from frequent vulnerabilities. Network administrators should ensure that network devices receive regular firmware updates to patch security issues. Improper implementations of SSL and TLS encryption also cause vulnerabilities when they use outdated protocols, insecure ciphers, or invalid certificates.
Explain how specialized technologies add complexity to vulnerability scanning. Cybersecurity analysts should understand how to conduct and interpret scans against mobile devices and Internet of Things components. They should also include specialized systems, such as embedded devices, RTOS, SoC, and FPGA technology. Recognize the difficulty added by scanning vehicles, drones, building automation systems, physical access control systems, and industrial control systems.
Know that software vulnerabilities require cooperation between analysts and developers. Web applications, in particular, are susceptible to SQL and XML injection attacks. All software may contain buffer, integer, and heap overflow vulnerabilities. Correcting these problems often requires rewriting code and rescanning vulnerable applications to confirm proper remediation.
Understand how virtualized infrastructures add another layer of potential vulnerability. Administrators responsible for virtualized infrastructure must take extra care to ensure that the hypervisor is patched and protected against virtual machine escape attacks. Additionally, administrators should carefully restrict access to the virtual infrastructure's management interface to prevent unauthorized access attempts.
In Activity 4.2, you ran a vulnerability scan of a network under your control. In this lab, you will interpret the results of that vulnerability scan.
Review the scan results carefully and develop a remediation plan for your network. This plan should carefully consider the severity of each vulnerability, the potential that each may be a false positive result, and the time required to complete the remediation.
In this lab, you will interpret the CVSS vectors found in a vulnerability scan report to assess the severity and impact of two vulnerabilities.
Review the vulnerability reports in Figures 5.22 and 5.23.
Explain the components of the CVSS vector for each of these vulnerabilities. Which vulnerability is more serious? Why?
In this lab, you will remediate one of the vulnerabilities that you identified in Activity 5.1.