Re: --win_help

[Fyodor <fyodor () insecure org>]

On Mon, Dec 19, 2005 at 01:53:08PM +0100, Baumgart, Alexander (K-GOT-1) wrote:
> ************************INTERFACES************************
> DEV  (SHORT) IP/MASK            TYPE     UP MAC
> eth0 (eth0)  10.33.56.221/24    ethernet up 00:0B:5D:24:7A:F7
> eth1 (eth1)  192.168.120.254/24 ethernet up 00:07:77:64:09:32
[cut]
> 192.168.120.254 is a "AVM FRITZ!web PPP over ISDN", that make the trouble.
> Its per default enable and unplugged.

That certainly casts into question the interface info, which is
obtained from libdnet.  If the interface is known by the system to be
unplugged, I don't think it should be counted as UP.  We get that
from libdnet (in tcpip.cc) as so:

dcrn->ifaces[numifaces].device_up = (entry->intf_flags & INTF_FLAG_UP)? true : false;

Dnet decides if a device is up in intf-win32.c:

if (ifrow->dwAdminStatus == MIB_IF_ADMIN_STATUS_UP)
  entry->intf_flags |= INTF_FLAG_UP;

It looks like Microsoft also has a dwOperStatus with values such as
'MIB_IF_OPER_STATUS_DISCONNECTED' if the interface is unplugged.  See:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mib/mib/mib_ifrow.asp

It sounds to me like we should change libdnet to check that as well,
and consider the interface down if it is disconnected.

This brings us to the next problem.  If this is an "AVM FRITZ!web PPP
over ISDN", why is it considered ethernet?  It even has a supposed MAC
address listed.  Is that legitimate for this device?  I know nothing
of this device, but one would expect it to be PPP given the name.  As
before, Nmap gets this (ethernet) from libdnet.  In tcpip.cc:

   if (entry->intf_type & INTF_TYPE_ETH) {
      dcrn->ifaces[numifaces].device_type = devt_ethernet;
         /* Collect the MAC address since this is ethernet */
            memcpy(dcrn->ifaces[numifaces].mac,
      &entry->intf_link_addr.addr_eth.data, 6);
   }

And how does libdnet get the information?  Again, in intf-win32.c:

entry->intf_type = (uint16_t)ifrow->dwType;

As before, ifrow is an MIB_IFROW.  This looks a little suspicious at
first, since intf_type uses a bunch of ethernet type constant #defines
from include/dnet/intf.h, while Microsoft uses their own set of
defines from dwType ( in Vc7/PlatformSDK/Include/Ipifcons.h ).  But at
least on my system, both sets of #defines have equivalent values,
which are taken from http://www.iana.org/assignments/ianaiftype-mib .
So it appears that Windows may be the one wrongly classifying the
device as ethernet.

This is a problem (non-ethernet devices appearing to Nmap as ethernet)
that I have seen before on Windows, and one I'd definitely like to get
fixed.  Does anyone have any ideas how to do this?  If you have
non-ethernet devices on your system (besides loopback), does Nmap
properly report the device type with --iflist, or are they wrongly
classified as ethernet?  Do Nmap scans using the device work?

> nmap -e lo0 -sP 10.33.56.0/24 
>
> work as usally, what i also didnt understand. Its seem not to be a nmap
> problem, its more strange behaviour under XP SP2.

That is strange.

Cheers,
-F


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