bluebay2014 - Fotolia
How hackers use idle scans in port scan attacks
Hackers exploit port scan attacks to mask their identities before launching an attack. One of their favorites: the idle scan.
Editor's note: One of the steps that generally precedes a network-based attack is port scanning, in which a hacker tries to discover which services are being offered in order to launch a more specific attack. This article reveals a port-scanning technique that, contrary to most other techniques, does not reveal the location of the system performing the port scan.
The goal of port scanning is to discover network services being offered at the target system. Port scanning is a legitimate tool. Network and security administrators use scanning to test firewall rules, for example. But scanning is also used by hackers who employ port scan attacks to launch application-specific attacks.
Port scan attacks generally require the attacker to send some kind of probe packet. The probe elicits different responses from the target system, depending on the state of the corresponding transport port. Because the attacker needs to receive the response from the target system, he needs to send probes that employ his real network address. An attacker obviously wouldn't want to reveal that information.
While there are a number of techniques that may help the attacker conceal his network location -- such as using decoy traffic -- there is one clever TCP port-scanning technique that allows a hacker to perform port scan attacks without actually revealing his network address to the target system. Among port-scanning techniques, this method is known as idle scan, or dumb scan.
What is TCP port scanning, and how does it work?
In order to understand TCP port scans, we need to revisit the TCP connection-establishment mechanism, or three-way handshake. This mechanism essentially involves the exchange of three packets, as follows:
- The client sends a SYN packet to the server. This is a TCP packet with the SYN flag set, and it contains important information, such as the initial sequence number and desired TCP options.
- The server responds with a SYN/ACK packet, namely a TCP packet with both the SYN and ACK flags set. This packet includes information similar to the client's SYN packet and acknowledges receipt of the client's SYN.
- The client responds with an ACK packet that acknowledges the receipt of the SYN/ACK from the server.
Figure 1 illustrates how packets are exchanged.
If the target port happens to be closed, the server will instead respond with a reset (RST) to the client's SYN, as seen in Figure 2.
Thus, one can tell the state of a TCP port by sending a SYN packet to the target system and port, and then wait for the response packet; a SYN/ACK response indicates the port is open, while an RST indicates the port is closed.
Forging SYN packets as part of port scan attacks
Let's now assume the attacker employed a forged IP source address for his SYN packet. If the port was open, the target server would respond with a SYN/ACK, as expected. However, this SYN/ACK would be directed to the forged source address of the SYN packet, rather than to the attacker's IP address.
Upon receipt of the SYN/ACK, the receiving system would find this packet bogus -- as it never actually sent a SYN packet -- and respond with an RST.
Figure 3 illustrates this packet exchange, with the node whose address has been forged labeled as zombie.
If the target port at the server was closed, the server would respond with an RST, as expected. As in the previous scenario, this RST packet would be directed to the forged IP address, rather than to the attacker.
However, TCP's packet-processing rules indicate that RST packets do not elicit any packets. If they are deemed bogus, however, they are silently dropped. This scenario is illustrated in Figure 4.
If the attacker was able to tell whether his probe packet -- the forged SYN packet -- caused the zombie to send a packet, he could determine if the port was open or closed. Put another way, the response from the server could reveal whether the zombie packet was sent as a result of the forged SYN packet.
Information leakage at the IP layer
Among the key mechanisms of the Internet Protocol are those of fragmentation and reassembly: They allow the Internet Protocol to operate over a wide range of technologies by carving up an original packet into smaller packets, or fragments, and reassembling those pieces into the original packet at the destination system.
The Identification field of the IP header labels packet fragments. The values in that field -- IP source address, IP destination address, protocol and identification -- are then used by the receiving system to reassemble the fragments into the original packet.
Hosts typically use a different identification value for each transmitted packet. More specifically, they usually set the Identification field to a global counter that tracks each transmitted packet. Each packet is counted, including those not fragmented by the source system.
As a result, a system receiving a flow of packets from another system could see an incremental sequence of IP Identification values, such as 44567, 44568, 44569 and 44570. If, at any point of that sequence, some value was skipped, that would very likely be an indication that the sending host sent one packet to some other system. Put another way, IP implementations that employ a global counter for setting the IP Identification field essentially leak information about the number of packets they transmit.
Idle scan and how it can be exploited
Anonymous TCP port-scanning techniques can be implemented by putting together all the concepts discussed above. This technique can be thought of having three actors: the attacker, the victim and the zombie. The attacker is the host performing the port scan attacks, while the victim will be the target. Finally, the zombie will be a system exploited by the attacker to conceal the port scan.
It works like this: The attacker will sample the current IP Identification value at the zombie. Then, he'll send a forged SYN packet. He'll then sample the IP Identification again.
Such sampling can be performed by sending any packet that would elicit a response from the zombie, such as a SYN/ACK. If the sampled IP Identification values were consecutive -- like 45000 and 45001 -- that would be an indication the zombie did not send any packets as a result of the forged SYN packet and, thus, the corresponding TCP port was closed. The packet exchange corresponding to this scenario is illustrated in Figure 5.
On the other hand, if the corresponding IP Identification values were not consecutive -- say, 45000 and 45002 -- this would indicate the transmission of one packet by the zombie node. This would also mean the corresponding port was open. Figure 6 illustrates the corresponding packet exchange.
Port-scanning techniques: Idle scan in practice
The technique discussed in this document has been implemented in a number of port-scanning tools, including the popular open source security tool nmap. The "-sI" option selects the "idle scan" and specifies the zombie system.
The following is a sample output from nmap:
# nmap -P0 -p1-65535 -sI zombie.example.com www.example.com
Starting Nmap 7.12 ( https://nmap.org ) at 2017-01-03 01:02 ART
Idlescan using zombie zombie.example.com (192.0.2.1:80); Class: Incremental
Interesting ports on 198.51.100.120:
(The 65527 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
135/tcp open loc-srv
443/tcp open https
1027/tcp open IIS
1030/tcp open iad1
Nmap run completed -- 1 IP address (1 host up) scanned in 2594.472 seconds
