Re: Default time limits for unpwdb

[Ron <ron () skullsecurity net>]

On Tue, 23 Mar 2010 11:23:46 -0600 David Fifield
<david () bamsoftware com> wrote:
> 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

I haven't looked at the code, but the concept is sound. As long as it defaults to some kind of limit, we can probably 
make the list arbitrarily long. As we sort of mentioned, some protocols are fast (SMB is bruteforced fast++), and some 
are slow (vsftpd forces a 2 second delay between attempts). For that reason, I think time is more important. 


-- 
Ron Bowes
http://www.skullsecurity.org
http://www.twitter.com/iagox86
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/