Re: -sO for IPv6

[David Fifield <david () bamsoftware com>]

On Wed, Jun 15, 2011 at 05:40:27PM -0500, Dario Ciccarone (dciccaro) wrote:
> Hm. This may end in a "TL;DR" . . . 
>
> I tried it against a couple devices - some observations:
>
> 1) For the actual extension headers (Hop-by-Hop (0), Routing (43),
> Fragment (44), Destination Options (60), No Next Header (59)) - we're
> just setting the NH field on the IPv6 header to each value. There's no
> attempt to actually build a valid extension header (well, it IS valid
> for 59 ;)). I think it would be more accurate if the extension header
> was properly formed. I can provide pcaps for each one of them, if so
> needed.

This is the same situation as for IPv4. We only send proper payloads for
a small number of protocols (ICMPv6, TCP, UDP, SCTP) and for the rest we
send empty payloads. Please send your packet captures so we can make it
better.

> 2) Because of (1), 0, 43, 44 and 60 are erroneously reported as
> "open|filtered", with reason "no-response". Actually, the thing is that
> for the other ones being reported as "closed", the OS is indeed sending
> back an ICMPv6(4,1) - but for those four I mention before, it's sending
> back an ICMPv6(4,0) - which we aren't checking for as a return value.

Oops, you're right. In fact we are testing for ICMPv6(4, 0) (and marking
"open" in that case), but there is another bug that prevents that test
from happening.

> 3) On top - if a device between the nmap scanning host & the target is
> filtering traffic for those protocols, the filtered protocols are being
> reported as (again) "open|filtered", "no-response" - even when the
> filtering device *does send back* an ICMPv6(1,1) - which again, looks
> like we're not checking for.

We are checking for ICMPv6(1, 1) (dest unreachable, admin prohibited),
but it might not be taking effect due to the same bug I mentinoed above.

> 4) There will never be anything back for an IPv6 packet with NH = 59 -
> unless being filtered, and filtering device sending back ICMPv6(1,1).
> Should, IMHO, be assumed open - if you're doing IPv6, you *have* to
> support them all (0, 43, 44, 59 and 60) - so.

I think then that open|filtered/no-response is appropriate.

> 5) A Routing Header can either be type 0, 1 or 2 - RH0 was deprecated by
> RFC-5095. If the actual RH was to be sent, we should probably test for
> (at least) RH0 and RH2. It isn't enough to just test for "routing
> header"
>
> 6) Some devices, like Cisco IOS, can not only filter on a given
> extension header (ie: "deny ipv6 any any dest-option", to filter any
> IPv6 packet including a Destination Option extension header), but can
> also filter on a specific option type within the extension header (ie:
> "deny ipv6 any any dest-option-type 0" to filter a Destination Option
> extension header including a Pad1 option). This could also be
> implemented to further determine if *any packet with a given extension
> header* would be dropped/filtered, or only those with a specific option
> within their "payload"

I think that numbers 5 and 6 are better handled by a specialized script.
Protocol scanning is more like port scanning: try all these numbers and
see if they work. We don't have a way to express in the output table
that some variations of a protocol work and some don't, but that could
easily fit in a script with a portrule matching that particular
protocol.

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