11-Vulnerability-Control

Chapter 11: Vulnerability Control Overview In this chapter, you will learn: n About discovering vulnerabilities n Strategies to manage vulnerabilities n Different types of Web vulnerabilities A vulnerability is an identified weakness within a system or network. Vulnerabilities, though, can be mitigated using a number of systems or processes, so even though a vulnerability has been identified, something else may be in place to keep the vulnerability from being exploited. It's worth knowing what the potential is, however, and then evaluating the probability of the vulnerability being exploited. Vulnerability scanners are often used as part of a Threat and Vulnerability Management (TVM) program, but as we will discuss later, vulnerability scanners are not flawless and sometimes turn up false positives. Vulnerabilities can arise from any number of directions, so it's helpful to know what these different directions are. You can even use some of the same tools your attackers might use in order to see what vectors of attack may be open. Mapping your network on a regular basis will ensure that the systems shown are the ones you expect to be there and that the appropriate services are being offered. There are a few different ways to perform this mapping. Vulnerability scans provide you with a starting point for the types of vulnerabilities that may exist on your system. Of course, these scans aren't perfect due to the nature of vulnerability scanners and how they operate. Beyond simply scanning for vulnerabilities, though, you could also try to exploit suspected vulnerabilities to prove they exist. Sometimes this sort of proof is a strong motivator in mitigating or removing such vulnerabilities. Once you have the list of vulnerabilities, whether technical or nontechnical, you should develop a strategy to mitigate them. This involves a combination of process and technical measures. One common place for vulnerabilities on a network is the Web server, not only the server itself but the public networks and various applications it's exposed to. Web applications have a number of potential sources of weakness. This could be due to poor application logic or programming, or it could result from a problem with frameworks and libraries in use by the Web application. Either way, it's helpful to check for vulnerabilities and understand how to get them under control in order to protect your network and any data stored on the server. Network Mapping/Scanning One of the first things you should do is gain an understanding of your network layout from the network perspective. While it is possible for systems to be configured to not appear on the network, you have a better chance of seeing what's out there by probing the network rather than trying to find every possible network connection and chasing it down, particularly with wireless networks being so prevalent. With a wireless connection, a networked device could be anywhere, and it would be difficult to find it. Locating networked devices is more easily accomplished by sending out probes on the network. Most times, you can get a device to respond to some network traffic and thus see what is out there. This will help you not only find potentially rogue devices, but will also check for potential misconfigurations where systems have IP addresses they aren't expected to have. Network scanning can also be done remotely, as opposed to physically checking for devices. A number of tools can be used to perform network scanning, and the results can be used to develop a map of the network. Some of these tools use the same techniques, though some have found different ways of scanning to get results. Ultimately, it comes down to sending out network requests and getting a response back that needs to be interpreted in some way. The interpretation is based on the way the specific protocol in use is designed to work, although there are sometimes anomalies based on different interpretations of the protocols. Different Types of Mapping When it comes time to map, the first thing you need to do is start issuing some network requests in order to get responses back. The request is based on the protocol you use to scan your network. Some choices of protocol will be based both on your location and the location of the hosts you are trying to scan. For instance, you wouldn't use a layer 2 protocol like ARP to check your network if you were on a separate subnet because you wouldn't actually get any useful responses GSEC GIAC Security Essentials Certification All­in­One Exam Guide McGraw­Hill/Osborne, McGraw­Hill Education (c) 2014, Copying Prohibited Page 2 / 26 back. This is because layer 2 requests aren't forwarded through layer 3 devices. Having said that, you can and probably should use different protocols based on what you are looking for. Using ARP Starting at the lowest layer we can issue network requests from, we can take a look at how to go about issuing ARP requests in order to see if a particular device is responsive at layer 2. While firewalls may block higher-layer protocols, blocking a layer 2 ARP request looking for a MAC address would make the system difficult to reach on the network since nothing could be sent to the system without knowing the media access control (MAC) address. You could send an Address Resolution Protocol (ARP) request out for every IP address on the system in order to see whether a system responds or not. Any attempt to connect to the system using the IP address will result in an ARP request being generated, but you could save some trouble and just issue the ARP request directly. There are several ways this can be done, depending on the OS you are using. No matter what tool you end up using, what you are really doing is issuing an ARP message indicating that you have an IP address and need to know the MAC address of the network interface it belongs to. The following is a single packet (that has been captured) of an ARP request looking for the IP address. 15:21:19.110503 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.30.42.152 tell dslrouter.westell.com, length 46 You would issue a request just like this to every host on your network looking to get an ARP response. Figure 11-1 shows the results from an ARP scan on the network using the Linux tool arp-scan. The tool issued an ARP request to the network looking for the MAC address of each IP address on the local network. As mentioned earlier, the reason for using an ARP scan rather than a scan using another protocol is that systems may be more likely to respond to ARP requests knowing that someone is looking for their MAC address to send a message to them. If they don't respond to these requests, getting anything to them would require that the network be seeded with static ARP entries on every system. This doesn't scale very well and would require that every system be changed if for some reason the IP address of the system changed. While this can be done and it may provide cloaking or obscurity, it's difficult to manage and is not particularly effective. An ARP scan can provide additional information for you as well since the MAC address will provide the vendor of the interface. While you can't directly determine the OS running simply from the vendor ID, you can make some good guesses about what may be happening with a particular system. You can see some entries reply indicating that they are network interfaces created by Apple Computer. That alone might tell you that the system is running some version of Mac OS X. Of course, it might also be running a version of iOS, but even adding that possibility in, you can narrow it down to two strong possibilities. Also note that there are two virtual machines on the network since two of the responses indicate that the interface vendor is Parallels Inc., and Parallels is virtualization software. You might guess that the host OS is Mac OS X in that case because, while Parallels has software available for both Windows and Mac, it is more common on the Mac OS than on Windows. GSEC GIAC Security Essentials Certification All­in­One Exam Guide McGraw­Hill/Osborne, McGraw­Hill Education (c) 2014, Copying Prohibited Page 3 / 26 Figure 11-1: An ARP scan One other piece of information visible from the scan is that there is at least one printer on the network. The system that responded with a vendor ID of Lexmark is very likely a printer since Lexmark makes printers. If you were to see a vendor ID of Brother, for example, you might conclude something similar. Other vendors like Hewlett Packard may have several devices you might find on a network, so you might not be able to take guesses about what the Hewlett Packard response is. A little digging, though, may turn up more details about some of the other vendor IDs resulting from the scan. Again, an ARP scan requires that you be on the local network with the hosts you are attempting to contact. This doesn't mean you need to physically be there, just that a system you are operating from is on the local network. ARP messages won't pass through a router onto another network. They belong solely to the subnet where they originated. ICMP You might also perform an ICMP scan using one of a number of ICMP messages, the most common of which is the ICMP echo request (type 8). The response to an echo request is an echo reply (type 0), assuming the host in question is up and running. You may be able to perform this type of scan using a broadcast message, but because of the risk of acting as an ICMP broadcast amplifier for Smurf attacks, many systems now won't easily originate ICMP messages to broadcast addresses, nor will they always respond to messages sent to a broadcast address. As a result, sending out an ICMP echo request to a broadcast address isn't the most reliable way of determining the systems that are on any given network. It's better to send out messages to individual systems. Since ICMP may be one of the first packets dropped if there is network congestion, you'll want to make sure you send several messages to ensure that not getting a response doesn't simply mean that the packet was dropped, and not that there is no host available on the network. ICMP messages operate at layer 3 using IP addresses, which are routable. As a result, you can use an ICMP scan from outside the local network. You do run a risk, however, of the ICMP messages not only being dropped but being blocked. Some administrators consider it a good idea to block ICMP messages from coming into their network, so again, not getting a response may not be a good indication that the host is not there or isn't responsive. It could simply mean that there is a router or firewall in the way dropping ICMP messages. In addition to an ICMP echo request, you may also send a different ICMP message like a timestamp request. While you may still run into the issue of dropped messages, you may be able to get around some near-sighted rules that limited themselves to ICMP echo requests. Blocking all ICMP messages isn't wise because ICMP is necessary for error messages, and going through all of the ICMP types and codes to determine the ones that are absolutely necessary can be Note The first three bytes of the MAC address is the Organizationally Unique Identifier (OUI), also known as the vendor ID. If the tool you are using is incapable of providing you a vendor from the OUI, there are several Web sites that will translate an OUI into a manufacturer name. GSEC GIAC Security Essentials Certification All­in­One Exam Guide McGraw­Hill/Osborne, McGraw­Hill Education (c) 2014, Copying Prohibited Page 4 / 26 time consuming. As a result, you may be able to get some ICMP messages through where something like an ICMP echo request may not make it because someone decided its only purpose is for scanning from the outside, and they don't allow that. Of course, getting an ICMP timestamp request through a firewall is no guarantee that the system will reply. In Figure 11-2, you can see a number of ICMP timestamp requests being sent over the local network (seen by the source and destination IP addresses of 172.30.42.55 and 172.30.42.1) with replies. TCP Since most services provided by a system are offered over TCP, this will give you results that the other two scan types discussed so far won't offer. Since TCP is a layer 4 protocol and layer 4 is responsible for offering ports for the purpose of multiplexing, you can determine services that may be running on the system. An ICMP or an ARP scan won't return the fact that port 80, for example, is open on the system being scanned. Knowing the ports that are open and responding will tell you different applications that are being used on the system. In the case of port 80, you could assume, lacking any other evidence, that there was a Web server on that particular system. TCP is a connection-oriented protocol, meaning that connections between two systems are established before actual application messages are sent back and forth. This is accomplished using a three-way handshake, as shown in the diagram in Figure 11-3, where the client initiates a connection to the server with a SYN message, the server responds with an ACK to the SYN, as well as a SYN of its own, and the client finishes the handshake with an ACK to the server's SYN message. This ensures that both systems are up and responding and it also establishes some parameters that will allow the two systems to communicate going forward. This three-way handshake will also allow us to do some scanning using TCP. A TCP scan might simply be done using a SYN message to each port on a system. If the port is open, the system will respond with the SYN/ACK as demonstrated earlier. If the port is not open, the system will reject the connection by sending a RST (reset) message. While there is no reason to finish the three-way handshake after getting the response, it may make sense to complete the connection and then tear it down to make sure that what you are doing is a little less noticeable. Of course, sending a lot of connection attempts to a system will be noticeable for anyone looking, but leaving hundreds or thousands of half-open connections on a system will be that much more noticeable. Figure 11-2: Several ICMP timestamp requests Figure 11-3: A three-way handshake GSEC GIAC Security Essentials Certification All­in­One Exam Guide McGraw­Hill/Osborne, McGraw­Hill Education (c) 2014, Copying Prohibited Page 5 / 26 Because TCP is not only connection-oriented but also reliable, it has to have header fields that allow it to provide connection management. These header fields can also be used to perform scans against targets. Setting different flags in packets sent to the target will yield different results. Figure 11-4 shows a FIN scan where, instead of a SYN packet, a packet with the FIN flag set is sent to the target. The FIN flag is used to close an open connection. If the port receiving the FIN message is closed, the target will send back a RST packet to reset the connection, effectively saying no one is home so stop bothering us here. If the port is open, however, it would have no record of an open connection, and as a result it would ignore the FIN message because it appears to be meaningless. Figure 11-4: A FIN scan FIN scans aren't the only types of scans you can perform that take advantage of the way TCP operates and the different fields that are available within the protocol. One type of scan is an Xmas scan, so named because the scanner turns on several flags before sending the message out. Another is an Idle scan because it takes advantage of the IP identification field to send out packets that appear to come from another source, then checks the IP ID of the spoofed source to determine how the target responded. This is actually just a SYN scan using a spoofed source. It's important that the spoofed source not be active on the network. The reason this works is because responses to a SYN message can be determined based on how the IP ID increments. If there is traffic going to the spoofed source that isn't coming from the target, it's harder to determine what's happening with the target because the IP ID will be changing in a way that doesn't make sense. Once you're talking about TCP, you're looking to see what ports (i.e., services) are open and not simply whether a host is online and available. Any combination of header fields that will get a response from the system and perhaps more importantly through a firewall or through intrusion detection is helpful when it comes time to get reliable results on a scan of a system where you want to know what vulnerabilities there are. The vulnerabilities from a network perspective are going to result from open ports and the services that are running on those ports. UDP A UDP scan is very similar to that of a TCP scan except that we don't have all the different variations on header fields to manipulate. On top of that, UDP is connectionless, so there isn't any process for establishing a session between two parties. Since UDP is not a reliable protocol, meaning it doesn't take responsibility for end-to-end delivery, UDP packets are dropped out on the network with the hope that they will get there in a timely fashion. Since there is nothing that ensures that the message got there or not, like with the TCP acknowledgment system, when you send a packet out you can't say what it means when you don't get a message back. It may mean that there is nothing on that port, but it could also mean that the message was simply dropped. If the message has been dropped, we would have to retransmit. The same is true for TCP, except that with TCP, a lack of acknowledgment means that we know that the message was dropped, so we can be sure that we have to retransmit. With UDP, there is no assurance that we have to retransmit, so we just do. Normally, the application would take the responsibility for retransmitting if it were using UDP and the message was important. UDP requires that reliability is handled by the application layer. The same thing is true when using a network scanner. If the scanner doesn't get a response back, it has to retransmit. Sending an immediate retransmit doesn't make any sense. You have to wait a period of time to account for the possibility of network lag. As a result of all of the retransmissions, a UDP scan may take quite a bit more time than a TCP scan of the same number of hosts and ports. Figure 11-5 shows a packet capture of a UDP scan. You can see how little there is in the UDP portion of the packet, which doesn't really leave anything much to change other than the port. Exam Tip  When you perform a port scan using TCP, whether it's a SYN scan (half-open) or a full connect scan, you will receive a reset (RST) packet in response on a closed port. Note The port number field in TCP is 16 bits, meaning that you can have values of 0–65535—or a total of 65,356 ports. GSEC GIAC Security Essentials Certification All­in­One Exam Guide McGraw­Hill/Osborne, McGraw­Hill Education (c) 2014, Copying Prohibited Page 6 / 26 Another reason why UDP scans can take longer and require retransmits is that an application listening to a UDP port would be responsible for responding, as appropriate. Again, unlike TCP where the operating system itself would handle the initial response, with UDP there is no connection handling, so everything is left up to the application. If the initial message sent to the UDP port isn't to the liking of the application, it is free to not respond. You might send several messages to a UDP port but if it is looking for a specific sequence in order to respond at all, you may get no response and the