mailing list archives
Re: RFC on Ncrack, A new network authentication cracker
From: ithilgore <ithilgore.ryu.l () gmail com>
Date: Tue, 28 Apr 2009 13:36:43 +0300
Now let's talk about the functional requirements for Ncrack. Here are
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
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.
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org