Nmap Development mailing list archives
Re: brute.lua, unpwdb.lua, custom iterators and flexibility
From: David Fifield <david () bamsoftware com>
Date: Wed, 27 Jun 2012 09:09:03 -0700
On Wed, Jun 27, 2012 at 05:11:16PM +0200, Aleksandar Nikolic wrote:
Hi all, I have a small report here about some ideas regarding brute scripts. After some discussion, we came to the conclusion that it would be nice to be able to add a specific username to try when bruteforcing. For example, I want to add a username "ftp" to ftp-brute along with the rest of the usernames and passwords form unpwdb. Now, there are three logical options: 1) Add custom usernames and password pairs 2) Adding just username to test against all passwords form unpwdb 3) Prepend or append username(s) to the list of usernames from unpwdb
I think that (3) is definitely what we want. My ideal API would look something like this (using semi-pseudocode): users = concat_iterators(table_iterator({"ftp"}), brute.usernames_iterator()) engine.setUsernameIterator(users) Here concat_iterators is a made-up function that does what you expect, it returns a new iterator that runs over each of its constituent iterators in turn, like itertools.chain from Python. brute.usernames_iterator is a function returning the brute library's default user name iterator, the one that gets used by default if you don't call setUsernameIterator. Naturally, there would be an independent setPasswordIterator. The usefulness of the current brute addIterator is limited, because as you've seen, it is asking for an iterator that returns (user, pass) pairs. That means if you want to add just an additional user name, you have to duplicate the password loop and all the other machinery from the brute library in your custom iterator. Here's another example of how caller-provided iterators allow greater flexibility. Let's say you're testing a service that you know doesn't allow passwords longer than six characters. You could do something like this: pass = filter_iterator(brute.passwords_iterator(), function (x) return #x <= 6 end) engine.setPasswordIterator(pass) This is why I don't think the programmer interface should not be limited to only appending or prepending to the default lists, even if that's the most common use case. We can even provide convenience options to do prepending, but I believe it should be implemented using iterator concatenation as above. There can still be a setIterator method that yields (user, pass) pairs, for callers who need ultimate control. I think that concat_iterators makes addIterator unnecessary. One small implementation problem is that concat_iterators and filter_iterator need to understand the "reset" convention at each level. They should probably live in unpwdb and be called from there. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- brute.lua, unpwdb.lua, custom iterators and flexibility Aleksandar Nikolic (Jun 27)
- Re: brute.lua, unpwdb.lua, custom iterators and flexibility David Fifield (Jun 27)
- Re: brute.lua, unpwdb.lua, custom iterators and flexibility David Fifield (Jun 27)