Idle Scanning and related IPID games

Almost four years ago, security researcher Antirez posted an innovative new TCP port scanning technique. Idlescan, as it has become known, allows for completely blind port scanning. Attackers can actually scan a target without sending a single packet to the target from their own IP address! Instead, a clever side-channel attack allows for the scan to be bounced off a dumb "zombie" host. Intrusion detection system (IDS) reports will finger the innocent zombie as the attacker. Besides being extraordinarily stealthy, this scan type permits mapping out IP-based trust relationships between machines.

I assumed that a problem of this magnitude would generate an immediate response and patches from the OS vendors. Unfortunately, many have chosen to ignore the problem for years. Apparently, they believe this is just a "theoretical" issue which is not practical to exploit in the real world. To refute that position, and increase the pressure on vendors to fix the problem, I have released a robust Idlescan implementation in recent versions of Nmap. This paper describes the technique in detail and offers defenses that network administrators, ISPs, and OS vendors can use to mitigate the vulnerability.

Note that Idle scanning is only one of the security risks posed by predictable IPID sequence numbers. This paper describes several other information gathering attacks made possible by this characteristic.

Technique

While Idle scanning is rather sophisticated as far as port scanning methods go, one does not have to be a TCP/IP expert to understand it. You only need to understand a few basic facts:

- Most network servers listen on TCP ports, such as web servers on port 80 and mail servers on port 25. A port is considered "open" if an application is listening on the port, otherwise it is closed.
- One way to determine whether a port is open is to send a "SYN" (session establishment) packet to the port. The target machine will send back a "SYN|ACK" (session request acknowledgment) packet if the port is open, and a "RST" (Reset) packet if the port is closed.
- A machine which receives an unsolicited SYN|ACK packet will respond with a RST. An unsolicited RST will be ignored.
- Every IP packet on the Internet has a "fragment identification" number. Many operating systems simply increment this number for every packet they send. So probing for this number can tell an attacker how many packets have been sent since the last probe.

By combining these traits, it is possible to scan a target network while forging your identity so that it looks like an innocent "zombie" machine did the scanning. This technique is easiest to describe via a diagram. In the picture below, an attacker, A, is scanning a Target machine, while blaming the scan on some Zombie, Z. The boxes represent machines, and the lines represent packets. Brief English descriptions of the packets are printed on top of the lines, while actual TCP flags and distinctive packet information is printed below them:

As demonstrated by the diagram above, the target hosts responds differently to the Zombie depending on port state. If the probed port is open, the target sends a SYN|ACK to the Zombie. The Zombie does not expect this SYN|ACK, so it sends a RST back. By sending the RST, the Zombie causes its IPID sequence number to increment. The real attacker detects this in step 3. If the port is closed, the target sends a RST to the Zombie. Zombies ignore this unsolicited RST packet and do not increment their IPID sequence number.

Idlescan Advantages

The Idlescan techniques offer attackers many advantages over other popular scan types such as SYN and FIN scans. This is why we recommend important defenses to help protect your network against this attack. Here are some of the reasons attackers (or legitimate penetration testers) might utilize this scan method:

- Ultimate stealth scan -- There are many techniques people can use to shield their identity when scanning. Examples include using decoys (nmap -D) or half-open scanning (nmap -sS). But even these techniques require an attacker to send some packets to the target from her real IP address. Idlescan, on the other hand, is completely blind -- no packets are sent to the target from the true source address.

  One upshot of this is that intrusion detection (IDS) systems will generally light up and send alerts claiming that the zombie machine has launched a scan against them!

- Defeating packet filtering firewalls/routers -- IP source address filtering is a common security mechanism for limiting machines that may connect to a sensitive host. For example, a company database server might only allow connections from the public web server which accesses it. A home user might only allow ssh (interactive login) connections from his work machines.

  A more disturbing scenario occurs when some company bigwig demands that network administrators open a firewall hole so he can access internal network resources from his home IP address. This can happen when executives are unwilling or unable to use secure VPN alternatives.

  Idle scanning can frequently be used to map out these trust relationship. The key factor is that Idlescan results list open ports from the zombie host perspective. So a normal scan against the aforementioned database server might show no ports open. But performing an Idlescan while using the web server IP as the zombie could expose the trust relationship by showing the database-related service ports open.

  Mapping out these trust relationships can be very useful to attackers for prioritizing targets. The web server discussed above may seem mundane to an attacker until she notices its special database access.

Nmap Usage Examples

The first step is to find an appropriate zombie host. The host should not have much traffic (hence the name Idle Scan) and should offer predictable IPID values. Printers, Windows boxes, older Linux hosts, FreeBSD, and Mac OS boxes generally work fine. The latest versions of Linux, Solaris, and OpenBSD are immune as zombies, but any host can be a target of the scan. One way to determine host vulnerability is to simply try an Nmap Idle scan. Nmap will test the zombie and report whether it is reliable.

Performing these scans is quite easy. Simply provide a zombie hostname to the `-sI` option and Nmap does the rest. Here is a quick example:

    # nmap -P0 -p- -sI kiosk.adobe.com www.riaa.com

    Starting nmap V. 3.10ALPHA3 ( www.insecure.org/nmap/ )
    Idlescan using zombie kiosk.adobe.com (192.150.13.111:80); Class: Incremental
    Interesting ports on 208.225.90.120:
    (The 65522 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
    2306/tcp   open        unknown
    5631/tcp   open        pcanywheredata
    7937/tcp   open        unknown
    7938/tcp   open        unknown
    36890/tcp  open        unknown

    Nmap run completed -- 1 IP address (1 host up) scanned in 2594.472 seconds

From the scan above, we learn that the RIAA is not very security conscious (note the open PC Anywhere, portmapper, and Legato nsrexec ports). Since they apparently have no firewall, it is unlikely that they have an IDS. But if they do, it will show 'kiosk.adobe.com' as the scan culprit. The `-P0` option prevents Nmap from sending an initial ping to the RIAA machine. This slows the scan down (less timing info available), but ensures that no packets are sent to the target from your real IP. The scan took a long time because all 65535 TCP ports were scanned -- skip the "-p-" option if you only want well known ports plus 1-1024. Be sure to find your own zombies -- kiosk is not very reliable and is likely disappear or be closely monitored.

Defenses

Fortunately, there are several defenses which can be deployed to prevent most IPID-related attacks:

Network Administrators:

- Configure your firewalls/border routers to deny incoming packets with bogus source addresses (eg. that appear to come from machines within your network, reserved IPs like 10.X.X.X or 192.168.X.X, localhost IPs 127.X.X.X, etc. Any good firewall guide should provide more detailed guidance on these essential rules.
- Stateful firewall rules can also help against these sorts of attacks -- make sure your firewall offers this feature and that it is enabled.
- Try to run operating systems with less predictable IP ID sequences, such as recent versions of OpenBSD, Solaris, or Linux. While these operating systems are immune from becoming zombies with the current version of Nmap, they may not stop all IPID-related attacks. Further investigation is needed.
- Implement egress filtering to prevent spoofed packets from leaving your network. This prevents your employees/students from launching some of these attacks.

Internet Service Providers (ISPs)

- The most important protection ISPs can offer is utilizing egress filtering to prevent spoofed packets from leaving your networks. This prevents users from executing many nasty attacks in addition to stopping Idle scanning. Besides helping the Internet, egress filtering can save you from substantial costs investigating IP spoofing attacks.

OS Vendors

- One good approach is to use connection or peer-specific IPID sequences. Solaris does this, and it severely limits the information attackers can glean about other connections. Linux 2.4 also uses peer-specific IPID values (see net/ipv4/inetpeer.c). In addition, Linux 2.4 zeros the IPID fields in packets with the DF (Don't Fragment) bit set. After all, IP defragmentation is the only critical use of the ID field. Another approach (used by OpenBSD) is to randomize the IPID sequence. This is difficult to get right -- be sure the sequence does not repeat and that individual numbers will not be used twice in a short period.

Idlescan Challenges

I was going to discuss implementation challenges of writing fast, accurate Idle scanners. But very few of you are doing that, and those who are can read the source code to Nmap and other scanners. So I will only outline a few important points. This section also includes some challenges encountered by tool users.

- Performance -- Scanning one port at a time (as in the diagram above) would be horrendously slow for thousands of ports. Nmap gets around this by sending up to 100 probes in parallel. Normally, all ports will be closed and the Zombie IPID will not increment. If Nmap finds that the IPID did increment, it will narrow down on the open port(s) using a binary search approach.
- Non-idle hosts -- Idle scanning works by counting the number of packets sent by a zombie and assuming those packets are responses to packets originated by your target. Thus, extraneous packets sent by a non-idle zombie cause significant confusion. Nmap tries to counter this problem with probe retransmission and other techniques to detect false results. For example, Nmap knows something is wrong if it probes 6 ports and the IPID increases by 10 or 20. Nmap adjusts its timing and parallelism to compensate for slightly active hosts or dropped packets when they are detected. However, Nmap will not be reliable with any heavily active zombies. One technique in dealing with highly active zombies is to send a large number (dozens or hundreds) of probes to each port. This "brute force" technique can hide a small amount of "white noise" traffic. Unfortunately, the cost is significant bandwidth, slow scans, and the possibility of SYN flooding your target. Thomas Olofsson demonstrated a tool for doing this at his 2001 Black Hat Briefings presentation. His (Powerpoint) presentation slides are available here.
- Egress filtering -- If you cannot spoof packets due to egress filtering by your ISP, try a new ISP or (for advanced users) IP tunneling. You can also try bouncing off another machine on your same network (less likely to be filtered).
- Unsuitable zombies -- Some hosts will not work as zombies due to a clever operating system or substantial traffic. In most cases you can simply use a different zombie.

More fun with IPID prediction

While this paper focuses on utilizing predictable IPID sequences for port scanning, there are many other devious ways to exploit this information. Here is a brief list:

- Traffic Analysis -- Sequential IPID numbers expose the number of packets sent by a host over a given period. This can be used to estimate web site traffic, determine when people log on, etc.
- Host alias detection -- Sometimes a single host will have multiple IP addresses or ethernet interfaces. You can often determine which IPs match a given host by looking for similar IP ID sequence numbers.
- Load balancer demultiplexing -- This is almost the reverse of the technique above. Large sites often use load balancing equipment so that a single address maps to a small farm of servers. By noting the IPID values, you can often determine how many machines are behind the load balancer and which one you are connected with. For example, the "id" fields in the following hping2 execution make it pretty obvious that beta.search.microsoft.com is handled by two machines behind a load balancer (207.46.197.115).

      # hping2 -c 10 -i 1 -p 80 -S beta.search.microsoft.com.
      HPING beta.search.microsoft.com. (eth0 207.46.197.115): S set, 40 headers + 0 data bytes
      46 bytes from 207.46.197.115: flags=SA seq=0 ttl=56 id=57645 win=16616 rtt=21.2 ms
      46 bytes from 207.46.197.115: flags=SA seq=1 ttl=56 id=57650 win=16616 rtt=21.4 ms
      46 bytes from 207.46.197.115: flags=RA seq=2 ttl=56 id=18574 win=0 rtt=21.3 ms
      46 bytes from 207.46.197.115: flags=RA seq=3 ttl=56 id=18587 win=0 rtt=21.1 ms
      46 bytes from 207.46.197.115: flags=RA seq=4 ttl=56 id=18588 win=0 rtt=21.2 ms
      46 bytes from 207.46.197.115: flags=SA seq=5 ttl=56 id=57741 win=16616 rtt=21.2 ms
      46 bytes from 207.46.197.115: flags=RA seq=6 ttl=56 id=18589 win=0 rtt=21.2 ms
      46 bytes from 207.46.197.115: flags=SA seq=7 ttl=56 id=57742 win=16616 rtt=21.7 ms
      46 bytes from 207.46.197.115: flags=SA seq=8 ttl=56 id=57743 win=16616 rtt=21.6 ms
      46 bytes from 207.46.197.115: flags=SA seq=9 ttl=56 id=57744 win=16616 rtt=21.3 ms

      --- beta.search.microsoft.com. hping statistic ---
      10 packets tramitted, 10 packets received, 0% packet loss
      round-trip min/avg/max = 21.1/21.3/21.7 ms

- OS Detection -- As already discussed, operating systems differ wildly in how they generate IP ID numbers. Nmap uses this information to help determine what OS version a remote system is running. More details on this technique are available here.
- Firewall ruleset detection -- The IPID value can help map out firewall rulesets. Here is a simple example:
  1. Probe for the IPID of a target machine behind the firewall
  2. Send a ping packet "from" a host inside the firewall to that same target.
  3. Probe for the IPID again. If it increased by 2 (one for the ping reply and one for the 2nd IPID probe), your spoofed ping got through. Extraneous traffic can interfere, but retesting can ensure accuracy.
  This technique can be expanded in many ways -- I could (and may) write a full paper describing them. Note that all the steps above can be performed with Hping.

Related Links

- Nmap, which now includes Idlescan, is available at http://www.insecure.org/nmap/
- The basic IPID scan technique was invented by Antirez (Salvatore Sanfilippo). His home page is at http://www.kyuzz.org/antirez/.
- Antirez also developed the excellent Hping tool, which is tremendously useful for low-level IPID testing.
- LiquidK posted a proof-of-concept IPID scanner and coined the name "idlescan" in 1999. The URLs no longer work, but you can probably find his implementation via Google or Packetstorm if you are interested.
- Thomas Olofsson wrote and demonstrated an IPID scanning tool at the 2001 Black Hat Briefings. His (Powerpoint) presentation slides are available here and give a good overview of the basic technique. As mentioned earlier in this paper, his tool may be preferable to Nmap in cases where the "Idle zombie host" is not really Idle. Unfortunately, I do not have a working URL for his tool.