Hidden Scans - Using Side Channels to Map Targets
Network scanning is a well worn tactic for host enumeration and target reconnaissance. By far and away the best network scanning tool is NMAP (http://nmap.org). NMAP scans target networks using a number of TCP/IP protocols (such as TCP, UDP, or ICMP). In a typical scan NMAP sends packets to well known ports on each IP address to be scanned and reports on response. NMAP can thus identify open and listening ports on target machines.
This typical approach, known as a syn scan, is reliable and quickly maps public services. An interesting challenge to a typical scan is a network setup where some ports are open, but have access restrictions. For instance, an internal web or file server might be set up and available to the local area network (LAN) but closed to the rest of the world. Knowing that these services exist, and mapping which IP addresses are "trusted" with access is extremely valuable information to an attacker. Such information can reveal internal network topology, trust relationships, and high value servers that might not be accessible via the wider internet. Enumerating these resource externally might seem like an impossible task. However, it is possible to do just that using NMAP's idle scanning functionality.
About Idle Scans
Idle scanning takes advantage of a somewhat obscure feature of TCP/IP networking. When a network packet is transmitted it conforms to certain size restrictions. Due to the uneven architecture of the internet, however, not all networks support the same maximum packet size. If a network device is responsible for delivering a packet across a network that cannot support the size of the packet then the device will fragment the packet into smaller packets that can fit across the network. To keep track of these fragments, so they can be reassembled at the destination, a fragmentation id is assigned as part of the TCP/IP packet header. Each packet contains a fragmentation id when it is created. Interestingly, some operating systems increment this id sequentially for each packet they send. Thus, if you send a packet to such a host, the response will have a certain fragmentation id (say 1), and if you send a subsequent packet the response will have an incremented fragmentation id (say 2).
In and of itself this behavior is not particularly useful. Where it becomes valuable is when spoofing an IP source address for a TCP communication. Because TCP communication starts with a three way handshake (machine A sends a SYN packet, machine B responds with a SYN/ACK packet, then machine A sends an ACK packet), and an unpredictable packet numbering scheme that is established in the second and third parts of the handshake, it isn't possible to spoof a full TCP communication. However, idle scanning uses this behavior to the attackers advantage.
Assume the following network, with real IP addresses instead of the reserved ones used below:
10.0.0.2 <- The attackers computer 192.168.0.2 <- A webserver that only answers to machines on the 192.168.0.x network 192.168.0.5 <- A device on the 192.168.0.x network with FTP (port 21)
Now, if the attacker in the above scenario sends a TCP SYN packet to 192.168.0.5 but spoofs the source address as 192.168.0.2 the target machine (192.168.0.5) will get the packet and respond by sending a SYN/ACK packet to 192.168.0.2 which will likely respond by sending a reset (RST) packet to 192.168.0.5 because it is unsolicited traffic. Thus, the attacker may as well be throwing packets down a hole since they never find out what happened to their original SYN packet.
Suppose, however, that the machine 192.168.0.5 has a sequential fragmentation id scheme. Let's say we send a SYN packet to 192.168.0.5 on port 21 and we get a SYN/ACK response with a fragmentation id of 3. Next, we send another SYN packet and get a similar response except the fragmentation id is 4. Next, we send a SYN packet to 192.168.0.2 but we spoof the source IP as 192.168.0.5. Then we send another normal SYN packet and get a SYN/ACK but the fragmentation id is now 8. We can infer, because of this, that the machine at 192.168.0.5 sent and received packets in the interim. Likely they communicated with the web server (192.168.0.2), meaning that 192.168.0.2 got our spoofed packet and tried to negotiate with 192.168.0.5 (our idle machine) which resulted in packets with incremented fragmentation id's being sent back and forth. This is useful because if we send packets to 192.168.0.2 with a spoofed source address but to ports that aren't listening the packets will simply get dropped and we won't see any incrementation of the fragmentation id from 192.168.0.5.
This attack utilizes a side channel (the fragmentation id) to determine if a communication has taken place. By spoofing source addresses we can control the destination of responses from our target machine. This allows us to map which machines, and ports, are allowed by rules that may be invisible to the outside. Ultimately this can reveal trust relationships, and hidden services. The key to this process is identifying machines that use incremental fragmentation ids and don't communicate much. A machine that uses incremental fragmentation but which communicates frequently will be useless since it will be impossible to tell if the machine is incrementing as a result of responding to spoofed packets or simply as a normal course of legitimate communications.
Identifying Idle Zombie Targets
NMAP provides two approaches for finding idle machines to use for this type of scanning. The first is to simply use OS detection (-O) and verbose mode (-v), which should report machines with incremental fragmentation ids.
Fig 1: Screenshot of output from an os detecting scan with verbose mode
A second method to find idle hosts is to use the NMAP scripting engine (NSE). NSE provides a number of extensions to NMAP in the form of small scripts written in Lua. These can be found in the scripts directory under the NMAP installation (in /usr/share/nmap/scripts on Linux and C:Program FilesNmapscripts on Windows). One of the scripts included in NMAP is ipidseq.nse which scans for incremental IP identification numbers (which are the fragmentation id's). You can run this script with the command:
$ sudo nmap --script=ipidseq [target_ip]
The results are self explanatory:
Fig 2: Screenshot of NMAP output using the ipidseq script
Performing an Idle Scan
Once we have identified a potential idle host we can then attempt an idle scan. This is done using the -sI flag. Scanning a target normally, then performing an idle scan, should reveal any discrepancies in access between your host and the idle host. Sometimes, however, idle scanning doesn't work. Many times this means that you must adjust the port that the idle scan is using on the idle zombie.
Fig 3: NMAP reporting a failed idle scan
You can adjust the port that the idlescan uses by providing an alternate port using a colon and a port following the idle target's IP address (such as 192.168.0.10:21). Note that this port can't be shown as 'filtered' or the scan will not work. Use one of the ports that NMAP has previously identified as open or closed on the idle machine.
Fig 4: Screenshot of an NMAP scan of a target
Fig 5: Screenshot of an NMAP idle scan of the same target using an idle host on the target's subnet
As Figure 3 and 4 illustrate, the target machine has quite a few ports that are available to the idle machine but not to the wider internet, a fact that is invisible by simply performing a regularly NMAP scan.
Potential Issues
It is important to note that idle scanning uses networking artifacts that might be mangled depending on intervening networking architecture. For instance, if your scanning machine is behind a small network address translation (NAT) device, or if your ISP prohibits spoofed outbound packets, idle scan attempts may fail. Generally speaking the closer you are to a "real" interent connection (i.e. a machine with an IP address directly accessible via the internet) the greater your chances of success.
Conclusion
Using idle scanning can reveal sensitive configuration information about targets via a side channel. Not only can this type of scan show services that might otherwise be invisible, it is also completely passive. This means that the target of the scan will never observe traffic from the actual source of the scans. Only the idle host will be aware of any contact with the scanning machine. This can allow attackers to perform reconnaissance to either perform a completely hidden scan, for instance by using an idle zombie in a third party organization making it extremely difficult to trace the origin of the scan, or to map trust relationships in an organization by using a zombie target within the target organization.
Defending against these types of attacks is extremely difficult, especially in the case where an attacker uses a third party idle zombie. By blocking inbound packets with source addresses from within your network you can effectively limit an attacker's ability to use internal zombie hosts, which will prevent trust mapping or probing of internal configurations, but this will not stop a scan using an external zombie. Being aware of this type of attack, however, should help illustrate the problem of attribution on the internet. Just because a scan is detected originating from a machine doesn't necessarily mean that the target machine actually initiated the scan.