Re: RFC on Ncrack, A new network authentication cracker

[ithilgore <ithilgore.ryu.l () gmail com>]

Fyodor wrote:

> Now let's talk about the functional requirements for Ncrack.  Here are
> my thoughts:
>
> o Like the rest of the Nmap suite, it needs to be portable.  Binaries
>   must be provided for Linux, Windows, and Mac and the source should
>   properly compile on the other major operating systems.

I think there are people on this list that have Mac boxes that could help
in compilation/testing, since I currently (and never before have) don't own
a Mac whatsoever.

> o It needs to be written in C++ and use the Nsock and Nbase libraries.

I have already began studying Nsock (which is really well written), though
I'll have to admit my experience with C++ doesn't compare with that in C.

> o It needs to be faster than its competitors such as THC Hydra, Cain &
>   Abel, etc.  The speed should be quite tunable so you can specify a
>   slow rate for the times when that is desirable.

Network authentication will require many packets on the wire, and if
speed is a concern, reliability is also another one. Of course, TCP (for all
TCP services at least) will take care of things itself. However, as far as UDP is
concerned a simple retransmission mechanism might be of use. Though, this can happen
possibly in the future as a further optimization-refining phase.

> o It needs to have great username and password lists.  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.

Being able to enforce restrictions on password generation is of high
importance indeed. Additionally, I noticed at the nmap TODO list that
there is a future plan of getting username/password lists from Solar Designer
(author of jtr) I think this will improve quality even further.

> 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.

A big design decision here is the way that each of the services will be
integrated into Ncrack. Obviously, a modularized approach is without question
but there are many ways one can implement that. For example, I saw that thc-hydra
uses a very simple approach of declaring all service-related core functions as
extern and calling them from separate .c files. It is a fairly straightforward
way and adding a new service "module" involves creating a separate hydra-<service>.c file
and writing a few lines at the main hydra.c file.
On the other hand, medusa ( http://www.foofus.net/~jmk/medusa/medusa.html ) uses a more
'official' way of creating separate shared library files (real modules that is) and calling
them with dlopen/dlsym etc. It is a slightly more refined way, but adds a bit to the complexity.
Snort also uses the same approach to give the user the ability of creating his own modules.

What are your thoughts on this?

> 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.

If things go well, development (as far as I am concerned) can continue even
after SoC 09.

> 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!

It is a very challenging task, but this is what this is all about after all!
I am waiting for the rest of nmap-dev's opinion, as well.

-- ithilgore



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