Re: Some scripts for analyzing NetBus

[Toni Ruottu <toni.ruottu () iki fi>]

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
sessions.

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:
> > |_netbus-brute:
> > There should be some message to make clear that it's an empty or blank
> > password.
>
> 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
> >                return
> >        end
> >        socket:send("Password;1; \r") --password: space
> >        if buffer() == "Access;1" then
> >                return "Vulnerable"
> >        end
> > 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
> > desktop.
>
> > 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.
>
>  --Toni
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/