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.
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.
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.
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 ( 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.
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.
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.
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:
- Probe for the IPID of a target machine behind the firewall
- Send a ping packet "from" a host inside the firewall to that same
target.
- 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.
- Nmap, which now includes Idlescan, is available at https://nmap.org/
- 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.