svn merge --ignore-ancestry svn://svn.insecure.org/nmap@26621 svn://svn.insecure.org/nmap-exp/luis/nmap-os6
This is the IPv6 OS detection branch. "nmap -6 -O" works now, though at
this point it only prints fingerprints and not OS guesses, because we
need to collect more submissions.
Heretofore we have always extracted teh destination address directly
from the packet contents. But the raw packet bytes do not contain enough
information in one case: IPv6 link-local addresses. For those we really
need the scope ID, and for that we must pass this information all the
way down.
Before this, I got "no route to host" on OS link-local addresses. I
think that it was working on Linux only on accident, by the OS picking a
default interface or something.
Mac OS X appears to have a new address convention that I can't find
documented. The link-local address fe80:4::X:X:X:X stands for
fe80::X:X:X:X%en0, if en0 is the interface with index 4. (I.e., it would
be fe80::X:X:X:X%4 on Windows.) The number 4 could be different numbers.
The interface addresses seem to be stored with these pseudo-zone IDs at
a low level, because they appear that way when they come from libdnet.
This is what "nmap --iflist" shows:
lo0 (lo0) fe80:1::1/64 loopback up 16384
en0 (en0) fe80:4::xxxx:xxxx:xxxx:xxxx/64 ethernet up 1500 XX:XX:XX:XX:XX:XX
The OS X network tools seem to hide this. This is what "ifconfig" and
"netstat -rn -f inet6" show:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::xxxx:xxxx:xxxx:xxxx%en0 prefixlen 64 scopeid 0x4
fe80::1%lo0 link#1 UHLI lo0
fe80::xxxx:xxxx:xxxx:xxxx%en0 XX:XX:XX:XX:XX:XX UHLI lo0
(Not the "scopeid 0x4".) Also, if you use one of these addresses, it
magically transforms into one without the pseudo-ID (getaddrinfo does
this):
$ ping6 fe80:4::1234
PING6(56=40+8+8 bytes) fe80::xxxx:xxxx:xxxx:xxxx%en0 --> fe80::1234%en0
$ ping6 fe80:1::1234
PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1234%lo0
This translation is messing up our netmask comparisons for the purpose
of routing. If you use a normal link-local address starting with fe80:0,
then it doesn't compare equal with the fe80:4/64 interface address. If
you try to use the 4, then getaddrinfo turns it into fe80:0 anyway, and
the comparison still fails.
So for this reason I added a canonicalize_address function, which calls
getnameinfo on an address, then calls getaddrinfo on the returned
string, to mangle an address the same way the OS would do it. One would
hope this is a no-op in cases other than the one I have described.
Now "nmap --iflist" shows:
lo0 (lo0) fe80::1/64 loopback up 16384
en0 (en0) fe80::xxxx:xxxx:xxxx:xxxx/64 ethernet up 1500 XX:XX:XX:XX:XX:XX
Since OS X 10.7, we must declare whether we want the IPv6 sockets API to
work like RFC 2292 or RFC 3542. As far as I know, we are compatible with
both, so just pick the more recent one, which Apple says will become the
default in the future.
This restores the previous behavior of these functions, which was broken
in r24127, which itself was fixing another bug.
r24127 solved the problem of --data-length appending zeroes, not random
data, to ICMP and IGMP packets. But in doing so, it added a check that
the data argument is not NULL. OS detection uses a data argument of
NULL, expecting these functions to fill in zeroes in this case. The
result of this was that the IE probes were being sent with empty
payloads instead of 120 and 150 bytes.
state ~= "closed"
into
state == "open" or state == "open|filtered"
(state ~= "closed") matches "filtered", so the script was running
against hosts that had all the relevant ports filtered.
Added softmatch line for Microsoft SQL 2008 R2.
Added specificity to CPE data on Microsoft SQL Server matchlines.
Removed auto flag on the os cpe lines for MS SQL Server
In the case of a few of these scripts the only thing that was updated was the example text as the scripts relied on the creds library which handles the strings internally.
