User:Pastore Italy/Idle scan

From Wikipedia, the free encyclopedia

The idle scan is a TCP port scan method that consist in sending spoofed packets to a computer: [1]: i.e. is a method to find out what services are available on a computer by impersonating another computer called "zombie" (that is not transmitting or receiving information) and observing the behaviour of the zombie system.

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

This exploit is dual-hatted as a port scanner and maps out trusted IP relationships between machines: the target system interacts with "zombie" and difference in behaviour can be observed using different "zombies", having 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). 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[edit]

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 identifying 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. 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 or Accepted: The host sent a reply indicating that a service is listening on the port.
  • Closed or Denied or Not Listening: The host sent a reply indicating that connections will be denied to the port.
  • Filtered, Dropped or Blocked: There was no reply from the host.

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[edit]

Idle scans take advantage of predictable Identification field value from IP header: every IP packet from a given source has an ID that uniquely identifying 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 and OpenBSD, Windows Vista are not suitable as zombie, since the IPID has been implemented with patches[3] 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 then 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[edit]

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. [4]

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.

Funny—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.

Using Hping[edit]

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 tramitted, 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[edit]

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 -O -sP 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[edit]

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 attackers 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 zombies computer [5], which might have extra rights than the attacker's. Another issue is that you must be able to spoof packets as if they are coming from the zombie and have them reach the target machine. Many ISPs (particularly dialup and residential broadband providers) now implement Egress_filtering to prevent this sort of packet spoofing. Higher end providers (such as colocation and T1 services) are much less likely to do this. If this filtering is in effect, Nmap will print a quick error message for every zombie you try. If changing ISPs is not an option, you might try using another IP on the same ISP network. Sometimes the filtering only blocks spoofing of IP addresses that are outside the range used by customers. Another challenge with idle scan is that you must find a working zombie host, as described in the next section.

See also[edit]

Notes[edit]

  1. ^ a b c Erikson, Jon (1977). "HACKING the art of exploitation" (2nd ed.). San Francisco: NoStarch Press. p. 264. ISBN 1-59327-144-1. {{cite book}}: Cite has empty unknown parameter: |lay-date= (help)
  2. ^ Sanfilippo, Salvatore (1998-12-18). "new tcp scan method". Retrieved 2010-09-28.
  3. ^ Sanfilippo, Salvatore (1999-10-26). "predictable ip->id patch". Retrieved 2010-09-28.
  4. ^ Gordon “Fyodor” Lyon (2010). "Nmap Network Scanning Chapter 5. Port Scanning Techniques and Algorithms". Insecure.Com LLC. Retrieved 2010-09-28.
  5. ^ Gordon “Fyodor” Lyon (2010). "Nmap Network Scanning Chapter 15. Nmap Reference Guide". Insecure.Com LLC. Retrieved 2010-09-28.

External links[edit]

Category:Computer security software Category:Internet Protocol based network software

Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Pastore_Italy/Idle_scan&oldid=1092330907"