Nmap Development mailing list archives

Re: Default time limits for unpwdb


From: David Fifield <david () bamsoftware com>
Date: Tue, 23 Mar 2010 11:23:46 -0600

On Sat, Mar 20, 2010 at 08:49:25AM -0500, Ron wrote:
On Fri, 19 Mar 2010 21:51:42 -0600 David Fifield <david () bamsoftware com> wrote:
The unpwdb library has a unpwdb.timelimit function that suggests how
long password brute-forcing should go on.

http://nmap.org/nsedoc/lib/unpwdb.html#timelimit

A problem is that it is up to the script to enforce the limit. Most
brute scripts don't do it. They keep running until they're exhausted
every credential. They can take an unexpectedly long time if tarpitted
or if the service is just slow.

I propose with the attached patch to add default time limits to the
username and password iterators, so that they start returning nil
after they run out of time. The default time limit would be the
return value of unpwdb.timelimit, or you can specify a limit
directly. A limit of 0 means to disable the time limit.

This would allow us to use a bigger password list without worrying
about how it's going to slow down the brute scripts. Scripts wouldn't
need any modification.

I think we should do a countlimit, too, as a script-arg. 

Here's another patch that adds these script arguments:

-- @args unpwdb.userlimit The maximum number of usernames
--                        <code>usernames</code> will return
--                        (default unlimited).
-- @args unpwdb.passlimit The maximum number of passwords
--                        <code>passwords</code> will return
--                        (default unlimited).
-- @args unpwdb.timelimit The maximum amount of time (in seconds) that any
--                        iterator will run before stopping.

You can reset the iterators so that they can reach the userlimit or
passlimit again. Those arguments act like you've truncated the username
or password list to the first N lines.

I made a test program.

description = ""
categories = {}
require("nmap")
require("stdnse")
require("unpwdb")
hostrule = function() return true end
action = function()
        local usernames
        local passwords
        local u_count, p_count, combo_count
        local start
        u_count = 0
        p_count = 0
        start = nmap.clock_ms()
        _, usernames = unpwdb.usernames()
        _, passwords = unpwdb.passwords()
        for p in passwords do
                for u in usernames do
                        print(string.format("%s/%s", u, p))
                        stdnse.sleep(1)
                        u_count = u_count + 1
                end
                usernames("reset")
                p_count = p_count + 1
        end
        return string.format("%d usernames  %d passwords  %.2f seconds",
                u_count, p_count, (nmap.clock_ms() - start) / 1000.0)
end

Here are its results with various script argument combinations.

./nmap --datadir . --script=test -n -sn localhost -d
|_test: 600 usernames  60 passwords  600.44 seconds

./nmap --datadir . --script=test -n -sn localhost -d -T5
|_test: 180 usernames  18 passwords  180.10 seconds

./nmap --datadir . --script=test -n -sn localhost -d --script-args unpwdb.timelimit=5
|_test: 5 usernames  1 passwords  4.96 seconds

./nmap --datadir . --script=test -n -sn localhost -d --script-args unpwdb.passlimit=5
|_test: 50 usernames  5 passwords  49.99 seconds

./nmap --datadir . --script=test -n -sn localhost -d --script-args unpwdb.userlimit=3,unpwdb.passlimit=5
|_test: 15 usernames  5 passwords  14.96 seconds

./nmap --datadir . --script=test -n -sn localhost -d --script-args 
unpwdb.userlimit=3,unpwdb.passlimit=5,unpwdb.timelimit=3
|_test: 3 usernames  1 passwords  2.95 seconds

./nmap --datadir . --script=test -n -sn localhost -d --script-args 
unpwdb.userlimit=3,unpwdb.passlimit=5,unpwdb.timelimit=0
|_test: 15 usernames  5 passwords  14.96 seconds

Does it look good? If so I can commit it today. The next step is to
increase the size of passwords.lst, so scripts that want to go into more
depth can do so.

David Fifield

Attachment: unpwdb-limit.diff
Description:

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

Current thread: