Re: RFC on Ncrack, A new network authentication cracker

["Luis M." <luis.mgarc () gmail com>]

Hi!

Here are some thoughts:
> o It needs to have great username and password lists. 


It would be great to include on that list user/passwords from the
"Default password list" mantained by phenoelit
(<http://www.phenoelit-us.org/dpl/dpl.html>). I'm sure many of us have
checked that list more than once. (Combining this with OS and version
detection would be awesome but I guess that's a pretty ugly task)

This is very obvious, but the tool should support user supplied
dictionary files.

The tool should be able to keep its state, pretty much like john does.
This is, you can interrupt the cracking process with CRTL-C and later
restart it from that point (john uses argument "--restore" for this).

I don't know if this is practically possible but it would be great to be
able to crack ssh, etc, using the keys  that were generated using that
broken version of OpenSSL distributed by Debian. You all probably
remember this vuln.


That's all I can come up with for now. Regards,


Luis.


> It should be
>   able to generate permutations of them (e.g. add digits to the end,
>   revers, etc.)  You should be able to specify restrictions on the
>   usernames/passwords used.  For example, if you know that their
>   enforced policy only allows passwords of at least 6 characters with
>   a mix of lowercase/uppercase letters and at least 1 number and 1
>   letter, you should be able to specify that so that non-conforming
>   passwords aren't tried.  Take a look at how John The Ripper handles
>   this sort of thing, as it is very flexible, powerful, and fast.
>
> o It needs to be able to crack in parallel where that helps.  For
>   example, a telnetd might make you wait 3 seconds before it tells you
>   that a password is wrong.  But that's not such a big difference if
>   you've got dozens of other threads cracking against the same service
>   at the same time.
>
> o Ncrack needs to support the major authenticated protocols, such as
>   ssh, msrpc, http, imap, pop3, SNMP, telnet, ftp, etc.  It should do
>   that in a flexible enough way that it can include optimizations for
>   each.  For example, some services will let you try 3 attempts per
>   connection before you have to disconnect and try again.
>
> o For HTTP it needs to support both basic auth and GET/POST password
>   forms on web pages.  It should be able to use features such as
>   keepalive and pipelining to the extent doing so helps.
>
> o It needs to be well documented in a man page (written in Docbook XML
>   so it can be converted to Nroff and HTML).
>
> o Must support IPv6, IPv4, and SSL-tunneled services.
>
> o It should take inspiration from tools such as Hydra, Cain, and John
>   as they certainly do some things right.  We should take the best
>   from each, and add our own great ideas and strong implementation.
>
> These are my ultimate goals, but they may not all be met by the end of
> SoC '09.  It might be more like Zenmap and Ncat which worked pretty
> well at the end of their first summer, but took 2+ years before they
> really hit prime time.
>
> What do you folks think?  Would you find such a tool useful?  What
> sort of features and functions would you want?  Any key requirements
> I've missed?
>
> Also, Ithilgore decides whether he's going to do this or something
> else.  So if you want Ncrack to happen, now is your chance to say so!
>
> Cheers,
> -F
>
>
> It would be great to include password from the "Default password list"
> mantained by phenoelit
> (<http://www.phenoelit-us.org/dpl/dpl.html>)
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org
>
>   


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