Re: IPv6 OS Detection: Call for fingerprinters!!

["Luis MartinGarcia." <luis.mgarc () gmail com>]

On 07/07/2011 07:14 AM, Dario Ciccarone (dciccaro) wrote:
> It works OK for me when using a global unicast address, but it doesn't
> work at all when trying to use a link-local address and the following
> command line:
>
> sudo ./ipv6fp.py fe80::20a:b8ff:fea9:5944 --ot=23 --ct=9999
> --interface=eth0 --send-eth --addr4=192.168.1.1
>
> I'm getting an "ERROR: Could not resolve target's MAC address" error.
> Checking the source code, it looks like the problem is on
> get_target_mac_address() - for the ICMPv6 Neighbor Solicitation message,
> you're using as L2 destination the broadcast address, and as destination
> on the IPv6 packet header the same address you're trying to find the L2
> address for. That wont' work.
>
> RFC-4861, Section 4.3
>
>    Nodes send Neighbor Solicitations to request the link-layer address
>    of a target node while also providing their own link-layer address to
>    the target.  Neighbor Solicitations are multicast when the node needs
>    to resolve an address and unicast when the node seeks to verify the
>    reachability of a neighbor.
>
> Then we need to use as destination a multicast NS - if we keep reading:
>
>       Destination Address
>                      Either the solicited-node multicast address
>                      corresponding to the target address, or the target
>                      address.
>
> The solicited-node multicast address format is FF02:0:0:0:0:1:FFXX:XXXX
> - for our example, FF02::1:FFA9:5944. That should be the destination
> address on the IPv6 header - not the unicast link-local address we're
> trying to get the L2 address for.
>
> And if we're doing multicast for the L3 destination address, then we
> also need to do multicast for the L2 destination address - from
> RFC-2464, section 7:
>
>    An IPv6 packet with a multicast destination address DST, consisting
>    of the sixteen octets DST[1] through DST[16], is transmitted to the
>    Ethernet multicast address whose first two octets are the value 3333
>    hexadecimal and whose last four octets are the last four octets of
>    DST.
>
> So, following our example, our L2 destination address should be
> 33:33:FF:A9:59:44.
>
> And so I don't look like I'm whining ;) - attached, a working diff
> implementing both changes to the get_target_mac_address() function. I'm
> doing the "inet_pton" step so I don't have to reinvent the wheel here,
> in case the destination IPv6 address provided in the command-line is
> something like FE80::1 or similar. Could, however, use a bit of
> error-checking logic. Or rewrite/beautify as needed :)
>
> Thanks,
> Dario



Hi Dario,

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

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.

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.

Again, thanks for your help. Best regards,

Luis MartinGarcia.


 










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