RE: IPv6 OS Detection: Call for fingerprinters!!

["Dario Ciccarone (dciccaro)" <dciccaro () cisco com>]

Luis Martin: 

> Hi Dario,
>
> Thank you very much for reporting and fixing this bug. I have 
> committed
> it in SVN rev r24708.

Yeah, well, looks like I stopped reading the RFC too soon - RFC-4861
also reads:

<snip>
   Possible options:

      Source link-layer address
                     The link-layer address for the sender.  MUST NOT be
                     included when the source IP address is the
                     unspecified address.  Otherwise, on link layers
                     that have addresses this option MUST be included in
                     multicast solicitations and SHOULD be included in
                     unicast solicitations.
<snip>

So, here attached, yet-another-diff, this one to be applied to ipv6fp.py
revision 24716 - adding the Source Link-Layer Address option to the NS
message. I also added a try/except clause, but it's kind of useless -
there is no try/except on scapy, so if you happen to pass the script a
malformed IPv6 address, scapy is going to traceback before we get here,
so . . . Maybe you could do the try/except w/ inet_pton() right after
parsing the command-line arguments, and before actually doing anything.
Your's and David's call :)

> However, it is a bit weird that it didn't work for you. I had 
> no problem
> resolving MAC addresses in my tests. Of course, I  agree that 
> your patch
> makes the script perform the Neighbor Discovery in the proper way,
> exactly how the standard suggests.

Ah, yes, about that. I run the "broadcast NS" version against a bunch of
devices (OpenSUSE, Thecus NAS, Mac OS/X, AppleTV, iPhone, HP LaserJet
printer, multiple IOS versions). Almost all of them actually replied to
the broadcast NS. Cisco IOS, tried three releases - two of them did
reply with a NA to the broadcast NS, while one of them did not. 

As you can already guess, the one that did NOT was the one I originally
used to test the script against ;)


> I conducted my tests against a set of 13 different operating 
> systems and
> all of them responded to the solicitations. The systems were run in a
> virtual machine. Maybe in your configuration there is a router that is
> blocking packets addressed to the Ethernet multicast address? In my
> case, there was no router, just a virtual LAN that my laptop 
> and the VM
> shared.

Nope, no ACL blocking any traffic - just different behaviour. Also saw
this specific release doing things different than other IOS releases,
but those are still under investigation.

Talking about OS tests - I haven't had the time to look at all the tests
that ipv6fp is performing, but one of the things I saw during my testing
is that some OSes, on reception of the NS, would reply with a NA and
issue their own NS, while others would issue the NS first and then
answer the NA. In case you think it would be a worthwhile test to also
try to distinguish between one IPv6 stack implementation and another -
if they answer the NS first, before sending their NA, or after sending
their own NS. As this is all local segment only, slim possibility of the
test being messed up by latency/load/others, IMHO.

Thanks,
Dario

Attachment: get_target_mac_address_24716.diff
Description: get_target_mac_address_24716.diff

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