Identifying open ports on a target system is the next step to defining the attack surface of a target. Open ports correspond to the networked services that are running on a system. Programming errors or implementation flaws can make these services vulnerable to attack and can sometimes lead to total system compromise. To determine the possible attack vectors, one must first enumerate the open ports on all of the remote systems within the project's scope. These open ports correspond to services that may be addressed with either UDP or TCP traffic.
Both TCP and UDP are transport protocols. Transmission Control Protocol (TCP) is the more commonly used of the two and provides connection-oriented communication. User Datagram Protocol (UDP) is a non connection-oriented protocol that is sometimes used with services for which speed of transmission is more important than data integrity. The penetration testing technique used to enumerate these services is called port scanning. Unlike host discovery, which was discussed in the previous chapter, these techniques should yield enough information to identify whether a service is associated with a given port on the device or server. Prior to addressing the specific recipes listed, we will discuss some of the underlying principles that should be understood about port scanning.
Because TCP is a more commonly used transport-layer protocol, services that operate over UDP are frequently forgotten. Despite the natural tendency to overlook UDP services, it is absolutely critical that these services be enumerated to acquire a complete understanding of the attack surface of any given target. UDP scanning can often be challenging, tedious, and time consuming. The first three recipes in this chapter will cover how to perform a UDP port scan with different tools in Kali Linux.
To understand how these tools work, it is important to understand the two different approaches to UDP scanning that will be used. One technique, which will be addressed in the first recipe, is to rely exclusively on ICMP port-unreachable responses. This type of scanning relies on the assumption that any UDP ports that are not associated with a live service will return an ICMP port-unreachable response, and a lack of this response is interpreted as an indication of a live service. While this approach can be effective in some circumstances, it can also return inaccurate results in cases where the host is not generating port-unreachable responses or the port-unreachable replies are rate limited or are filtered by a firewall.
An alternative approach, which is addressed in the second and third recipes, is to use service-specific probes to attempt to solicit a response, which would indicate that the expected service is running on the targeted port. While this approach can be highly effective, it can also be very time consuming.
Throughout this chapter, several different approaches to TCP scanning will be addressed. These techniques include stealth scanning, connect scanning, and zombie scanning. To understand how these scanning techniques work, it is important to understand how TCP connections are established and maintained. TCP is a connection-oriented protocol, and data is only transported over TCP after a connection has been established between two systems. The process associated with establishing a TCP connection is often referred to as the three-way handshake. This name alludes to the three steps involved in the connection process. The following diagram illustrates this process in graphical form:
A TCP SYN packet is sent from the device that wishes to establish a connection with a port of the device that it desires to connect with. If the service associated with the receiving port accepts the connection, it will reply to the requesting system with a TCP packet that has both the SYN and ACK bits activated. The connection is established only when the requesting system responds with a TCP ACK response. This three-step process establishes a TCP session between the two systems. All of the TCP port scanning techniques will perform some variation of this process to identify live services on remote hosts.
Both connect scanning and stealth scanning are fairly easy to understand. Connect scanning is used to establish a full TCP connection for each port that is scanned. This is to say that for each port that is scanned, the full three-way handshake is completed. If a connection is successfully established, the port is then determined to be open. On the other hand, stealth scanning does not establish a full connection. Stealth scanning is also referred to as SYN scanning or half-open scanning. For each port that is scanned, a single SYN packet is sent to the destination port, and all ports that reply with a SYN+ACK packet are assumed to be running live services. Since no final ACK is sent from the initiating system, the connection is left half open. This is referred to as stealth scanning because logging solutions that only record established connections will not record any evidence of the scan.
The final method of TCP scanning that will be discussed in this chapter is a technique called zombie scanning. The purpose of zombie scanning is to map open ports on a remote system without producing any evidence that you have interacted with that system. The principles behind how zombie scanning works are somewhat complex. Carry out the process of zombie scanning with the following steps:
Send another SYN+ACK packet to the zombie host, and evaluate the final IPID value of the returned RST response. If this value has incremented by one, then the port on the scan target is closed, and if the value has incremented by two, then the port on the scan target is open.
The following diagram shows the interactions that take place when a zombie host is used to scan an open port:
To perform a zombie scan, an initial SYN/ACK request should be sent to the zombie system to determine the current IPID value in the returned RST packet. Then, a spoofed SYN packet is sent to the scan target with a source IP address of the zombie system. If the port is open, the scan target will send a SYN/ACK response back to the zombie. Since the zombie did not actually send the initial SYN request, it will interpret the SYN/ACK response as unsolicited and send an RST packet back to the target, thereby incrementing its IPID by one. Finally, another SYN/ACK packet should be sent to the zombie, which will return an RST packet and increment the IPID one more time. An IPID that has incremented by two from the initial response is indicative of the fact that all of these events have transpired and that the destination port on the scanned system is open. Alternatively, if the port on the scan target is closed, a different series of events will transpire, which will only cause the final RST response IPID value to increment by one.
The following diagram is an illustration of the sequence of events associated with the zombie scan of a closed port:
If the destination port on the scan target is closed, an RST packet will be sent to the zombie system in response to the initially spoofed SYN packet. Since the RST packet solicits no response, the IPID value of the zombie system will not be incremented. As a result, the final RST packet returned to the scanning system in response to the SYN/ACK packet will have the IPID incremented by only one. This process can be performed for each port that is to be scanned, and it can be used to map open ports on a remote system without leaving any evidence that a scan was performed by the scanning system.
This tutorial is an excerpt from "Kali Linux Network Scanning Cookbook - Second Edition" by Michael Hixon & Justin Hutchens and published by Packt. Get the ebook for just $10 for a limited period of time.
NetOps teams, like Spider Man, have great powers and great responsibilities. Increasingly, they are adopting a Zero Trust approach to network operations to help fight their battles.
Senior stakeholders who want to hold on to their CISOs must ensure that they have sufficient incentives and, more importantly, support to cope with the burden of risk that they are carrying.
The most alarming takeaway from Cisco’s new Cybersecurity Readiness Index report is that even after decades of having the importance of cybersecurity driven home, cyber threats are still taken too lightly.
