Re: [PATCH] TCP Idle Scan in IPv6

[Mathias Morbitzer <m.morbitzer () student ru nl>]

Here is the list of the operating systems I tested: 

System | Assignment of Identification
 -----------------------------------------------------------------
 Android 4.1 (Linux 3.0.15) | Per host, incremental (1)
 FreeBSD 7.4 | Random
 FreeBSD 9.1 | Random
 iOS 6.1.2 | Random
 Linux 2.6.32 | Per host, incremental (2)
 Linux 3.2 | Per host, incremental (1)
 Linux 3.8 | Per host, incremental
 OpenBSD 4.6 | Random
 OpenBSD 5.2 | Random
 OS X 10.6.7 | Global, incremental (3)
 OS X 10.8.3 | Random
 Solaris 11 | Per host, incremental
 Windows Server 2003 R2 Standard 64bit, SP2 | Global, incremental
 Windows Server 2008 Standard 32bit,  SP1 | Global, incremental
 Windows Server 2008 R2 Standard 64bit, SP1 | Global, incremental by 2
 Windows Server 2012 Standard 64bit | Global, incremental by 2
 Windows XP Professional 32bit, SP3 | Global, incremental (4)
 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
------------------------------------------------------------------
(1) Hosts calculates wrong TCP checksum for routes with PMTU < 1280
(2) PMTU < 1280 results in DoS
(3) Does not accept PMTU < 1280
(4) IPv6 disabled by default

So, to sum up: Every Windows operating system can be used as zombie, all others I tested can't. 

 
> The change to get_ipid_sequence needs some more thought. When you are
> dealing with 16-bit IPv4 ID values, and you start treating them as
> 32-bit, you will have calculation errors at the 16-bit boundary.
> Imagine
> two consecutive IP ID values are 0xfffe and 0x0001.
> (u16) 0x0001 - (u16) 0xfffe == 3
> but
> (u32) 0x0001 - (u32) 0xfffe == 4294901763
> Do you have ideas as to how to account for this? Perhaps you need to
> sequence calculation to be aware of whether it is handling 16-bit or
> 32-bit values.

Thank you for pointing that out, I did not think about that. 

As far as I understand, this concerns only these three lines:
235: ipid_diffs[i - 1] = ipids[i] - ipids[i - 1]; 
237: ipid_diffs[i - 1] = (u16) (ipids[i] - ipids[i - 1] + 65536);
261: ipid_diffs[i] -= 256;
263: ipid_diffs[i]--;

Those are the only ones were calculations are done with the ipid_diffs[] values. 
If so, I would just put a  "if (o.af() == AF_INET4) ..." before those lines, and try to handle the values correctly 
depending on if they are 16 or 32 bits, like this:

237 in IPv4: ipid_diffs[i - 1] = (u16) (ipids[i] - ipids[i - 1] + 65536); 
237 in IPv6: ipid_diffs[i - 1] = (u32) (ipids[i] - ipids[i - 1] + 4294967296);

261 in IPv4: ipid_diffs[i] = (u16) ipid_diffs[i] - 256;
261 in IPv6: ipid_diffs[i] -= 256;

263 in IPv4: ipid_diffs[i] = (u16) ipid_diffs - 1;
263 in IPv6: ipid_diffs[i]--;

Let me know what you think about that approach. 


> I saw you added a new IPID_SEQ_INCR_BY_2, which is probably the right
> way to do it. However, not only idle scan uses the IPID_SEQ
> classifications; OS detection uses them as well. Specifically, we need
> to decide what to do with IPID_SEQ_INCR_BY_2 in make_aval_ipid_seq.
> This
> is the code that controls what gets printed for the SEQ.TI, SEQ.CI,
> and
> SEQ.II IPv4 OS detection tests:
> http://nmap.org/book/osdetect-methods.html#osdetect-ti.
> We have two options: one is to add a new value for "increment by 2",
> for
> instance to make TI=2 possible; and the other is to find out what
> hosts
> having "increment by 2" behavior are currently being classified as,
> and
> make hosts that increment by 2 map to this value, for instance TI=I or
> TI=R.
> What did get_ipid_sequence return for hosts that increment by 2,
> before
> your patch causing them to be IPID_SEQ_INCR_BY_2?

Before my patch, get_ipid_sequence returned "Incremental" instead of "Incremental by 2". (Which caused the scan to fail 
because it was expecting lower increments)
So, hosts which increment by 2 are currently classified as "incremental". 

It should not be much of an issue to apply the second solution and map the hosts to this value, but in my opinion it 
would be nicer to add a value for "increment by 2". 
This might also allow a better OS detection, as we have (in IPv6) for example Windows 7 that increments by 2, and 
Windows Vista that increments by 1. 
Also, there are operating systems like windows 7 which increment by 1 in IPv4, and by 2 in IPv6, which should allows 
allow to limit the pool of possible OS for OS detection. 

And not to forget, in previous research I stumbled across network printers which assigned the IPID incremental by 9. 
They should probably also get their own value at a certain point instead of mapping all the "increment by x" to the 
same, simple "incremental". 

That is my opinion, but I do not have much expertise with the OS detection, so I will leave this decision up to 
somebody else. 


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