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:

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:

Idlescan technique diagram

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:


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:

Internet Service Providers (ISPs) OS Vendors
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.


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:


Related Links