Home page logo

nmap-dev logo Nmap Development 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

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
Archived at http://SecLists.Org

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]