Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Some scripts for analyzing NetBus
From: Toni Ruottu <toni.ruottu () iki fi>
Date: Sat, 15 Jan 2011 14:17:57 +0200

netbus-auth-bypass was set into category "intrusive" because it breaks
other sessions. I was asked to research this, so I did. It turns out
that all sessions are invalidated on each new connection to the server
unless the correct password is provided through the new connection. I
used NetBus 1.7 to test this. By this definition regular version scan
is equally intrusive. In my tests -sT and -sS did not seem to break

So how should we categorize the scripts then? I think netbus-version
should not be in intrusive, because any other version probes already
break sessions, so it does not add to the intrusiveness. netbus-brute
should clearly be in intrusive as it might send lots of data to the
server and fill some log file with login requests.

How about netbus-auth-bypass and netbus-info? Should we put them all
into the intrusive category for the benefit of those who try to do
stealthy scans with default scripts enabled, but version scanning
disabled? Or should we rather have them in the default category
because they may help admins notice a backdoor instance, set a
password for the service, or upgrade it to a secure version.

Taking all this into account I would move netbus-auth-bypass into the
default category. Detecting vulnerabilities seems more important than
accidentally breaking a session. Specially since NetBus is probably
not expected to be really robust, and it might not be too common to
have long sessions open.

On Mon, Dec 13, 2010 at 11:53 PM, Toni Ruottu <toni.ruottu () iki fi> wrote:
The scripts store a password in nmap.registry.netbuspassword. This won't
work if more than host with different passwords is scanned at the same
time. You should make this indexed by IP address and port number.

I'll look into this.

If there's no password set on the server, the output of netbus-brute is:
There should be some message to make clear that it's an empty or blank

It is indeed a blank password. I think trying to log in with "foo"
(when the blank password is set) would cause an error, but I'd need to
check to be sure. Is some other brute script reporting a blank? I
could copy the message format to remain consistent.

Similarly netbus-auth-bypass fails to report if it was able to connect
with a blank password:
       socket:send("Password;1;\r") --password: empty
       if buffer() ~= "Access;1" then
       socket:send("Password;1; \r") --password: space
       if buffer() == "Access;1" then
               return "Vulnerable"
There should be an "else" on that second "if" that says, "Not
vulnerable, but password is blank."

Oh, I thought it would be task of netbus-brute to figure that out.
Maybe it makes sense to detect that here too. :-)

Wow, I tried running NetBus170 on a Fedora VM under WINE, and your
right. The "Screendump" button even gets a copy of the whole GNOME

One of the scripts messed up the server (which you warned about) so that
every button brings up a dialog reading "Sorry, host is password
protected." I think this was netbus-auth-bypass. I moved the script into
the "intrusive" category because of this. Can you explain what
circumstances cause the server to be locked out so it can be documented?

I think any failed authentication attempt will fail sessions for
everyone, but I have to check how this behaves with blank passwords.


Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]