Re: ftp-brute.nse overhaul

[Ron <ron () skullsecurity net>]

On 09/18/2009 09:36 PM, Fyodor wrote:
> Thanks Ron!
No problem. It's what I do. :)

> Authentication cracking in general can take a long time to finish.  I
> doubt I'm the only one here who has had crackers running for months on
> end.  I don't think 2,000 combinations is an unreasonable number by
> default.  Limiting it to trying just 10 users x 10 passwords makes the
> script go fast, but only because it isn't doing much.  I also worry
> that it could give a false sense of security to people who assume that
> it is doing a more thorough check.  I am glad you added the limits,
> but I think 10x10 is too small.  Now if we can speed up the cracking
> process itself (rather than just reducing the number of credentials
> tried), that would be delightful.  We will probably start sharing the
> Ncrack user/pass DB (or at least a subset of it) with Nmap soon.
The biggest issue is that 2000 combinations isn't unreasonable normally, 
but in my tests (against vsftp) it would take over a half hour. I left 
it running when I left work today, so I'll see on Monday how long it 
actually takes.

That being said, I agree -- I just committed a patch to remove the 
limits (though the user can still limit it using a script-arg).

Speeding up the cracking will likely be achieved best through 
parallelization, but I'm not in a big hurry to get tangled up in threads. :)

I agree with sharing the Ncrack DB -- the Nmap one is sort of lacking. 
We need to incorporate Brandon's great research! I haven't looked into 
what Ncrack is using, but how large is the dictionary? I think it'd be 
best if we could use the "most common N passwords", the same way Nmap 
checks the "most common N ports" (where N=1000) by default, giving the 
option to the user to enable more.

> I think building this into unpwdb would be ideal.  That allows for
> arguments to be shared between our "auth" scripts, and avoids
> duplicating the time/credential limitation code.  If possible, it
> would be nice if users could also specify per-script arguments in case
> they want to set different limits for different scripts.
All right. Updating unpw has been on my list for months. The issue is, 
the best ways I can think of to update it are going to break 
compatibility (which might be find -- I don't mind fixing up the auth 
scripts, especially since I'll likely be parallelizing them at the same 
time).

> We talked about this idea during SoC and Patrick had some
> implementation ideas.  The main goal was indeed to make the "auth"
> scripts faster.  Patrick, can you tell us more about where we stand in
> this respect?  I tend to recall that we weren't too far from being
> able to do this.
Will definitely incorporate this in the future.

Ron

--
Ron Bowes
http://www.skullsecurity.org/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org