Nmap Development mailing list archives

Re: nmap_lua attack scripting beta release


From: Fyodor <fyodor () insecure org>
Date: Mon, 3 Jul 2006 14:51:37 -0700

On Mon, Jul 03, 2006 at 10:29:04PM +0200, Diman Todorov wrote:
I just finished and published the beta release of nmap-lua.
Nmap-lua does for nmap what NASL does for nessus.
With nmap-lua you can write custom penetration tests in lua.
They are run against an open port if the rule you have specified  
matches.
Output is provided in the trusty, worthy nmap tab and in the xml report
which can be converted to html.

Thanks for the new release.  I am very excited about the Nmap-Lua
project as I feel it will be a hugely valuable addition to Nmap.  I
don't know if we need to compete head-on with Nessus and its 11,000+
modules (we certainly don't right now), but I can thing of dozens of
scripts which would fit Nmap's core network discovery purpose.  Not
only could we ship with a bunch of generic discovery scripts to run
when users request -sC, but users can easily add their own scripts to
fit their custom needs.  This provides a tuned and optimized framework
for quickly interrogating hundreds/thousands of services over a large
network.

I hope other Nmap-dev members will test this out and post their
feedback.  That will certainly help us improve the system.  So please
post if you have any suggestions for improving this, or if you
encounter any bugs or compilation problems.

Here are the test instructions again:

wget http://xover.mud.at/~diman/nmap-4.20ALPHA3-LUA.tar.bz2
tar -jxvf nmap-4.20ALPHA3-LUA.tar.bz2
cd nmap-4.20ALPHA3-LUA
./configure && make
./nmap -sC somehost

I just gave this a try on two Fedora Core 5 systems.  It compiled on
both of them, though one gave the message:

liblua/liblua.a(loslib.o): In function `os_tmpname':
loslib.c:(.text+0x35): warning: the use of `tmpnam' is dangerous,
better use `mkstemp'

From the notes in liblua/luaconf.h, maybe we should define
LUA_USE_MKSTEMP and see if we run into problems with systems that
don't support it.  Does anyone know if mkstemp is portable enough for
us?  Does Windows offer it?

I don't know if the way LUA uses Mkstemp is a security hole or whether
it is even an issue given the way we use the system.  But even if it
isn't, I'd rather not have Nmap give "uses insecure function"
warnings.  It doesn't give users a warm feeling :).

Speaking of compilation, have you tried compiling it on Windows yet?

After compilation, I gave it a try:

./nmap -sC scanme.nmap.org
[...]
PORT    STATE SERVICE SCRIPT SCAN
[...]
22/tcp  open  ssh
|                     stealth sshd version: SSH-2.0-OpenSSH_4.3
80/tcp  open  http
|                     Site title: Authentication required!

In this case, the results could fit on the table line itself, but we
probably don't need to worry about optimizing for that case.  The two
advantages I see for using separate lines are that it allows you to
show results from multiple scripts more easily, and helps avoid
running off the edge of the screen (and line wrapping).

But in this case, you don't get the line-wrapping-reduction advantage
because you start the new line in the same late column.  I would
suggest removing the "SCRIPT SCAN" column from the table and simply
indenting the script results by a few spaces.  For example:

PORT    STATE SERVICE
22/tcp  open  ssh
|  Stealth sshd version: SSH-2.0-OpenSSH_4.3
80/tcp  open  http
|  Site title: Authentication required!

The whitespace problem becomes more acute when I next added version detection to the mix:

./nmap -sVC scanme.nmap.org
[...]
22/tcp  open  ssh      OpenSSH 4.3 (protocol 2.0)
|                                                    stealth sshd version: SSH-2.0-OpenSSH_4.3
80/tcp  open  http     Apache httpd 2.2.2 ((Fedora))
|                                                    Site doesn't have a title.

Note that when I add version detection, the system for some reason
fails to get the site title.  This happens every time I try it from
that machine (I am running it from the same machine which hosts
scanme.nmap.org).  If I run it against scanme from a machine across
the Internet, it seems to work even with -sVC.  If you can't reproduce the
problem, let me know and I can send you some sort of trace (whatever
would be useful).

When I run the command "nmap -sVC -v scanme.nmap.org", Nmap reports
the status of the connect scan, service scan, and rpcgrind scan, but
says not a word about script scan.  Similarly, it doesn't seem to have
runtime interaction status support (
http://www.insecure.org/nmap/man/man-runtime-interaction.html ).
Would you add these so we have a better idea what is going on under
the covers?  Even '-d' doesn't give me anything extra.

We don't want to go overboard in scrolling the screen with output.
But -v should at least tell us when the scripting engine starts it
scanning and finishes (with some useful stats in the finishing line,
perhaps).  -d should give more information, and at higher o.debugging
levels you can give more and more.

For more usage information refer to nmap-4.20ALPHA3-LUA/README_LUA

There does not seem to be any such file in
nmap-4.20ALPHA3-LUA.tar.bz2.  Would you send it to the list?

Some demo scripts are provided in nmap-4.20ALPHA3-LUA/nmap_scripts

Looks good.  I like the way that showHTMLTitle.lua uses version
detection results (if available) to find web servers to run against.  I
tried running a web server on an unusual port, but service detection
found that it was http and showHTMLTitle.lua properly detected this
and found the title.  Meanwhile, it didn't waste time running against
non-http services like ssh.

From our AIM discussion, it sounds like you haven't tested UDP or SSL
much/any yet.  But I agree that is a good direction to take.  UDP is
particularly important.

Keep up the good work.  And I hope other people will start reviewing
your releases as well.  That will help us develop what the broad
userbase wants, rather than just what you and I think is cool :).

Cheers,
-F



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


Current thread: