Re: [PATCH] TCP Idle Scan in IPv6

["Mathias Morbitzer" <m.morbitzer () runbox com>]

On Sun, 13 Oct 2013 11:03:49 -0700, david <david () bamsoftware com> wrote:

> > The attached patch should fix all the issues pointed out. 
>
> I'm having some trouble getting results with this patch. I set up a test
> IPv6 network:
>       abcd::1 GNU/Linux scanning host
>       abcd::2 Windows 7 VM zombie
>       abcd::3 GNU/Linux target
> Is there any more information I can send you?

Are you testing on a physical network, or with VMs? I did most of my tests with VMs, and sometimes encountered a 
slightly different behavior when I used a physical host as idle host. Of course, it should work in both situations, but 
this could be the reason why it works for me, but not for you. 
And because it could be a TCP checksum problem: Which Linux version are you using on the scanning host and the target? 
? 

> Here is what I tried first. Notice the warning about -Pn, the detected
> "Class: Incrementing by 2", and the error "Even though your Zombie".
>
> $ sudo ./nmap -6 --top-ports 10 -sI '[abcd::2]:22' abcd::3 --packet-trace
> WARNING: Many people use -Pn w/Idlescan to prevent pings from their true IP.  On the other hand, timing info Nmap 
> gains from pings can allow for faster, more reliable scans.
> Starting Nmap 6.41SVN ( http://nmap.org ) at 2013-10-13 09:29 PDT
> SENT (2.1294s) ICMPv6 (58) abcd::1 > ff02::1:ff00:3 (type=135/code=0) hopl=255 flow=0 payloadlen=32
> RCVD (2.1297s) ICMPv6 (58) abcd::3 > abcd::1 (type=136/code=0) hopl=255 flow=0 payloadlen=32
> SENT (2.3091s) ICMPv6 (58) abcd::1 > abcd::2 (type=128/code=0) hopl=255 flow=0 payloadlen=1226
> RCVD (2.3091s) ICMPv6 (58) abcd::1 > ff02::1:ff00:2 (type=135/code=0) hopl=255 flow=0 payloadlen=32
> RCVD (2.3098s) ICMPv6 (58) abcd::2 > ff02::1:ff00:1 (type=135/code=0) hopl=255 flow=0 payloadlen=32
> RCVD (2.3099s) ICMPv6 (58) abcd::1 > abcd::2 (type=128/code=0) hopl=255 flow=0 payloadlen=1226
> RCVD (2.3099s) ICMPv6 (58) abcd::1 > abcd::2 (type=136/code=0) hopl=255 flow=0 payloadlen=32
> RCVD (2.3108s) ICMPv6 (58) abcd::2 > abcd::1 (type=129/code=0) hopl=128 flow=0 payloadlen=1226
> SENT (2.3809s) ICMPv6 (58) abcd::1 > abcd::2 (type=2/code=0) hopl=255 flow=0 payloadlen=1222
> SENT (2.3810s) ICMPv6 (58) abcd::3 > abcd::2 (type=128/code=0) hopl=255 flow=0 payloadlen=1226
> SENT (2.3912s) ICMPv6 (58) abcd::3 > abcd::2 (type=2/code=0) hopl=255 flow=0 payloadlen=1222
> SENT (2.4893s) TCP abcd::1:54287 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450249 win=1024 <mss 1460>
> RCVD (2.4897s) TCP abcd::2:22 > abcd::1:54287 R hopl=128 flow=0 payloadlen=28 seq=2604933148 win=0
> SENT (2.5201s) TCP abcd::1:54288 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450250 win=1024 <mss 1460>
> RCVD (2.5204s) TCP abcd::2:22 > abcd::1:54288 R hopl=128 flow=0 payloadlen=28 seq=2604933148 win=0
> SENT (2.5507s) TCP abcd::1:54289 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450251 win=1024 <mss 1460>
> RCVD (2.5511s) TCP abcd::2:22 > abcd::1:54289 R hopl=128 flow=0 payloadlen=28 seq=2604933148 win=0
> SENT (2.5814s) TCP abcd::1:54290 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450252 win=1024 <mss 1460>
> RCVD (2.5818s) TCP abcd::2:22 > abcd::1:54290 R hopl=128 flow=0 payloadlen=28 seq=2604933148 win=0
> SENT (2.6121s) TCP abcd::1:54291 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450253 win=1024 <mss 1460>
> RCVD (2.6125s) TCP abcd::2:22 > abcd::1:54291 R hopl=128 flow=0 payloadlen=28 seq=2604933148 win=0
> SENT (2.6428s) TCP abcd::1:54292 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450254 win=1024 <mss 1460>
> RCVD (2.6432s) TCP abcd::2:22 > abcd::1:54292 R hopl=128 flow=0 payloadlen=28 seq=2604933148 win=0
> Idle scan using zombie abcd::2 (abcd::2:22); Class: Incrementing by 2
> SENT (2.6434s) TCP abcd::3:54286 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450249 win=1024 <mss 1460>
> SENT (2.6937s) TCP abcd::3:54286 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450250 win=1024 <mss 1460>
> SENT (2.7440s) TCP abcd::3:54286 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450251 win=1024 <mss 1460>
> SENT (2.7943s) TCP abcd::3:54286 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3022450252 win=1024 <mss 1460>
> SENT (3.0946s) TCP abcd::1:54321 > abcd::2:22 SA hopl=255 flow=0 payloadlen=24 seq=3918816763 win=1024 <mss 1460>
> RCVD (3.0951s) TCP abcd::2:22 > abcd::1:54321 R hopl=128 flow=0 payloadlen=28 seq=950163425 win=0
> Even though your Zombie (abcd::2; abcd::2) appears to be vulnerable to IP ID sequence prediction (class: Incrementing 
> by 2), our attempts have failed.  This generally means that either the Zombie uses a separate IP ID base for each 
> host (like Solaris), or because you cannot spoof IP packets (perhaps your ISP has enabled egress filtering to prevent 
> IP spoofing), or maybe the target network recognizes the packet source as bogus and drops them
> QUITTING!

It seems that the idle host does not answer to the packets the attacker spoofs in the name of the target. (The 5 
SYN/ACKs which are sent after reporting the idle host IPID class). What I don't understand is why this works in IPv4, 
but not in IPv6. 
Establishing a TCP connection (or pinging) from the target to the idle host works? If yes, could you please check with 
tcpdump if the spoofed packets arrive at the idle host and have the correct TCP-checksum? And if the idle host sends a 
reply to back to the target? (probably not, otherwise its IPID would increase)


> Sometimes I get different errors at the end:
>
> Your IP ID Zombie (abcd::2; abcd::2) is behaving strangely -- suddenly cannot obtain IP ID
> QUITTING!
> Idle scan zombie abcd::2 (abcd::2) port 22 cannot be used because it has not returned any of our ICMPv6 Echo Requests 
> -- perhaps it is down or firewalled.
> QUITTING!

While testing, I learned that after executing the scan multiple times, Windows 7 refuses to answer any more ICMPv6 Echo 
Requests. There seems to be a security mechanism in place which stops responses after a certain amount of messages is 
received. This probably happens to protect from flooding. Restarting the Windows host or waiting a bit solves this 
issue. In a real life scenario, this should not be a problem, as this problem only occurs if the scan is executed 
multiple times within a short period of time, as this is done only while testing. 

> If I comment out the "Even though your Zombie" error, I get scan output,
> but every port is closed|filtered, even though 22 is open on abcd::3.
> Idle scan using IPv4 of the same hosts find port 22 open.
>
> Nmap scan report for abcd::3
> Host is up (0.00035s latency).
> PORT     STATE           SERVICE
> 21/tcp   closed|filtered ftp
> 22/tcp   closed|filtered ssh
> 23/tcp   closed|filtered telnet
> 25/tcp   closed|filtered smtp
> 80/tcp   closed|filtered http
> 110/tcp  closed|filtered pop3
> 139/tcp  closed|filtered netbios-ssn
> 443/tcp  closed|filtered https
> 445/tcp  closed|filtered microsoft-ds
> 3389/tcp closed|filtered ms-wbt-server

As stated above, the reason for this is probably because the idle host is not answering to packets from the target. 
Therefore, no increase in the IPID, and the port is stated closed although being open. 

 
> This last one was an error on my part, because I was using my own
> address ([abcd::1]:22) as the zombie address. But the "Malformed packet
> received" error kills the whole Nmap process, and it probably shouldn't
> do that.
>
> $ sudo ./nmap -6 -Pn --top-ports 10 -sI '[abcd::1]:22' abcd::3 --packet-trace
> Starting Nmap 6.41SVN ( http://nmap.org ) at 2013-10-13 09:24 PDT
> SENT (0.1280s) ICMPv6 (58) abcd::1 > ff02::1:ff00:3 (type=135/code=0) hopl=255 flow=0 payloadlen=32
> RCVD (0.1283s) ICMPv6 (58) abcd::3 > abcd::1 (type=136/code=0) hopl=255 flow=0 payloadlen=32
> SENT (0.7730s) ICMPv6 (58) abcd::1 > abcd::1 (type=128/code=0) hopl=255 flow=0 payloadlen=1226
> RCVD (0.7729s) ICMPv6 (58) abcd::1 > abcd::1 (type=128/code=0) hopl=255 flow=0 payloadlen=1234
> RCVD (0.7730s) ICMPv6 (58) abcd::1 > abcd::1 (type=129/code=0) hopl=64 flow=0 payloadlen=1234
> SENT (0.8797s) ICMPv6 (58) abcd::1 > abcd::1 (type=2/code=0) hopl=255 flow=0 payloadlen=1222
> SENT (0.8799s) ICMPv6 (58) abcd::3 > abcd::1 (type=128/code=0) hopl=255 flow=0 payloadlen=1226
> SENT (0.8902s) ICMPv6 (58) abcd::3 > abcd::1 (type=2/code=0) hopl=255 flow=0 payloadlen=1222
> SENT (0.9519s) TCP abcd::1:57726 > abcd::1:22 SA hopl=255 flow=0 payloadlen=24 seq=3917294392 win=1024 <mss 1460>
> RCVD (0.9519s) TCP abcd::1:57726 > abcd::1:22 SA hopl=255 flow=0 payloadlen=32 seq=3917294392 win=1024 <mss 1460>
> SENT (1.0879s) ICMPv6 (58) abcd::1 > abcd::1 (type=128/code=0) hopl=255 flow=0 payloadlen=1226
> RCVD (1.0878s) ICMPv6 (58) abcd::1 > abcd::1 (type=128/code=0) hopl=255 flow=0 payloadlen=1234
> RCVD (1.0879s) ICMPv6 (58) abcd::1 > abcd::1 (type=129/code=0) hopl=64 flow=0 payloadlen=1234
> SENT (1.1677s) ICMPv6 (58) abcd::1 > abcd::1 (type=2/code=0) hopl=255 flow=0 payloadlen=1222
> SENT (1.1678s) ICMPv6 (58) abcd::3 > abcd::1 (type=128/code=0) hopl=255 flow=0 payloadlen=1226
> SENT (1.1780s) ICMPv6 (58) abcd::3 > abcd::1 (type=2/code=0) hopl=255 flow=0 payloadlen=1222
> Malformed packet received
> SENT (1.2095s) TCP abcd::1:57727 > abcd::1:22 SA hopl=255 flow=0 payloadlen=24 seq=3917294393 win=1024 <mss 1460>

I fully agree with you. In IPv4, when you state your own host as idle host, you receive an error message saying that 
this is not possible. For some reason, this does not seem to work in IPv6. I guess the code needs to be adapted to 
check for all IPv6 addresses, and not only for one. I will work on this as soon as I have access to my testing 
environment again, which will be in one or two weeks time.


Best,
Mathias Morbitzer

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/