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 http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- RFC on Ncrack, A new network authentication cracker Fyodor (Apr 28)
- Re: RFC on Ncrack, A new network authentication cracker Luis M. (Apr 28)
- Re: RFC on Ncrack, A new network authentication cracker ithilgore (Apr 28)
- Re: RFC on Ncrack, A new network authentication cracker Lionel Cons (Apr 28)
- Re: RFC on Ncrack, A new network authentication cracker Michael Pattrick (Apr 28)
- Re: RFC on Ncrack, A new network authentication cracker Arturo 'Buanzo' Busleiman (Apr 28)
- Re: RFC on Ncrack, A new network authentication cracker Justin Knox (Apr 29)
- Re: RFC on Ncrack, A new network authentication cracker Professor 0110 (May 01)
- RRe: RFC on Ncrack, A new network authentication cracker Brandon Enright (May 01)
- Re: RFC on Ncrack, A new network authentication cracker Justin Knox (Apr 29)
- Re: RFC on Ncrack, A new network authentication cracker Kris Katterjohn (Apr 28)
- Re: RFC on Ncrack, A new network authentication cracker Corey Chandler (Apr 28)
- RE: RFC on Ncrack, A new network authentication cracker Aaron Leininger (Apr 28)
- Re: RFC on Ncrack, A new network authentication cracker jah (Apr 28)