Vulnerability Identification

Vulnerability Identification

Abstract

This chapter discusses the steps necessary to identify information about target systems, including information regarding operating system and version, and accessible applications. Once identified, we look at how to use this information to identify potentially exploitable vulnerabilities.

Contents

Introduction

In this chapter, we examine systems closer than we did during the Information Gathering phase; in the previous phase of the penetration test, we collected data on operating systems (OSes), Internet Protocol (IP) addresses, application data, and more from sources on the Internet. During the Vulnerability Identification phase, we will use this information to shape our probes and communicate directly with the targets with the intent of identifying potential threats and vulnerabilities.

To understand what types of vulnerabilities exist on a target system, we need to know specifics about the OS, what services are available on the server, and the application version information. Once we have this data, we can query national databases on vulnerabilities to determine if the target system might be vulnerable to attack. In this phase, we do not conduct any exploits; it will be in Chapter 8. For now, we are simply auditing the system to see what risks might exist—not prove their existence. We also explore different techniques used to gathering system information: specifically, active and passive scans. Passive scans will allow the penetration test engineer to avoid detection, whereas active scans provide greater depth of information more quickly.

An obstacle we often encounter is firewalls, which may filter our probes. We will look at ways of detecting services despite the existence of firewalls by manipulating network packets. We will examine the Transmission Control Protocol (TCP) and Internet Control Message Protocol (ICMP) in detail to understand exactly what type of network traffic we are using to detect systems and how we can modify them to avoid firewall restrictions.

I need to make a clear distinction between what we will cover in this chapter and Chapter 8 titled “Vulnerability Exploitation.” In this chapter, we will not use automated scanners to perform vulnerability assessments—the reasoning behind this distinction is that vulnerability scanners often step over the vaguely defined line between vulnerability identification and vulnerability exploitation. Our primary focus is to understand at a high level what types of exploitable vulnerabilities might exist on a system.

Port Scanning

When we conduct a port scan in the vulnerability identification phase, there are two objectives:

1. Verification of the existence of the target system and

2. Obtaining a list of communication channels (ports) that accept connections.

 

Later on, we will try to identify what applications are on the communication channels, but for now we simply want to enumerate what ports are open. In this section, we will use a couple of different tools, but don’t assume that the tools listed are the only ones available for port scanning and enumeration. The BackTrack disk has a number of tools capable of doing port scanning and system enumeration. In addition, www.sectools.org/app-scanners.html also lists the most popular hacking tools related to port scanning (be aware that the Nmap scanner has intentionally been left off this particular list, because the owner of the Web site is the developer of the Nmap scanner and didn’t want to seem partial in the ranking of the top scanner tools).

Although we won’t delve too deeply into the concepts of ports and communication protocols, it is important to understand not only the protocol structures but also how the tools use (or misuse) the protocols to communicate with the target. We discuss different scanning techniques and protocols to determine if a system is available and how the system is communicating.

Our work during the Information Gathering phase may have provided us with some idea of systems, applications, and OSes within the target network; however, we need to delve deeper. The first step in this phase often involves scanning a network to identify all systems available. For this chapter, we proceed immediately with scanning specific targets, instead of examining the network as a whole. We eventually identify all the systems on the network using passive scanning techniques, but the real purpose in this chapter is to locate potential vulnerabilities.

Target Verification

Before we begin scanning for all open ports on a system, it is often prudent to begin with the task of verifying the existence of the target. There are a couple of ways we can do this, including using the TCP and User Datagram Protocol (UDP) protocols. However, our first attempt at target verification will be to use the PING command, which uses the ICMP. The ICMP is defined in RFC 792 and provides network and system information, including details on any errors encountered. The ICMP communication occurs at the Internet Layer of the TCP/IP model or the Network Layer of the Open Systems Interconnection (OSI) reference model.

For our purpose, there are two messages that we use within ICMP to determine whether our target is alive: Echo Request and Echo Reply. An example of the ICMP Echo or Echo Reply message can be seen in Figure 7.1.

The initial request from our attack system will set the Type field to “8” and send the datagram to the target system. If the target system is configured to respond to echo requests, the target will return a datagram using the value of “0” in the Type field. It is possible that systems are configured to ignore ICMP requests, to provide some protection against random scans from malicious users, so results are not always accurate.

An example of a successful ping request can be seen in Figure 7.2. We see that 64 bytes of data were sent to our target three times and each time the target replied. Additional information is provided, including how long it took to obtain a reply from the target. As a side note, Linux and Windows handle ping requests a bit differently; one of the biggest differences is that Windows will tell us when a packet is dropped, whereas Linux won’t tell us until we cancel the ping request. Another one is that Linux will ping forever until actively terminated—the only reason we received just three ping packets from our target using Linux is because I stopped it at that point.

Latency information is useful for adjusting the speed of your attack, but not very helpful for the purposes of verifying availability of a target. Let’s take a look at Figure 7.3, where we send another ping to a different target (the De-ICE 1.100 disk), but this time the target system is blocking all ICMP traffic. Figure 7.3 shows that 24 packets were sent to the target system and no echo replies were received in return.

If we relied simply on ICMP to confirm the existence of a system, we would have missed this particular server. Because it is possible that ICMP messaging may be disabled for 192.168.1.100, an alternate tool should always be used to verify our findings.

A tool we will use extensively in this book is the Nmap port scanner. Nmap is short for “Network Mapper” and is an open-source project available from www.nmap.org. If we are not connected to the network segment containing our target system, we can use Nmap to try and detect our target. Figure 7.4 shows the result of an Nmap ping scan (-sP).

We see that Nmap was able to detect our target, although our previous ICMP echo request was unsuccessful. What was the difference? Turns out, the Nmap ping scan sends out two datagrams—an ICMP echo request and a TCP ACK packet. If we captured the packets between the target and attack system, we would see that the ICMP echo request did not generate any reply, while the TCP ACK packet successfully enticed our target to disclose its existence.

It is important to understand what actually occurs within the tools we use during a penetration test. The term Ping scan is somewhat of a misnomer, considering that a TCP packet is also sent in the scan. While this technicality may seem minor, it should be noted that the target system did not actually respond to a ping request, despite what Nmap implies, and should be recognized in any reports provided to clients.

If we wanted to conduct a network scan, we would have modified the Nmap scan request accordingly. If we wanted to identify all systems within this particular network using the Nmap ping scan, our command would have been nmap -sP 192.168.1.1-255 or, better yet, nmap -sP 192.168.1.0/24. There is a lot of flexibility in designating which targets Nmap should scan, which is detailed in the Nmap documentation.

When we are on the same network segment as the target or in the path of the packet, we can listen for network chatter to detect systems. The advantage is we do not have to send any data packets, allowing us to be less obvious about our intentions. Figure 7.5 has the results of network traffic on my lab network. As we can see, 192.168.1.100 is alive and communicating within the network segment, which invalidates the results obtained in Figure 7.3.

Once we have identified a system is alive, we can proceed to the next step of discovering what ports are open, closed, or filtered on our target.

UDP Scanning

UDP scanning has many disadvantages; it is slow when compared to TCP scans, and most exploitable applications use TCP. In addition, UDP services only respond to a connection request when the incoming packet matches the expected protocol; any UDP scan has to be followed up with connection attempts. Despite the disadvantages, UDP scanning is an essential component in target verification and understanding the target network.

There are four possible results returned from a UDP scan:

■ Open: The UDP scan confirmed the existence of an active UDP port.

■ Open/filtered: No response was received from the UDP scan.

■ Closed: An ICMP “port unreachable” response was returned.

■ Filtered: An ICMP response was returned, other than “port unreachable.”

When an open or closed result is obtained from a UDP scan, we can assume that the target system is alive and we can communicate with it directly (to what extent still needs to be determined). From experience, firewall rules are often written to prevent TCP attacks; UDP scans are not something most firewall administrators think about, and therefore don’t filter. If our initial TCP scans don’t find our target system, we can use UDP scans as a follow-up method of detection.

When we receive the open/filtered or filtered response, there is a good chance a firewall or an intrusion prevention system is intercepting our probes. Unfortunately, systems can also be configured to ignore UDP connection requests as well. When we receive a result indicating filtering is occurring, we need to adjust our attack accordingly by using various perimeter avoidance scans discussed below.

TCP Scanning

Most of the interesting applications from a pentest perspective use TCP to communicate across the networks, including Web servers, file transfer applications, databases, and more. There are a few different tools we can use to determine port status, but for this section we will use two tools: Nmap and netcat. Understanding the fields within the TCP header, seen in Figure 7.6, will assist us to identify what is occurring when we do launch some of the more advanced scans. Of particular interest in the header is the control bits starting at the 106th bit, labeled URG, ACK, PSH, RST, SYN, and FIN. These control bits are used to provide connection reliability between two systems.

Our first attempt in identifying ports on a target will be with the netcat tool. In Figure 7.7, we probe the De-ICE 1.100 disk for a list of ports available. For simplicity sake, we just scanned from ports 20 through 25 and found that three ports were open: 21, 22, and 25. Although netcat provided us with suggestions as to what applications are on each open port, we cannot trust what netcat says, because it uses a best guess—it does not send any data to confirm what applications are running. Our next tool will demonstrate this problem.

When we run Nmap against a different target, as seen in Figure 7.8, we are presented with a list of ports and suspected applications. Unfortunately, the service identified by Nmap on port 10000 is incorrect. We will confirm that later in this chapter under the Section “Banner Grabbing,” but this illustrates the necessity of validating our findings with different tools. The application list in this Nmap scan is also a best guess and doesn’t verify any information from the application itself.

Our scan is a very basic scan and doesn’t use the strengths of Nmap very well. The scan conducted in Figure 7.8 does provide us a quick look at the system, but does not provide much assurance as to what is really on our target. A default scan simply sends a TCP connection request to the target system and sees if anything comes back—it does not complete the TCP three-way handshake. It is possible that a firewall is altering the packets and providing us with incorrect information. Let’s take a look at some alternate scanning techniques using Nmap.

The TCP connect scan is the most reliable method of determining port activity, which conducts a complete three-way TCP handshake, as seen in Figure 7.9. The disadvantage to a TCP connect scan is that the amount of traffic required to confirm the existence of an application is much higher and may be noticed by intrusion detection systems (IDSes). The advantage is that after a TCP connect scan, we will know for certain whether an application is truly present or not.

The TCP SYN stealth scan is the default scan for Nmap, which we conducted in Figure 7.8. Unlike the TCP connect scan, the SYN stealth scan creates a half-open connection as seen in Figure 7.10. After receiving a SYN/ACK from the target server, the attack system simply closes the connection with a RST. The advantage of this attack is simply a reduction in traffic over the target server’s network by not completing the three-way handshake. While this might help against IDSes, the real advantage is the increased speed of scans against numerous targets.

The TCP connect scan and SYN scan will prove to be useful in most scans. If a firewall is between the attack and target system, additional attack methods must be considered to detect the presence of a system and its applications.

Perimeter Avoidance Scanning

Nmap has many different options we can use when scanning a system or network segment; some of them are intended to avoid firewalls, which is where the control bits mentioned earlier come into play. Types of scans that activate different control bits within the Nmap scanner are as follows:

■ ACK scan (-sA): This turns on the ACK bit. This scan will send an ACK to the target system in the hopes that the firewall will assume a communication channel that already exists between the attacker and the target system. Stateful firewalls typically only filter SYN packets, so the unrelated ACK might punch through.

■ Fin scan (-sF): This scan turns on the FIN bit, which should only be present at the end of a stateful TCP session. A FIN is sent to the target system in the hopes that the firewall will assume a communication channel that already exists between the attacker and the target system. As with the ACK scan, stateless firewalls typically only filter SYN packets, so the unrelated FIN might go unnoticed.

■ Null scan (-sN): A “Null” attack is when a TCP packet is sent with all control bits set to zero. The packet is sent to the target system in the hopes that something complains about the packet—preferably the target system. Stateless firewalls typically only filter SYN packets, so the empty might go unnoticed.