TCP Idle Scans in IPv6 presented at HITBSecConf Malaysia 2013

by N/a ,

URL : The most stealthy port scan technique in IPv4 is the TCP Idle Scan, which hides the identity of the attacker. With this technique, the attacker spoofs messages of a third computer, the so-called idle

Summary : With the slowly approaching upgrade of IPv4 with IPv6, one will not be able anymore to conduct the TCP Idle Scan as previously, as the identification value has been removed in the IPv6 header.
At first sight, IPv6 seems immune to the idle scan technique due to this removal. 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 the use of the IPv6 extension header for fragmentation between other hosts. This is achieved by sending an ICMPv6 Packet Too Big (PTB) message which specifies a value smaller than the IPv6 minimum MTU in its MTU field. Although the extension header for fragmentation appended to the IPv6 packets is empty, it contains the identification field, which is the only relevant field for the attacker.
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.
Knowing how to force the idle host to use the IPv6 extension header for fragmentation, the TCP Idle Scan in IPv6 can be executed as follows:
1. First, the attacker sends a spoofed ICMPv6 Echo Request to the idle host, with the source address of the target. This Echo Request contains a big amount of data and will therefore be fragmented.
2. Due to the spoofed source address, the idle host will answer with an ICMPv6 Echo Response directed to the target.
3. Now the attacker spoofs a PTB message with a MTU smaller than the IPv6 minimum MTU and the source address of the target and sends it to the idle host. This causes the idle host to append the extension header for fragmentation to all IPv6 packets sent to the target even if there is no need to fragment the packet.
4. In the next step, the attacker sends a spoofed ICMPv6 Echo Request from his real source address to the idle host. Like before, this Echo Request contains a big amount of data and will therefore be fragmented.
5. Due to the size of the ICMPv6 Echo Request, the extension header for fragmentation is also used in the ICMPv6 Echo Response, which allows the attacker to determine the idle host’s currently used identification value.
6. Additionally, the attacker now sends a PTB message to the idle host from his real source address, specifying an MTU smaller than the IPv6 minimum MTU of 1280 bytes. The idle host will now also append an extension header for fragmentation to every IPv6 packet sent to the attacker. From this point onward, the scan can be executed identically to IPv4 due to the idle host appending an extension header for fragmentation to all its IPv6 packages sent to the idle host and the target.
7. Now, the attacker sends a SYN to the target, addressed to the port he wants to scan, using as source address the address of the idle host.
8. If the port on the target is closed, an RST will be sent to the idle host. If the scanned port on the target is open, the host will send a SYN/ACK.
9. In case of receiving a RST, the idle host will not execute further actions. But if a SYN/ACK is received, it will answer by sending a RST. As the idle host appends an empty extension header for fragmentation to all packets being sent to the target, it will use its next available identification value in the answer.
10. In order to request the result of the scan, the attacker sends a SYN/ACK to the idle host.
11. The received RST will now be analyzed by the attacker regarding its identification value in the extension header for fragmentation. If it increased once compared to the identification stored in step 5, it can be reasoned that the idle host did not send a RST, therefore the scanned port on the target is closed. If the identification incremented twice, the idle host had to send a RST, and therefore the port on the target is open.
Compared to IPv4, the requirements for the idle host regarding idleness are less limiting in IPv6. In IPv4, the idle host was not allowed to create traffic at all due to the identification value being a static part of the IPv4 header. In IPv6, the limitations are on communication using the extension header for fragmentation. While executing the TCP Idle Scan in IPv6, an idle host communicating with a fourth party via IPv6 would not disturb the scanning process, as long as the IPv6 packets being sent from the idle host to the fourth party do not use the IPv6 extension header for fragmentation.
To analyze which operating systems are suitable as idle hosts for the TCP Idle Scan in IPv6, 21 different operating systems have been tested. Out of those 21, nine can be used as idle hosts, which are all tested Windows operating systems. Combined with the fact that the idle host is not expected to remain idle, but only not to create traffic requiring the extension header for fragmentation, this will make it much easier to find an idle host for the TCP Idle Scan in IPv6 than it was in IPv4.
Defense mechanisms against the TCP Idle Scan in IPv6 are techniques against IP spoofing, stateful firewalls and, most important, a random assignment of the identification value in the IPv6 extension header for fragmentation, which should be applied by the vendor.