Idle scan

Idle scan on an open port

The idle scan is a TCP port scan method that consists of sending spoofed packets to a computer[1] to find out what services are available. This is accomplished by impersonating another computer called a "zombie" (that is not transmitting or receiving information) and observing the behavior of the ''zombie'' system.

Information

This action can be done through common software network utilities such as nmap and hping. The attack involves sending forged packets to a specific machine target in an effort to find distinct characteristics of another zombie machine. The attack is sophisticated because there is no interaction between the attacker computer and the target: the attacker interacts only with the "zombie" computer.

This exploit functions with two purposes, as a port scanner and a mapper of trusted IP relationships between machines. The target system interacts with the "zombie" computer and difference in behaviour can be observed using different "zombies" with evidence of different privileges granted by the target to different computers.

Discovered by Salvatore Sanfilippo (also known by his handle "Antirez") in 1998,[2] the idle scan has been used by many black hat "hackers" to covertly identify open ports on a target computer in preparation for attacking it. Although it was originally named dumb scan, the term idle scan was coined in 1999, after the publication of a proof of concept 16-bit identification field (IPID) scanner named idlescan, by Filipe Almeida (aka LiquidK).[3] This type of scan can also be referenced as zombie scan; all the nomenclatures are due to the nature of one of the computers involved in the attack.

TCP/IP basic knowledge

The design and operation of the Internet is based on the Internet Protocol Suite, commonly also called TCP/IP. IP is the primary protocol in the Internet Layer of the Internet Protocol Suite and has the task of delivering datagrams from the source host to the destination host solely based on their addresses. For this purpose, IP defines addressing methods and structures for datagram encapsulation. It is a connectionless protocol and relies on the transmission of packets. Every IP packet from a given source has an ID that uniquely identifies IP datagram.

TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. TCP is the protocol that major Internet applications rely on, such as the World Wide Web, e-mail, and file transfer. Each application server is called a service. In this system, hosts and host services are referenced using two components: an address and a port number. There are 65536 distinct and usable port numbers per host. Most services use a limited range of numbers.

Some port scanners scan only the most common port numbers, or ports most commonly associated with vulnerable services, on a given host. See: List of TCP and UDP port numbers.

The result of a scan on a port is usually generalized into one of three categories:

Open ports present two vulnerabilities of which administrators must be wary:

  1. Security and stability concerns associated with the program responsible for delivering the service - Open ports.
  2. Security and stability concerns associated with the operating system that is running on the host - Open or Closed ports.

Filtered ports do not tend to present vulnerabilities. The host in a local network can be protected by a firewall that filters, according with rules that its administrator set up, packets. This is done to deny services to hosts not known and prevent intrusion in the inside network. The IP protocol is network layer transmission protocol.

Basic mechanics

Idle scans take advantage of predictable Identification field value from IP header: every IP packet from a given source has an ID that uniquely identifies fragments of an original IP datagram; the protocol implementation assigns values to this mandatory field generally by a fixed value (1) increment. Because transmitted packets are numbered in a sequence you can say how many packets are transmitted between two packets that you receive.

An attacker would first scan for a host with a sequential and predictable sequence number (IPID). The latest versions of Linux, Solaris, OpenBSD, and Windows Vista are not suitable as zombie, since the IPID has been implemented with patches[4] that randomized the IP ID.[1] Computers chosen to be used in this stage are known as "zombies".

Once a suitable zombie is found the next step would be to try to establish a TCP connection with a given service (port) of the target system, impersonating the zombie. It is done by sending a SYN packet to the target computer, spoofing the IP address from the zombie, i.e. with the source address equal to zombie IP address.

If the port of the target computer is open it will accept the connection for the service, responding with a SYN/ACK packet back to the zombie.

The zombie computer will then send a RST packet to the target computer (to reset the connection) because it did not actually send the SYN packet in the first place.

Since the zombie had to send the RST packet it will increment its IPID. This is how an attacker would find out if the targets port is open. The attacker will send another packet to the zombie. If the IPID is incremented only by a step then the attacker would know that the particular port is closed.

The method assumes that zombie has no other interactions: if there is any message sent for other reasons between the first interaction of the attacker with the zombie and the second interaction other than RST message, there will be a false positive.

The first stage of an idle scan
The second stage of an idle scan

Finding a zombie host

The first step in executing an idle scan is to find an appropriate zombie. It needs to assign IP ID packets incrementally on a global (rather than per-host it communicates with) basis. It should be idle (hence the scan name), as extraneous traffic will bump up its IP ID sequence, confusing the scan logic. The lower the latency between the attacker and the zombie, and between the zombie and the target, the faster the scan will proceed.[5]
Note that when a port is open, IPIDs increment by 2. Following is the sequence:
1. Attacker to target -> SYN, target to zombie ->SYN/ACK, Zombie to target -> RST (IPID increment by 1)
2. Now attacker tries to probe zombie for result. Attacker to Zombie ->SYN/ACK, Zombie to Attacker -> RST (IPID increment by 1)
So, in this process IPID increments by 2 finally.

When an idle scan is attempted, tools (for example nmap) tests the proposed zombie and reports any problems with it. If one doesn't work, try another. Enough Internet hosts are vulnerable that zombie candidates aren't hard to find. A common approach is to simply execute a ping sweep of some network. Choosing a network near your source address, or near the target, produces better results. You can try an idle scan using each available host from the ping sweep results until you find one that works. As usual, it is best to ask permission before using someone's machines for unexpected purposes such as idle scanning.

Simple network devices often make great zombies because they are commonly both underused (idle) and built with simple network stacks which are vulnerable to IP ID traffic detection.

While identifying a suitable zombie takes some initial work, you can keep re-using the good ones. Alternatively, there have been some research on utilizing unintended public web services as zombie hosts to perform similar idle scans. Leveraging the way some of these services perform outbound connections upon user submissions can serve as some kind of poor's man idle scanning.[6]

Using hping

The hping method for idle scanning provides a lower level example for how idle scanning is performed. In this example the target host (172.16.0.100) will be scanned using an idle host (172.16.0.105). An open and a closed port will be tested to see how each scenario plays out.

First, establish that the idle host is actually idle, send packets using hping2 and observe the id numbers increase incrementally by one. If the id numbers increase haphazardly, the host is not actually idle or has an OS that has no predictable IP ID.

[root@localhost hping2-rc3]# ./hping2 -S 172.16.0.105
HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes
len=46 ip=172.16.0.105 ttl=128 id=1371 sport=0 flags=RA seq=0 win=0 rtt=0.3 ms
len=46 ip=172.16.0.105 ttl=128 id=1372 sport=0 flags=RA seq=1 win=0 rtt=0.2 ms
len=46 ip=172.16.0.105 ttl=128 id=1373 sport=0 flags=RA seq=2 win=0 rtt=0.3 ms
len=46 ip=172.16.0.105 ttl=128 id=1374 sport=0 flags=RA seq=3 win=0 rtt=0.2 ms
len=46 ip=172.16.0.105 ttl=128 id=1375 sport=0 flags=RA seq=4 win=0 rtt=0.2 ms
len=46 ip=172.16.0.105 ttl=128 id=1376 sport=0 flags=RA seq=5 win=0 rtt=0.2 ms
len=46 ip=172.16.0.105 ttl=128 id=1377 sport=0 flags=RA seq=6 win=0 rtt=0.2 ms
len=46 ip=172.16.0.105 ttl=128 id=1378 sport=0 flags=RA seq=7 win=0 rtt=0.2 ms
len=46 ip=172.16.0.105 ttl=128 id=1379 sport=0 flags=RA seq=8 win=0 rtt=0.4 ms

Send a spoofed SYN packet to the target host on a port you expect to be open. In this case, port 22 (ssh) is being tested.

# hping2—spoof 172.16.0.105 -S 172.16.0.100 -p 22 -c 1
HPING 172.16.0.100 (eth0 172.16.0.100): S set, 40 headers + 0 data bytes
--- 172.16.0.100 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Since we spoofed the packet, we did not receive a reply and hping reports 100% packet loss. The target host replied directly to the idle host with a syn/ack packet. Now, check the idle host to see if the id number has increased.

# hping2 -S 172.16.0.105 -p 445 -c 1
HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes
len=46 ip=172.16.0.105 ttl=128 DF id=1381 sport=445 flags=SA seq=0 win=64320 rtt=0.3 ms
--- 172.16.0.105 hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.3 ms

Notice that the proxy hosts id increased from id=1379 to id=1381. 1380 was consumed when the idle host replied to the target host's syn/ack packet with an rst packet.

Run through the same processes again testing a port that is likely closed. Here we are testing port 23 (telnet).

# hping2 -S 172.16.0.105 -p 445 -c 1; hping2—spoof 172.16.0.105 -S 172.16.0.100 -p 23 -c 1; hping2 -S 172.16.0.105 -p 445 -c 1
HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes
len=46 ip=172.16.0.105 ttl=128 DF id=1382 sport=445 flags=SA seq=0 win=64320 rtt=2.1 ms
--- 172.16.0.105 hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2.1/2.1/2.1 ms
HPING 172.16.0.100 (eth0 172.16.0.100): S set, 40 headers + 0 data bytes
--- 172.16.0.100 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes
len=46 ip=172.16.0.105 ttl=128 DF id=1383 sport=445 flags=SA seq=0 win=64320 rtt=0.3 ms
--- 172.16.0.105 hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.3 ms

Notice that this time, the id did not increase because the port was closed. When we sent the spoofed packet to the target host, it replied to the idle host with an rst packet which did not increase the id counter.

Using nmap

The first thing the user would do is to find a suitable zombie on the LAN:

Performing a port scan and OS identification (-O option in nmap) on the zombie candidate network rather than just a ping scan helps in selecting a good zombie. As long as verbose mode (-v) is enabled, OS detection will usually determine the IP ID sequence generation method and print a line such as “IP ID Sequence Generation: Incremental”. If the type is given as Incremental or Broken little-endian incremental, the machine is a good zombie candidate. That is still no guarantee that it will work, as Solaris and some other systems create a new IP ID sequence for each host they communicate with. The host could also be too busy. OS detection and the open port list can also help in identifying systems that are likely to be idle.

Another approach to identifying zombie candidates is the run the ipidseq NSE script against a host. This script probes a host to classify its IP ID generation method, then prints the IP ID classification much like the OS detection does. Like most NSE scripts, ipidseq.nse can be run against many hosts in parallel, making it another good choice when scanning entire networks looking for suitable hosts.

nmap -v -O -sS 192.168.1.0/24

This tells nmap to do a ping sweep and show all hosts that are up in the given IP range. Once you have found a zombie, next you would send the spoofed packets:

nmap -P0 -p <port> -sI <zombie IP> <target IP>

The images juxtaposition show both of these stages in a successful scenario.

Effectiveness

Although many Operating Systems are now immune from being used in this attack, Some popular systems are still vulnerable;[1] making the idle scan still very effective. Once a successful scan is completed there is no trace of the attacker's IP address on the target's firewall or Intrusion-detection system log. Another useful possibility is the chance of by-passing a firewall because you are scanning the target from the zombie's computer,[7] which might have extra rights than the attacker's.

See also

Notes

  1. 1 2 3 Erikson, Jon (1977). HACKING the art of exploitation. San Francisco: NoStarch Press. p. 264. ISBN 1-59327-144-1.
  2. ↑ Sanfilippo, Salvatore (1998-12-18). "new tcp scan method". Retrieved 2010-09-28.
  3. ↑ Filipe Almeida (aka LiquidK) (1999-12-03). "idlescan (ip.id portscanner)". Retrieved 2010-11-09.
  4. ↑ Sanfilippo, Salvatore (1999-10-26). "predictable ip->id patch". Retrieved 2010-09-28.
  5. ↑ Gordon “Fyodor” Lyon (2010). "Nmap Network Scanning Chapter 5. Port Scanning Techniques and Algorithms". Insecure.Com LLC. Retrieved 2010-09-28.
  6. ↑ Martin “olemoudi” Obiols (2011). "Zombie Scans using Unintended Public Services". (Almost) No Tech Hacking Blog. Retrieved 2011-03-16.
  7. ↑ Gordon “Fyodor” Lyon (2010). "Nmap Network Scanning Chapter 15. Nmap Reference Guide". Insecure.Com LLC. Retrieved 2010-09-28.
This article is issued from Wikipedia - version of the 1/7/2015. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.