Re: Replacing passwords.lst

[Martin Holst Swende <martin () swende se>]

David Fifield wrote:
> On Sat, Mar 06, 2010 at 09:15:00AM -0600, Ron wrote:
>   
> > - john the ripper-like complexity rules -- though much simpler like
> > adding a '1' to the end of the passwords. We have to keep in mind that
> > bruteforcing != cracking, so we can't go crazy like john does
> >     
>
> I second that--specifically adding "1" to the end of passwords. I think
> this could be nicely implemented as another iterator that wraps the
> unpwdb.passwords iterator. Other iterators could be combined to add
> other fancy accoutrements. My gut says that think "1" is going to be the
> single most effective modification.
>
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
>   

On the topic of bruteforcing, iterators and unpwdb; I started
implementing brute forcers for a couple of services. In doing so, I did
not want to do copy-paste coding, instead I thought that one of these
two ways of implementing a bruteforcer should be used :
A : Implement a brute-force script, which works like :
nmap -p80, 27017 -script=brute-force
    bruteforces http on port 80
    bruteforces mongodb on port 27017
To do this, each service needs to define an authentication-library which
can be loaded by the brute-force script. Benefits are that it would be
easy to do bruteforcing, since all sercvices could have more or less the
exact same parameter syntax. Also, a user wouldn't have to know what a
specific service is there, just run "please bruteforce all you can find"...

B: Implement a brute-force library, which is used by brute-force scripts
where each script only implements authentication and then calls the
bruteforcer (which perhaps is a base class).

I tried A first, but had some issues doing dynamic require (the loaded
authenticatio-libraries had nothing in scope, and could not even use e.g
print). I then switched to approach B, and made a PoC. Which brings me
to the iterators. One feature of a generic bruteforcer would be that it
should ask a driver (or authenticator) if there are any specific
accounts or passwords which should be tried. Default accounts, names
used in how-to-setup-examples or service name (db2admin for db2 etc).

Therefore, one closure I implemented is a generic iterator takes any
number of arguments and iterates over most kinds of objects : strings,
tables, lists and other iterators. To avoid duplicates, I also added the
closure "uniq", which works like the bash namesake.
 
Usage :
status,usernames = unpwdb.usernames()
status,passwords = unpwdb.passwords()
<http://martin.swende.se/hgwebdir.cgi/nsescripts/file/tip/nselib/db-brute.lua#l190>

for username in uniq(iterate(serviceSpecificNames,usernames)) do
for password in
uniq(iterate(username,serviceSpecificPasswords,passwords)) do


So, to summarize :
* What do you think about having a generic bruteforcing framework so a
developer only has to add authentication for a specific service?
* There are two nifty iterators that perhaps could be useful in unpwdb.

Source code for this can be browsed at
Brute force library :
http://martin.swende.se/hgwebdir.cgi/nsescripts/file/tip/nselib/db-brute.lua
Authentication driver for couch db :
http://martin.swende.se/hgwebdir.cgi/nsescripts/file/tip/scripts/couchdb-auth.nse

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