Saturday, April 5, 2014

How does idle scan work?

        Idle scan, also called as 'Zombie scan' or 'Side channel attack' is a technique of port scanning. It is termed to be very stealthy or totally blind port scan. This is because the attacker's actual IP address is never disclosed to the target being scanned. The scan takes place indirectly through a zombie host. The attacker need not have control over zombie at all. However there is one condition for any host to act as a zombie -- it should be idle. That means, the 'zombie' host should not be talking on the network when the scan is being done. It should not have any connections already open which are sending or receiving packets. Otherwise the scan will be unsuccessful. Why is that so.. we'll see in a short while.

        Idle scan exploits the "Identification" field in IP header (IPID). It is based on the fact that this IPID is incremented by 1 for each packet that a host sends. Although many modern operating systems are immune from this attack (they randomize the IPID field), there are still other network-connected devices like printers which implement the bare essential TCP/IP. Idle scan also makes use of the TCP 3 way handshake - the standard "SYN" - "SYN/ACK" - "ACK" pattern -  and also the way open and closed ports react differently to the "SYN" packets. An open port will respond to a "SYN" TCP packet with a "SYN/ACK", while a closed port will respond with an "RST". Also remember that an unsolicited "RST" is not entertained, it is simply ignored with no reply.

        Okay, with that covered, now we'll see what exactly happens when an idle scan takes place. Note that we need to have address of a "zombie" host which is idle. 
See the above diagram, the sequence of incidents that take place are as follows:

  • Attacker first sends a TCP SYN packet to the Zombie which is up and idle i.e. not talking on the network.
  • The zombie replies with a SYN/ACK, in turn, disclosing its IPID value in this packet.
  • The attacker notes down this IPID value, which in this case, is 100. (Actual IPID's are much larger, considering the 2 byte size of this field)
  • Attacker then sends spoofed TCP SYN packet to the victim, with source IP of the Zombie. (in this case, it is 10.10.10.20). This SYN request is to the port which is to be scanned. 
Following till now? Here onward, there are two cases, either the port on the victim is open or closed. 

Case - I (Victim port is open):


  • If the port is open, the victim will send a SYN/ACK to the zombie (because the source ip in the SYN packet was spoofed to be zombie's).
  • Zombie will go like, "hey 10.10.10.30, we didn't have any connection open" and reply back with an RST (Hence, incrementing its IPID by 1)
  • After some time (usually, milliseconds) attacker will again send a SYN packet to the zombie.
  • But the zombie was expecting an "ACK" since it had sent "SYN/ACK" to the attacker earlier. So, it will send an "RST" packet back to the attacker, with IPID incremented by 1 (Now to 102).
  • The attacker now goes "Aha! The first IPID was 100 and now it is 102. That means that zombie must have sent one packet (IPID: 101) in between, to the victim. This packet must have been a TCP RST, because victim had sent to him, a SYN/ACK which zombie wasn't expecting! And since victim sent him a SYN/ACK. The victim's port is open! Yay!". Notice the kind of reverse thinking that goes into here. We trust that zombie must not have sent any other packet except for its "RST" reply to the unsolicited "SYN/ACK" that it got from victim.
That's why it is important to have a zombie that is not talking! The situation will be more clear when we consider the second case.

Case - I (Victim port is closed):

  • If the port is closed, victim will reply with an RST to the zombie (again, because of the spoofed IP).
  • Zombie is surprised to see an RST from victim when they didn't even have any connection open. Unsolicited RST's are ignored.. so zombie won't reply back to the victim.
  • Again attacker sends a SYN packet to the zombie, or any packet for that matter, it is really interested only in the IPID of the packet that it gets back.
  • From the packet that zombie sends back to the attacker, the IPID is obtained, which in this case is 101.
  • The attacker says, "hmm.. lets see, first IPID was 100 and now its 101. That means zombie didn't send any packet to anyone in between. It implies that it must have either got an RST from victim (port was closed), or nothing at all (port was filtered)! Since the IPID is not incremented in between, the port is either closed or filtered.. in any way not interesting to me!"

Hence, as you can see that idle scan is a very sophisticated kind of scan where the attacker's original IP address is not revealed to the victim. It can also be used to find out the trust relationships between zombies and the victim. Victim or target may react differently to different zombies based on the trust relationship between them, if any. 

Popular port scanning tools like hping and nmap can be used to perform idle scans. The command for nmap goes like this:
user# nmap -Pn -p 80 -sI 10.10.10.20 10.10.10.30
-sI is option for idle scanning followed by the zombie's address. Here, we are scanning for port 80. I am not sure if hping gives you directly such option.. I guess you have to manually note down and compare the IPIDs..

Thank you for reading my article and I hope you found it informative :)