Re: [NSE] http gitweb projects enum

[Patrik Karlsson <patrik () cqure net>]

On Fri, Apr 20, 2012 at 5:39 AM, riemann <riemann () opendz org> wrote:

> Hi list,
> This a script to enumerate public projects diplayed with gitweb.
> Also in most case the author column in project list can be used
> in bruteforce operation as a username, are there any solution
> to add a list of user collected by this script to unpawdb and use
> it in an other script?
>
> This is what proposed from djalal harouni after some private talk about
> the probleme
>
> What do you think of this proposition:
> Can we add support for in memory usernames/passwords addition ?
> add them to the 'usertable' or 'passtable' tables of unpwdb.lua library
> and give them precedence over the usernames/passwords that are
> retrieved from a file ? should we link them to their host ? or just use
> 'nmap.registry[self.host.ip].**unpawdb_entries' ? We can consider the
> creds.lua library but that one seems more for reporting only (output),
> but I'm not sure, perhaps we should just add the state LIKELY_VALID
> and push them there for output and avoid updating unpwdb.lua entries
> for input ? Well public cvs,svn,git logs are for diffs not for crack-me...
>  Note: the creds.lua library has the logic to attach entries to their host.
> If we push them into unpwdb.lua tables then all the brute scripts
> will use them automatically... a positive point, but abuses will eat
> memory...
> Thoughts ?
>
> Thx.
>
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

Hi Riemann,

I tested the script and fixed some minor stuff and committed it.
In regards to user enumeration, we've discussed this in the past, can't
seem to find it at the moment though.
One way of doing it I guess is to separate user enum scripts from brute
scripts and have them register potential users through the cred library,
using some specific state flag (similar to state.PARAM). This specific
state could then be leveraged by the brute library/framework to perform
password guessing. I guess discovered accounts wouldn't necessarily have to
be service/host specific either?

If someone has any ideas on a suitable design for this and would like to
give it a go, let me know.

Thanks for contributing with the script.
//Patrik

-- 
Patrik Karlsson
http://www.cqure.net
http://twitter.com/nevdull77
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/