Re: Nmap bug - Doesn't folow static route

[David Fifield <david () bamsoftware com>]

On Fri, Feb 26, 2010 at 12:09:09PM -0700, David Fifield wrote:
> On Fri, Dec 18, 2009 at 12:59:06PM +0200, Ninel Piroi wrote:
> > I use Nmap frequently at home and at work, before being useful in many  
> > situations and I want to thank you for this sweet product.
> > Recently I discovered that when using static routes to subnet, Nmap does  
> > not follow the route, but looking directly into local broadcast (ARP)
> >
> > Ex:
> > [Nmap Host] <-10.1.0.0/20-> [GW1] <-192.168.1.0/24-> [GW2]  
> > <-10.1.3.0/24-> [Target Host]
> >
> > [Nmap Host]
> > IP  :    10.1.0.15/20
> > GW1: 10.1.0.1
> > Static Route:  10.1.3.0/24 gw 10.1.0.1
> >
> > [Target Host]
> > IP:      10.1.3.9/24
> > GW2: 10.1.3.1
> >
> > > nmap --packet-trace -sS 10.1.3.9
> > Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-18 08:41 GTB Standard Time
> > SENT (0.6720s) ARP who-has 10.1.3.9 tell 10.1.0.15
> > SENT (0.7820s) ARP who-has 10.1.3.9 tell 10.1.0.15
> > Note: Host seems down. If it is really up, but blocking our ping probes,  
> > try -PN
> > Nmap done: 1 IP address (0 hosts up) scanned in 0.91 seconds
> >
> > > nmap --iflist
> > Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-18 08:41 GTB Standard Time
> > ************************INTERFACES************************
> > DEV  (SHORT) IP/MASK       TYPE     UP MAC
> > eth0 (eth0)  10.1.0.15/20 ethernet up 00:1A:DC:3E:34:AC
> > lo0  (lo0)   127.0.0.1/8   loopback up
> > DEV    WINDEVICE
> > eth0   \Device\NPF_{00744106-FFB1-473B-AED9-3CD94673D5AA}
> > lo0 <none>
> > <none> \Device\NPF_GenericDialupAdapter
> > **************************ROUTES**************************
> > DST/MASK           DEV  GATEWAY
> > 10.1.0.15/32      lo0  127.0.0.1
> > 10.255.255.255/32  eth0 10.1.0.15
> > 255.255.255.255/32 eth0 10.1.0.15
> > 10.1.3.0/0         eth0 10.1.0.1
> > 10.1.0.0/0         eth0 10.1.0.15
> > 127.0.0.0/0        lo0  127.0.0.1
> > 224.0.0.0/0        eth0 10.1.0.15
> > 0.0.0.0/0          eth0 10.1.0.1
>
> You're right. If a target address matches an interface's address and
> netmask, Nmap doesn't even look at the routing table.
>
> Your case has additional complications, like this:
>
> 10.1.3.0/0         eth0 10.1.0.1
> 10.1.0.0/0         eth0 10.1.0.15
>
> Nmap sorts the routes by netmask before matching, so more specific
> matches will be tried first. But it uses qsort, which is probably not a
> stable sort, so entries with identical netmasks may have their order
> changed. I think both of these problems would have to be fixed for Nmap
> to work in your environment.

Those /0 netmasks were a separate bug, fixed in r16968.

> If someone wants to work on this, the relevant functions are
> getsysroutes and route_dst in tcpip.cc.

I've implemented this as of r16970. If you are building from source,
please give it a try. Here is the commit message:

Before, route_dst worked like this:
  1) Check destination address against all interfaces, with special-case
     handling for local addresses.
  2) Check destination address against routing table.

Now it works like this:
  1) Check destination address against local addresses.
  2) Check destination address against routing table.
  3) Check destination address against all interfaces.

This allows a routing table entry to override an interface, for example
in this configuration:

  ************************INTERFACES************************
  DEV  (SHORT) IP/MASK         TYPE     UP MAC
  eth0 (eth0)  192.168.0.21/24 ethernet up 00:00:00:00:00:00

  **************************ROUTES**************************
  DST/MASK       DEV  GATEWAY
  192.168.0.3/32 eth0 192.168.0.1
  192.168.0.0/24 eth0

192.168.0.3 will not be considered directly connected, but will have its
traffic routed through 192.168.0.1.

The logic for determining when an address is directly connected has
changed. Instead of considering an address directly connected whenever
it matches an interface netmask, we consider it so when the gateway
address is 0.0.0.0 or when the gateway address is exactly equal to the
interface address. The proper way to do this would be to look at the "G"
flag from the routing table, but libdnet doesn't retain that.

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