Nmap Development mailing list archives

Re: nmap+V


From: Fyodor <fyodor () insecure org>
Date: Thu, 24 Aug 2000 01:19:46 -0700 (PDT)

On Thu, 24 Aug 2000, H D Moore wrote:

There are some issues with this, namely DoS attacks caused by the
'detection' packets.  An example are some wind0z3 SQL boxes that have
port 6666 open, but if you make a connection to that port and send ASCII
data it crashes whatever service was listening on that port.

The unfortunate fact is that many features of Nmap have occasionally been
known to crash poorly written applications, TCP/IP stacks, and even
operating systems (!).  I won't neuter Nmap for every obsucer crash of a
poorly written system, but I do try to work around it in many cases.  In
your example, perhaps port 6666 would be registered to try the SQL
detection test first.  Tests that cause common problems could be tweaked
if it helps resolve these issues.

Some protocols are always in a specific state based on what data they
have already received, what probe packets do you send to determine which
service it is, and not inadvertently set the daemon/service into a mode
where it wont respond to the same string it would if that string was the
first thing you sent?

Agreed.  Thats why I mentioned that multiple "isolated" tests would likely
be needed.  They are not just isolated in the config file grammer -- I was
planning to have them use separate TCP connections as well.  This helps
maintainability, accuracy, and can even allow for faster speeds via test
parallelization.  Of course, you don't need a separate test for every
service.  As the previous mail (re: nessus) showed, we may be able to
catch 70% (by popularity) of the ports via the first (GET /) test.

scripts/plugins/etc.  Wouldn't a modularized plugin
output/filtering/processing system make all of this a non-issue and
allow people developing things like version and banner detection do so
without needing to "taint" core nmap development?

Yes, I think a modularized plugin system could make banner & version
checking a non-issue and that is one reason I have suggested we only worry
about service detection.  I think service detection is important because
the plugions should only run against the services they were designed
for.  I don't want the plugin config to say:

80/tcp launch echo "GET /robots.txt HTTP/1.0\r\n\r\n" | nc $target 80

I would rather they write:

http launch echo "GET /robots.txt HTTP/1.0\r\n\r\n" | nc $target $port

One of the most frequent usages of Nmap is security auditing where it is
critically important that people not miss vulnerabilities just because
someone was running their server on a non-default port.

Cheers,
-F


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).



Current thread: