Nmap Development mailing list archives

Re: backorifice-brute NSE script


From: Gorjan Petrovski <mogi57 () gmail com>
Date: Wed, 4 May 2011 15:11:23 +0200

Hi,
Thanks for the fast replies.

Would a backorifice-version script make sense (a script
backorifice-brute would depend on)? Do you have to have the correct
pwd/seed to determine if it is the BackOrifice service?

Yes, you have to have the correct pwd/seed to get any response from
the service. A backorifice-version script is not possible without
cracking the pwd/seed.

Should a brute script update version info?

Probably not. I think backorifice-version would be more appropriate if possible.

So, with above answer in mind, should backorifice-brute update version
info if it finds the password?

Which socket timeout is best for this kind of script? (I put 3000 ms)

Is the default (30 seconds I believe) not suitable?

The only way to establish a wrong password is by timeout, so I thought
that 30s would be too much, especially since the default number of
brute threads is 10. I'll try out David's suggestion.

Why shouldn't I put 50 or 100 bruteforcing threads?

The NSE engine only allows 20 concurrent connections at a time. You
can't do better than 20 unless you increase this limit using
--max-parallelism. Isn't there a brute library option to increase the
number of threads?

Yes, the brute option works fine. Since password verification is based
on a timeout, and these are filtered udp packets we're talking about,
I was wondering what would be the maximum recommended amount of
threads / reserved sockets I could use for this script, so as not to
overuse sockets on local host, and avoid clogging the service on
target host (which would probably run on an old Win98 machine). I
guess I have research to do :-)

Best Regards,
Gorjan
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: