Vulnerability Scan

Vulnerabilities are weaknesses that may or may not be exploitable. Known vulnerabilities are categorized and referred to by their Common Vulnerabilities and Exposures (CVE) number. Once you have discovered hosts and open ports, you can conduct a vulnerability scan to see if the services listening on those ports have known vulnerabilities. A vulnerability scan involves sending specially crafted packets or commands to the service to see how it responds. If the service is vulnerable to a specific attack, it will be apparent in the response. Services that have been patched against the vulnerability will respond differently.

Scanners can be more generalized, or focus on specific targets such as Linux servers, SQL servers, web applications, or network devices. Depending on the tool, vulnerability scanners may or may not attempt to actually exploit the vulnerability and collect evidence (usually a stolen file) of a successful exploit. Some tools allow you to select the target type. Some vulnerability scanners can use the output from a port scan to focus their efforts.

Note: Do not mistake CVE with CWE. CWE stands for Common Weakness Enumeration, and refers to common software weaknesses regardless of vendor or implementation. CVE stands for Common Vulnerabilities and Exposures, and refers to specific vulnerabilities of specific products.

Here is an example of Nmap discovering web servers on the network, and then piping its output to Nikto for vulnerability scanning:

nmap -p80,443 10.0.1.0/24 -oG - | nikto.pl -h -

Commonly used vulnerability scanners include:

• OpenVAS
• Nexpose/Nexpose Community Edition
• Retina Community
• Nessus/Tenable
• Nmap NSE scripts

Note: For more information about CVEs and to research vulnerabilities by product, vendor or type, visit cve.mitre.org and www.cvedetails.com

---

Host Vulnerability Scans

Host vulnerability scans involve running tests against an operating system, including its default services. Often the focus is a single host. Hosts can not only run common network services, but they also often have specialized applications that use non-standard, dynamically chosen ports. Compromised hosts might also have malware backdoors listening on unusual ports. The challenge will be to map the discovered port to the actual listening process. You cannot assume that a well-known port is actually being used by the expected service.

Here are some examples of using Nmap for host vulnerability scanning.

# Check for common vulnerabilities
nmap -Pn --script vuln <target>

# Scan for vulnerabilities and attempt to automatically exploit them
nmap -Pn --script exploit <target> 

# Test to see if a host is vulnerable to DoS attacks
nmap --script dos -Pn <target> 

# Scan and interrogate ports for service version information. Produce very verbose output.
nmap -sV -vv <target> 

A good vulnerability scanner should be able to identify common services running on a host. If you are scanning for defensive purposes and cannot identify the underlying process, you can run the netstat command on the host for more information.

# Linux: 
netstat -natp

# Windows: 
netstat -nabo

---

Network Service Vulnerability Scans

Network services are common services you can expect to find on just about any network. These typically include:

• DHCP
• DNS
• WINS (legacy; less common today)
• Authentication/Directory Services
• Email
• File and print
• Web
• FTP
• Fax
• Remote Access

Nearly all network services have been vulnerable to attack at some point or another. Usually the vulnerability lies with the specific product or implementation. In some cases, however, the vulnerability lies less with the server and more with the process itself. For example, DHCP is broadcast-based with no authentication. This means a rogue DHCP server handing out incompatible IP addresses would be very disruptive to a network. When scanning network services, you can use a good general vulnerability scanner. If your network has unusual services, you might have to use a specialized tool.

Note: Do not confuse network service with network device. A network service provides client services. A network device such as a router or switch connects devices and moves traffic along the network.

---

Server Service Vulnerability Scans

The term server can refer to either a computer dedicated to serving clients on the network, or a specialized application installed on that computer. Servers (usually) run operating systems that are configured to handle hundreds or even thousands of concurrent clients. A few examples of server operating systems include Windows Server 2016, FreeBSD, Solaris, Ubuntu Server, and Red Hat Enterprise. Server OSs often ship with default network services installed. They also make it easy to install additional network services, including resource-intensive applications such as email and database servers.

From a vulnerability scanning perspective, there is no practical difference between a network service and a server service, since network services run on servers, and servers provide their services on a network. When testing your server services, you can start with a standard vulnerability scanner. If you have specialized services, you might need a tool configured for that service.

---

Web Server and Database Vulnerability Scans

Web servers and databases provide a unique opportunity for vulnerability scanning. Although they often work together, they are actually separate services, each with its own vulnerabilities and listening ports. They are often installed on separate computers and have their own IP addresses. Web servers are often public-facing, whereas database servers are almost always on the private network. The web server will then have a backend connection to the database server. Most database servers use the SQL language and listen on TCP or UDP port 1433. If you have access to the internal network, you can try scanning the SQL server directly. Or, if your access is through the web server, you can try scanning the web application to see if it will pass illegal commands to the SQL server (SQL injection). In smaller applications, the web server and database can be part of the same application, installed on the same computer. Here are possibilities for scanning a web server and its database:

• Scan the web server on TCP 80 or 443 for web-server-specific vulnerabilities.
• Scan for web servers that run on non-standard ports.
• Scan any web apps running on the web server for vulnerabilities not related to SQL.
• Scan the web app for SQL-injection-related vulnerabilities.
• Scan the SQL server directly on its port (usually TCP 1433).

Some common web application vulnerability scanners include:

• Arachni
• Metasploit WMAP
• OWASP ZAP
• Nikto
• Grabber
• Vega
• Wapiti
• W3af
• Skipfish
• Wfuzz
• Grendel-Scan
• Metasploit Pro
• SQLMap
• Zeus-Scanner (formerly Whitewidow)
• nmap http-*.nse scripts

Some common SQL-specific vulnerability scanners and testers include:

• Microsoft SQL Vulnerability Assessment
• ms-sql-info.nse
• ms-sql-empty-password.nse
• Metasploit auxiliary/scanner/mssql modules: mssql_ping, mssql_sql, mssql-enum, mssql_idf

---

Application Vulnerability Scans

Along with well-known services, other types of applications listen on the network. Some provide additional functionality to the standard service. One very common example is the web app. Web applications are scripts and executables that are included in the website’s HTML. They provide dynamic content to the user and (usually) run on the website’s standard TCP 80 and 443 ports. From a vulnerability scanning perspective, they also present an interesting challenge because so many are custom made. There are whole categories of web app vulnerabilities, but individual apps will behave differently from each other. An advanced pen tester might opt for testing for interesting behavior by the web app, in addition to using a pre-canned vulnerability scan.

Besides web apps, many other applications also listen on the network. These can be the hardest to identify, as they might not be predictable in the ports they use. If your scanner cannot identify the listening service, go to the host and use the netstat command for more information. You can also perform a Google search for information posted by the vendor.

Note: A deep dive into web application coding is beyond the scope of this class. For an interesting article on testing web app behavior, see https://portswigger.net/blog/backslash-powered-scanning-hunting-unknown-vulnerability-classes

---

Network Device Vulnerability Scans

Network devices such as routers, switches, and wireless access points also have vulnerabilities. Like servers, they have their own operating systems with services and features. They are also usually managed remotely using HTTP/S, SSH, or telnet. Because of the central role they play in connecting other devices, a compromised network device can cause serious disruptions, even network outages. As a penetration tester, you will want to look not only for vulnerable services and protocol stacks, but also ways to gain remote administrative access. When scanning network devices, a general scanner will show open ports but might not know how to test the specific devices. Be sure to choose a scanner that can specifically target the network devices you are scanning.

When scanning network devices, consider which IP address the device can be reached on. For example, a router is likely to have at least two IP addresses, but a switch might not have any. You can configure higher-end switches with a management IP address that you can make a remote connection to. Consider scanning all available IP addresses for the network device, just in case packet filtering or policies disallow some traffic on some interfaces.

---

Firewall Vulnerability Scans

While a firewall product might itself have vulnerabilities, most firewall scans are conducted to identify which traffic types the firewall allows, and to test the effectiveness of its rules. The primary purpose of a firewall is to block unauthorized packets from reaching listening services. Dedicated (appliance) firewalls control traffic flowing between the “trusted” and “untrusted” network. Software-based personal firewalls protect the host from unwanted connections. Firewalls use rule sets to determine if traffic is permitted or not. Most rules are based on:

• Destination or source port
• Destination or source IP address
• Protocol type
• Payload

Specially crafted packets might slip through because they sufficiently match a permit rule. Or, the packet might not be blocked because it doesn’t sufficiently match a deny rule. In addition, not all firewalls are capable of payload inspection. You might be able to push malicious code through a firewall over a permitted port. For example, if TCP 80 is allowed, you could hide a payload in HTTP, or simply set the destination port of any malicious TCP packet to 80. If the firewall is only looking at ports and not payload, it will permit the packet.

Sometimes you may just want to validate that there is a device at an IP address. Firewalls by design filter (block) traffic unless the port is open. This also means that if the host has no open ports, it will not respond to ICMP. Nor will it send any kind of response (including a TCP RST) to a TCP SYN. But a firewall might have a misconfiguration or design flaw that allows a specially crafted packet through, thus eliciting a response from the host. The type of packet you need to use will be dependent on the firewall product, though you can start with some well-known vulnerabilities. For example, the XMAS scan, in which the FIN, URG, and PSH flags are all raised in the same TCP segment, works against firewalls that follow a strict interpretation of RFC 793 (the original TCP specification). While this has been updated in most implementations, this vulnerability still exists in the wild.

There are two basic approaches to scanning a firewall for vulnerabilities:

• If the firewall is installed on the host, if it is a separate device in transparent mode, or if it provides NAT translation between the private and public network: Port-scan the public address of the host or firewall to see which ports are open or are being published. If you are probing for vulnerabilities, use specially crafted packets.
• If the firewall stands between two routable networks (does not provide NAT translation between two separate subnets), and you know or guess the IP address of the hidden host: Use firewalking against the firewall’s public interface. This technique uses a specialized combination of traceroute and port scanning to discover the details of the internal network. It can map additional routers and firewalls, IP addresses, and permitted ports.

Note: A firewall in transparent mode acts like a switch rather than a router. Although it filters traffic, nodes on both sides of it are in the same subnet.

Note: For information about firewalking, see the article “Firewalk: Can Attackers See Through Your Firewall?” at www.giac.org/paper/gsec/312/firewalk-attackers-firewall/100588

---

Packet Inspection

Packet inspection is the process of examining a network packet to see if it meets certain rules. A firewall will inspect packets to see if they should be permitted or denied. An intrusion detection system will inspect packets for unusual behavior or malicious payloads, and then log what it observes. Depending on the product, the inspection can be:

• Signature-based, comparing the packet and its payload to known malicious signatures.
• Anomaly-based, first capturing a baseline of normal traffic and then looking for deviations.

The pen tester will want to evade detection by packet inspectors. This can be done in a number of ways, including:

• Encrypting the packet or payload.
• Using as-yet unknown signatures or unrecognized crafted packets.
• Scanning very slowly so as not to indicate a pattern of malicious traffic.
• Spoofing by using trusted source ports or addresses.

---

Packet Crafting for Vulnerability Scans

Packet crafting is the process of taking a typical packet from a known protocol such as TCP or IP, and manipulating its options for security testing purposes. Because devices on a network are designed to follow the rules of TCP/IP, when confronted with an unexpected packet, they might behave abnormally. The results could be anything from DoS caused by unprocessable packets, to evading intrusion detection, to testing firewalls for vulnerabilities. Typical packet crafting techniques include:

• Raising TCP flags in an unusual or illogical manner.
• Changing source or destination ports.
• Spoofing IP or MAC addresses.
• Changing TCP sequence or acknowledgment numbers.
• Changing IP fragment offsets.
• Changing the Time-to-Live (TTL) value.
• Changing Quality of Service (DSCP) values.

Nmap can perform some packet crafting. There are also a number of tools specifically designed for packet crafting. Examples include:

• hping3
• Ostinato
• Scapy
• Libcrafter
• Yersinia
• packETH
• Colasoft Packet Builder
• Bit-Twist

---

WAP Vulnerability Scans

While some wireless access points (WAPs) themselves can have vulnerabilities, the vast majority of scans will be against the WAP’s security configuration. Most WAP security mechanisms have proven at some point to be vulnerable. The following table summarizes common WAP vulnerabilities.

WAP Security Type	Vulnerability
WEP	A weak implementation of the RC4 encryption algorithm, coupled with the absence of digital signatures and packet sequencing, makes it possible to crack a WEP key in 10 minutes or less. A 128-bit key takes only slightly longer.
WPA	Rotating keys and sequence numbers make cracking much more difficult, but the protocol is still susceptible to dictionary attacks if a weak passkey has been chosen.
WPA2	A key reinstallation attack (KRACK) manipulates the WPA2 4-way handshake, tricking a device into changing its encryption key to all zeros.
WPS	Brute forcing can crack a WPS pin in minutes. Usually also requires detection evasion techniques such as constantly changing the attacker’s MAC address, or specifying a blank PIN.

Note: Most of the security tests that apply to WAPs also apply to wireless routers.

---

Compliance Scans

Compliance scanning involves scans that verify that your network adheres to certain policy requirements. These policies can be mandated by law, industry, or individual company. Companies performing in-house compliance tests can use generic scanning tools to test their controls. Regulatory and industry compliance scanning, however, can be much more complex, with steep fines or even jail time for criminal non-compliance. For this reason, many organizations buy specialized software or even engage professional help when conducting regulatory compliance scans. Some organizations, such as the PCI Security Standards Council, publish a list of approved scanning vendors (ASVs).

You can conduct vulnerability scans to assist with compliance testing. If the compliance is regulatory, check with your legal department to help determine the scope and depth required.

Note: A control is anything, technical or non-technical, that implements a security measure. It can include policies, procedures, training, configuration, and physical devices.

---

Container Security Issues

A software container is basically a lightweight virtual machine. Rather than running an entire operating system, it runs a single application and its dependencies (processes the application depends on). The combination of the container and its application is called a container image—a standalone executable package that possesses everything it needs to run: code, runtime, system libraries and tools, and settings. Containers have been around since the early 2000s, but were not popular until applications like Docker made containers accessible for enterprise use. Unlike traditional virtual machines, containers do not rely on a separate hypervisor layer. Instead, they are directly supported by the underlying operating system, sharing the same kernel (core part of the operating system) and some binaries and code libraries as the host. This means their resource needs are minimal. The container is only a few megabytes in size and takes only seconds to start, as opposed to a few minutes as required by a virtual machine. The same amount of hardware on a host computer can support exponentially more containers than VMs. Containers are also highly transportable. They will behave the same way regardless of the platform that hosts them.

With all the conveniences containers bring to enterprise DevOps (developer/operations teams), they also introduce new security risks. Containers make it easy to package and distribute an application, but they don’t provide the same level of isolation as a virtual machine. Many network and security administrators are not even aware that containers have been deployed on their network. As with any software, not all container images available on the Internet can be trusted. Lack of visibility into a container makes it harder to observe and manage. Additionally, there is no guarantee that all components included in a container are patched and up-to-date.

Common container security issues include:

• Kernel exploits—since a container shares the OS kernel, any instability could cause a kernel panic and crash the host.
• Denial-of-Service attacks—if a container monopolizes shared resources, it could starve out other containers or the host itself.
• Container breakouts—if the application contains a bug that allows privilege escalation, malware could escape the container and attack other containers or the host.
• Poisoned or malicious images—if an attacker tricks you into launching a malicious image, or can swap out your good image with a malicious one, your host and data are at risk.
• Compromised credentials and keys—when a container needs to access a database or service, it will require a secret such as an API key or user name and password to authenticate. If an attacker can intercept the secret or extract it from the image, then they too will be able to access the service.

Note: For more information about container security, see NIST Special Publication 800-190 “Application Container Security Guide” at https://doi.org/10.6028/NIST.SP.800-190

---

Considerations for Scanning for Vulnerabilities

The biggest consideration when scanning for vulnerabilities is that your scanner will only report what it can recognize. It compares what it finds to a list of pre-canned, known vulnerabilities. Unlike antivirus or intrusion detection software, your average vulnerability scanner cannot use behavior analysis to identify unknown, zero-day vulnerabilities. For this reason, vulnerability scanning should only be one part of a multi-disciplinary approach to testing your security controls. You should update your scanner regularly, and scan frequently. Consider using multiple tools and cross-correlating results. Some organizations even outsource security scanning to cloud-based services that have databases with tens of thousands of vulnerability signatures.

Another major consideration is to validate vulnerabilities that you do find. Many vulnerability scans produce false positives, or report vulnerabilities that can’t actually be exploited. The most common way to validate is to attempt to actually exploit the vulnerabilities and produce evidence of success. Some exploit tools such as Metasploit can directly import the results of a vulnerability scanner and then attempt the exploit.

You should also keep in mind the limits of your scanning tools. Exploit tools such as Metasploit have some built-in vulnerability scanning capabilities. However, this is not Metasploit’s primary focus, and its scanning is not comprehensive. This is why you should use an actual scanning tool such as OpenVAS or Nexpose to conduct the scan, and then have Metasploit validate the results. Some tools, such as Nmap NSE scripts, are also out-of-date. Do not rely on any single tool for a comprehensive scan.

Additional Considerations

Some additional things to consider when it comes to vulnerability scanning include:

• Some vulnerability scans take a great deal of time to run—especially web app scans, which can take days. You may need to configure the scan to run at a more superficial level, or you may need to simply stop scanning after a certain amount of time or until you get a satisfactory amount of results.
• A scan may use one or more protocols to actually identify, process, analyze, and output vulnerability information. Some protocols are more useful in certain situations than others. For example, application of the Security Content Automation Protocol (SCAP) is mandatory for U.S. government agencies, and is therefore leveraged by several common scanners.
• The target network’s topology can make scanning more or less difficult, as well as impact the results of the scan. For example, in a network that is properly segmented, you may be unable to scan hosts outside of the segment in which you are conducting the scan.
• Intensive scans can consume a significant amount of bandwidth, especially if several concurrent scans are running against multiple hosts. This can delay the scans or disrupt them entirely. You may need to consider throttling the number of queries launched by the scanner in order to overcome bandwidth limitations.
• Query throttling can also help you avoid issues with fragile systems and other non-traditional assets that have weaker hardware or are inherently unstable. The less overhead the target needs to deal with, the less likely it is to experience delays, become unresponsive, or crash entirely.

---

Guidelines when Scanning for Vulnerabilities

Here are some guidelines you can follow when scanning for vulnerabilities:

• When scanning for vulnerabilities, use an actual vulnerability scanner rather than a generic port scanner.
• If you are scanning for compliance, involve your legal team.
• If possible, use credentialed scans to probe further into your target.
• When scanning different device or application types, use tools that are specifically designed for your target type.
• Scan firewalls to see which ports are permitted. If necessary, use specially crafted packets to evoke additional information from the firewall.
• Use tactics such as encryption, trusted ports, or slow speeds to evade packet inspection.
• Scan wireless access points to determine security settings and encryption protocols.
• Educate yourself on identifying and mitigating container security risks.
• Keep in mind that most vulnerability scanning can only identify known security weaknesses.
• Do not depend on any one vulnerability scanner to discover all of your vulnerabilities.
• Keep in mind that vulnerability scanners often produce false positives. Be sure to validate your scan results with an exploit tool such as Metasploit.

---