TCP Idle Scans in IPV6…

February 10, 2014


After discovering how to conduct the TCP Idle Scan in IPv6, 21 dif-ferent operating
systems and versions have been analyzed regarding their properties as idle host.
Among those, all nine tested Windows systems could be used as idle host. This shows
that the mistake of IPv4 to use predictable identification fields is being repeated
in IPv6. Compared to IPv4, the idle host in IPv6 is also not expected to remain idle,
but only not to send fragmented packets. To defend against this bigger threat, the
article also introduces short-term defenses for administrators as well as long term
defenses for vendors.

When trying to attack a target, one of the first steps performed by an attacker will be to execute a port scan in order to discover which services are offered by the system and can be attacked. In the traditional approach for port scanning, SYNs1 are sent directly to various ports on the target to evaluate which services are running.

However, this method is easy to detect and to be traced back to the attacker. To remain undetected, different methods for port scanning exist, all providing various advantages and disadvantages [8]. One of those methods is the TCP Idle Scan. With this port scanning technique, the attacker uses the help of a third-party system, the so-called idle host, to cover his tracks. Most modern operating systems have been improved so that they cannot be used as idle host, but research has shown that the scan can still be executed by utilizing network printers [11]. At first sight, IPv6 seems immune to the idle scan technique, as the IPv6 header no longer contains the identification field. However, some IPv6 traffic still uses an identification field, namely if fragmentation is used. Studying the details of IPv6 reveals that an attacker can force fragmentation between other hosts. The attack on IPv6 is trickier than on IPv4 but has the benefit that more machines will be suited as idle hosts. This is because we only require the idle host not to create fragmented
IPv6 traffic, whereas in IPv4 the idle host is not allowed to create traffic at all.

2. Background
The TCP Idle Scan is a stealthy port scanning method, which allows an attacker to scan a target without the need of sending a single IP-Packet containing his own IP address to the target. Instead, he uses the IP address of a third host, the idle host, for the scan. To be able to retrieve the results from the idle host, the attacker utilizes the identification field in the IPv4 header (IPID)2, which is originally intended for fragmentation.

3. Conducting the TCP Idle Scan in IPv6
This section deals with the characteristics of the TCP Idle Scan in IPv6. Compared to IPv4, where most modern operating systems use protection mechanisms against the scan, it is novel to conduct the scan in IPv6. Therefore, not all operating systems use the same protection mechanisms as in IPv4. To give an overview of the behavior from various operating systems, tests have been conducted with 21 different systems, and the results are shown and discussed.

4.Behavior of various systems
As stated previously, for executing the TCP Idle Scan in IPv6 it is a necessity that the identification value is assigned by the idle host on a predictable and global basis. To determine which operating systems form appropriate idle hosts 21 different operating systems and versions have been tested to establish their method of assigning the identification value. Among all the tested systems, six assigned the identification value on a random basis and can therefore not be used as idle host. Out of the remaining 15, five assigned their
values on a per host basis which makes also those systems unusable. Another system which can not be used as idle host is OS X 10.6.7, which does not accept PTB messages with a MTU smaller than 1280 bytes. The nine systems which are left, and can be used
as idle hosts for the TCP Idle Scan in IPv6, are all Windows operating systems. System Assignment method usable Android 4.1 (Linux 3.0.15) Per host, incremental

(1) X FreeBSD 7.4 Random X FreeBSD 9.1 Random X
iOS 6.1.2 Random X
Linux 2.6.32 Per host, incremental (2) X
Linux 3.2 Per host, incremental (1) X
Linux 3.8 Per host, incremental X
OpenBSD 4.6 Random X
OpenBSD 5.2 Random X
OS X 10.6.7 Global, incremental (3) X
OS X 10.8.3 Random X
Solaris 11 Per host, incremental X
Windows Server 2003 R2 64bit, SP2 Global, incremental √
Windows Server 2008 32bit, SP1 Global, incremental √
Windows Server 2008 R2 64bit, SP1 Global, incremental by 2 √
Windows Server 2012 64bit Global, incremental by 2 (4) √
Windows XP Professional 32bit, SP3 Global, incremental (5) √
Windows Vista Business 64bit, SP1 Global, incremental √
Windows 7 Home Premium 32bit, SP1 Global, incremental by 2 √
Windows 7 Ultimate 32bit, SP1 Global, incremental by 2 √
Windows 8 Enterprise 32 bit Global, incremental by 2 (4) √
(1) Host calculates wrong TCP checksum for routes with PMTU < 1280
(2) No packets are sent on route with PMTU < 1280
(3) Does not accept Packet Too Big messages with MTU < 1280
(4) Per host offset
(5) IPv6 disabled by default
TABLE 1: List of tested systems

A special behavior occurred when testing Windows 8 and Windows Server 2012. A first analysis of the identification values sent to different hosts gives the impression that the values are assigned on a per-host-basis and start at a random initialization
value. A closer investigation though revealed that the values being assigned for one system are also incremented if messages are sent to another system. This leads to the conclusion that those operating systems use a global counter, but also a random offset for each host, which is added to the counter to create the identification value. However, the global counter is increased each time a message is sent to a host. For the TCP Idle Scan in IPv6, this means that the systems are still suitable as idle hosts, as from the view of the attacker, the identification value received from the idle host increases each time the idle host sends a message to the target. Being still usable as
idle host, it is a complete mystery to us what should be achieved with this behavior.

6. Conclusion
This paper has shown that by clever use of some IPv6 features, the TCP Idle Scan can successfully be transferred from IPv4 to IPv6. Therefore, this type of port scan remains a powerful tool in the hands of an attacker who wants to cover his tracks, and a challenge for anybody who tries to trace back the scan to its origin. The fact that major operating systems assign the identification value in
the fragmentation header in a predictable way also drastically increases the chances for an attacker to find a suitable idle host for executing the TCP Idle Scan in IPv6. Because the idle host is also not required to be completely idle, but only expected not to create IPv6 traffic using the fragmentation header, this chances are increased additionally. What remains is the question why it is still a common practice to utilize predictable identification values. The danger of predictable sequence numbers has already
been disclosed by Morris [13] in 1985. Although his article covered TCP, the vulnerabilities were caused by the same problem: a predictable assignment of the sequence number. For this reason, he advised to use random sequence numbers. With the TCP Idle Scan in IPv4 being first discovered in 1998, it has been shown that the necessity of unpredictable identification values also applies to IPv4. This article has shown that also in IPv6, predictable identification values facilitate attacks and should be substituted with random values. To prove that the TCP Idle Scan in IPv6 works in practice, a proof of concept has been created using the python program scapy5, which allows easycreation and manipulation of packets. The proof of concept can be found in the appendix. Furthermore, the security scanner Nmap6, which already provided a very elaborated version of the TCP Idle Scan in IPv4, has been extended in order to also handle the TCP Idle Scan in IPv6 [10]. Until vendors are able to provide patches for assigning unpredictable identification
values in the fragmentation header, administrators are advised to implement the short-term protection mechanisms described in Section 5. Additionally, one might consider an update of RFC 1981, which forces a host to append an empty fragmentation header to every IPv6 packet after receiving an ICMPv6 Packet Too Big message with an MTU smaller than the IPv6 minimum MTU. Likewise, updating RFC 2460 towards an obligatory random assignment of the identification value in the fragmentation header should be considered as well.

p/s:- This article is taken from the excerpt of Hack In The Box  Magazine , January 2014 – Vol 4 issue 10.

– Last Year PIKOM PC Fair was the best PC Fair that I’ve ever attend , on December  2013 last year….Great exhibiton from all the computer manufacturer…One from MSI is the best. Not to mention Kaspersky Booth….Bought a Pendrive 8GB…

– Well … this is my latest post for this year , 2014 ….Hope to see you soon…..


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: