Re: [NSE] new scripts and libraries: brute library

[Patrik Karlsson <patrik () cqure net>]

On 18 aug 2010, at 18.05, David Fifield wrote:

> On Sat, Aug 14, 2010 at 04:57:16PM +0200, Patrik Karlsson wrote:
> > On 12 aug 2010, at 04.16, David Fifield wrote:
> >
> > > What do you do when there's a socket error in the login method? Is there
> > > a way to report it, or perhaps ask the brute library to retry the
> > > credentials?
> >
> > The login function may respond with either:
> > true, brute.Account object - if it finds a valid credential
> > false, brute.Error object - if it fails
>
> Please add this to the documentation.
Done.
> > So if a socket error occurs we need to report an error back to the engine.
> > If the retry attribute is set using the setRetry on the error object
> > the engine will retry the credential.
> > When max_retries (default 3, can be modified with argument) is
> > reached, the engine aborts.
>
> How does the login method distinguish the two failure modes: (1) access
> denied, and (2) socket error. I want (2) to be retried, but not (1).

This is really up to the driver, it needs to be able to determine (at a protocol level) whether the login was denied or 
if there was a socket error.
The login method in the Driver the needs to adjust the Error object appropriately before returning it to the Engine.

> > > Please also include documentation for the account states "OPEN",
> > > "LOCKED", and "DISABLED".
> >
> > I've documented this in the brute library as:
> > An account have the following states
> > - OPEN - Login was successful
> > - LOCKED - The account was locked
> > - DISABLED - The account was disabled
>
> Okay, I was actually thinking that this should be documented in the top
> NSEDoc comment, and in the documentation for Account.new. Ideally,
> programmers will be able to write code for the library without looking
> at comments inside functions.

I added some documentation to the new method of the Account object and on top of the file.
> > > I notice that there is a brute.emptypass script argument. I think that
> > > this is better controlled with a password list. Our default list already
> > > includes the empty password.
> >
> > Your probably right, I included it as a "rule" mostly so it can be
> > disabled by scripts for services that are known not to support empty
> > passwords.
>
> I'm going to remove it. This is another thing that could be handled with
> a special-purpose iterator, in pseudocode:
>
> for password in sub_iterator: # passwords.lst
>       if password != "":
>               yield password

Do it.

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


It's commited as r19895.

//Patrik

--
Patrik Karlsson
http://www.cqure.net
http://www.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/