Re: distributed nmap?

[Simple Nomad <thegnome () nmrc org>]

On Wed, 22 Mar 2000, Johan Denoyer wrote:

> There is a problem using this method ... I am not sure what use of
> this scanning you are going to do, but IF this is for unprofessional
> use, the host receiving the information (the listening host) will
> accept the information. Thus it will not send the "DESTINATION
> UNREACHABLE: PORT UNREACHABLE" message back! If someone installs a
> sniffer on the network to detect such packets... The person
> responsible for the host receiving the information WILL be
> investigated if your scanning is unprofessional! So this method can
> be used ONLY if the packets received by the listening host are UDP
> packets... Meaning only host scans. No TCP port scanning...
>
> Now if this is for professional use, then by all means this method
> will work.

I am not going to debate the "professional" or "unprofessional" efforts
involved. There are plenty of people capable of wearing a white or black
hat on this list.

As it has been quite obvious to me for over a year, there is nothing to
stop the following -- this works now and requires no modification to nmap. 
Consider this mono-spaced ascii drawing:

 *----------------*
 | target network |  10.10.10.x
 *----------------*
          |
   *--------------*
   | target's ISP |  10.10.222.x
   *--------------*
          |
          |   *---------------*
          |---| nmap on ISP's |  10.10.222.27
          |   |    network    |
          |   *---------------* 
          |
  *---------------*
  | innocent host |  192.168.1.1
  *---------------*

The machine running nmap is on the target's ISP's network. For argument's
sake we'll assume nefarious intent and that the nmap machine has been root
compromised. The black hat runs nmap with the following options:

nmap -v -n -S 192.168.1.1 -e eth0 -sS -p 1-1024 10.10.10.1-50

Running this will make it look like the innocent host ran the scan. Note
that they do NOT have to use the -P0 option, unless so inclined since nmap
is upstream it sees the pings. Running *with* the -P0 option also turns up
some interesting information though. If you were to get a message returned
that EVERY target IP address had port 7, 9, and 19 filtered, you could
assume that either the ISP *or* the target network is filtering those
ports.

If the person running nmap wanted to be a real crafty individual, they
could also do the following:

nmap -v -n -S 10.10.10.1 -e eth0 -sS -p 1-1024 192.168.1.1

It would look to the admins at each respective site they had scanned each
other. Imagine if the two locations were in fact business partners or one
a subsidiary of the other. You could throw in some other innocent hosts
and possibly determine addresses-based trust rules between certain
companies. Go nuts and add decoys. Talk about your confusing diversion
while network mapping...

I guess I assumed this was common knowledge, and one of the reasons why
nmap is so popular -- nmap is very diverse and immensely configurable. I
first discussed this at SANS NS99 last October at a presentation I did
there, and is part of a paper I have partially written (I need to finish
it, started it over a year ago). 

This is why I don't trust source addresses if I'm being scanned. I find it
naive to assume this is *not* being done.

-         Simple Nomad          -  No rest for the Wicca'd  -
-      thegnome () nmrc org        -        www.nmrc.org       -
-  thegnome () razor bindview com  -     razor.bindview.com    -

> > The easiest way to make nmap distributed is to modify it to just
> > listen. Run nmap in listen mode on 192.168.1.1, and have several
> > instances of nmap on other systems scanning with a forged source
> > address of 192.168.1.1. All the replies would go to 192.168.1.1.  
> >
> > For example, you have nmap on 192.168.1.1 listening with the
> > theoretical -L option, started as such: nmap -L -sS -v -v -n
> > 10.10.10.1-3. On another box you start a scan: nmap -sS -n -S
> > 192.168.1.1 10.10.10.1, and repeat on additional boxes for .2 and
> > .3.  
> >
> > The listener, perhaps using an additional timeout parameter,
> > eventually receives all the packets its going to receive and
> > reports what it heard.  
> >
> > What makes this even more interesting is if your listener is
> > upstream from the spoofed source address. Then you could spoof the
> > source address on the listener and listen to replies as they go
> > flying by toward the unsuspecting spoofed host.  
> >
> > Since nmap uses libpcap you can already spoof a source address on
> > your same network and still get the reply, so this isn't as far
> > fetched as it sounds. I did a similar thing with icmpenum available
> > at http://razor.bindview.com/ in the tools section, which does
> > distributed host enumeration via icmp packets. Hopefully I'll get
> > some time and take a real serious look at nmap soon because I think
> > this would be a fairly interesting feature.