Re: RFC on Ncrack, A new network authentication cracker

[Ron <ron () skullsecurity net>]

Fyodor wrote:
> Hi All!  You've surely noticed that Nmap has been branching out lately
> into a suite of tools.  We now have Ncat, Ndiff, and Zenmap to keep
> the flagship Nmap Security Scanner company.  Meanwhile, Nping
> (http://nmap.org/soc/Ncat.html) is in the wings.  But in this email,
> I'm proposing a new tool: Ncrack, and I'd love to get your feedback on
> it!
>
> Ncrack is designed to be a fast and flexible network authentication
> cracker.  You can point it at a service (ssh, msrpc, http, imap, pop3,
> SNMP, telnet, ftp, etc.) and it will make repeated authentication
> attempts.  The goal is, of course, to find working credentials by
> brute force.  It is a very handy tool to have during pen-tests, as
> many/most users still choose weak passwords.
>
> This isn't actually a new idea.  I registered ncrack.org in May 2000
> and took a week of vacation time from my day job that month to write
> it.  Of course that wasn't enough time, and all I managed to complete
> that week was the parallel sockets library, Nsock.  Fortunately, it
> has proven quite handy since then for Nmap version detection, NSE, and
> Ncat.
>
> While it is approaching a decade since my first attempt to write
> Ncrack, I think it is still as useful and desirable as ever.  Here is
> the evidence I see pointing to that demand:
>
> o In my Top 100 Security Tools list (sectools.org), Cain and Able,
>   John the Ripper, and THC Hydra all made the top 15.
>
> o Brute force scripts have been some of the most popular in NSE.  We
>   already have ftp-brute.nse, pop3-brute.nse, smb-brute.nse,
>   snmp-brute.nse, and telnet-brute.nse.
>
> o Major services (OpenSSH, Apache, even Bind) are starting to mature
>   and it seems that we're seeing fewer pre-auth exploitable
>   vulnerabilities.  In addition, execution limits,
>   compartmentalization, and other hardening techniques have increased
>   the difficulty of exploiting those vulnerabilities which are found.
>   Also, people are getting better at patching due largely to easier
>   patching services.  These are all great things, but they do make the
>   pen-tester's job more difficult.  Yet password strength is a more
>   fundamental weakness which can be harder to mitigate.
>
> Why am I resurrecting this old idea now?  Because Ithilgore applied
> for the Summer of Code and I think he has just the talents necessary
> to realize this application.  He has a long history of C software
> development, has contributed patches to Nmap in the past, and has
> written open source security tools.
>
> Note that I plan to distribute Ncrack separately from Nmap rather than
> integrating it as with Zenmap, Ndiff, Ncat, and the upcoming Nping.
> It is more of a focused pen-testing tool than a more general network
> discovery/exploration/debugging/auditing tool like the others.
>
> You might be wondering what this means for the NSE brute force
> scripts: nothing, for now!  I'm not sure which will implementation
> will prove more useful in the long run (NSE auth cracking scripts or
> Ncrack).  Ncrack will have an architecture explicitly designed for
> auth cracking and be written in C++, so it will initially have a major
> speed advantage over the current NSE brute force scripts.  Also, it
> can focus its command-line interface and output on just the needs of
> auth cracking, which can make it a bit more elegant.  But the NSE
> brute force scripts have major advantages too.  For example, millions
> of people already have Nmap installed and so they may find NSE scripts
> more convenient than installing a new program.  Also, NSE can piggy
> back the brute force cracking on results already obtained from the
> host discovery and port scanning phases as well as other NSE scripts.
> And of course NSE has a big head start in that it already has multiple
> working scripts, while Ncrack is just an idea at this stage.  And
> while the performance (for brute force authentication purposes) may be
> slow now due to a lack of parallelism in that respect and other
> limitations, we've got people such as Patrick, David, and João working
> on NSE this Summer and they may be able to improve that.
>
> So in other words, I see this as competition at its finest.  We will
> do the best we can at NSE brute force scripts and Ncrack, and then let
> users decide what works best for them.  It may be that Ncrack proves
> best for the really tough/dedicated cracking jobs, while the NSE
> scripts are most valuable for broad network sweeps including lighter
> password cracking attempts against a wide variety of services found on
> the network.
>
> 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.
>
> o It needs to be written in C++ and use the Nsock and Nbase libraries.
>
> 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.
>
> 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.
>
> 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

Just a note to anybody doing this -- I put a lot of work into
smb-brute.nse, and a lot of it can probably be leveraged, at least for
ideas. Many of the things I did were specific to Windows, but not
everything. I suggest taking a look at the blog I wrote on
www.skullsecurity.org (I don't have the link handy, and my browser is
misbehaving, but just search for 'Bruteforcing SMB' or similar.

One example is bruteforcing all usernames simultaneously. Another is
detecting and preventing locked out accounts.

Hope it's helpful!

-- 
Ron Bowes
http://www.skullsecurity.org/

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