Nmap Development mailing list archives
Re: Ncrack ssh module
From: David Fifield <david () bamsoftware com>
Date: Mon, 13 Jul 2009 09:47:58 -0600
On Mon, Jul 13, 2009 at 07:24:50AM +0300, ithilgore wrote:
SSH unfortunately doesn't allow the authentication of more than one username per connection. This means that in a given connection we can only test the maximum allowed passwords for 1 username. If we try to change the username in a connection, then we get immediately disconnected by the server with reason: (example when we first tried guest and then root as usernames) Disconnecting: Change of username or service not allowed: (guest,ssh-connection) -> (root,ssh-connection) What does the above entail? Ncrack by default uses an iteration of trying each password for every username, instead of the usual iteration of trying every password for each username. This means that given the following lists: Username list: guest, root Password list: 12345, test, foo, bar Ncrack will try them by default with the following order: guest/12345, root/12345, guest/test, root/test, guest/foo, root/foo, guest/bar, root/bar Usually the default for common password crackers is doing the opposite. However, this is less effective for the reason that password lists are usually sorted by order of password frequency. As you have already realized by now neither the default nor the opposite iteration is good enough against SSH targets. Let's suppose that the SSH server allows 3 attempts per connection and we have the following lists: Username list: guest, root Password list: 12345, test, foo, bar, changeme, lala, keke, 000 Suppose Ncrack opens 4 parallel connections numbered #1-#4. Connection #1 will first get guest/12345 and will additionally be allocated with the passwords 'test' and 'foo' for the same username(guest) for the next 2 attempts. Connection #2 will first get root/12345 and will additionally be allocated with the passwords 'test' and 'foo' for the same username(root) for the next 2 attempts. Connection #3 will first get guest/bar and will additionally be allocated with the passwords 'changeme' and 'lala' for the same username(guest) for the next 2 attempts. Connection #4 will first get root/bar and will additionally be allocated with the passwords 'changeme' and 'lala for the same username(root) for the next 2 attempts. After any of the connection finishes, then the first newly invoked connection #5 will get guest/keke and will then try guest/keke and guest/000 and so on.
This is an excellent idea. Based on what you say, this should definitely be the default mode of operation for SSH.
Consequently, I was thinking of providing a 3rd kind of iteration for Ncrack: For every service, Ncrack uses a first reconnaissance probe that opens just 1 connection and tries to make as many authentication attempts as the server allows. By doing this, it can understand the maximum number of allowed authentication attempts per connection against that specific server and since there is only 1 connection open at that time, the reliability of the inference is much higher.
I don't see the need for a reconnaissance probe, unless the architecture of Ncrack requires each connection to know the credentials it will try in advance. Instead, think of it this way: There is a globally optimum next pair to try, but each connection has its own locally optimum next pair that may be different. In the example above, after guest/12345 has been tried, the next best pair globally is root/12345, because that is the next most likely to succeed. But for the connection that tried guest/12345, that's not optimum, because it would have to restart the connection. Instead, its local optimum is guest/test. So when a new connection is started, it grabs the next global optimum. But while a connection exists, it grabs its next best local optimum each time, until the connection ends. I can see the avlue of a reconnaissance probe if you have to attempt a fourth authentication to find that only three are allowed. But if the server disconnects you automatically after three failed authentications, you can use that as the signal to end the connection. Then the software will gracefully cope in case the limit changes dynamically or something.
In addition, I was thinking that maybe it would be best to provide these kinds of options (which of the 3 kinds of iteration) as per-host instead of global ones like --passwords-first that apply to every service. So a user would be able to specify something like: ./ncrack 10.0.0.2:22,it=1 10.0.0.10:21,it=2 where 'it' stands for iteration and 1 and 2 stand for numbers corresponding to each mode of iteration. Something more intuitive could be used there though (instead of mode numbers).
These options seem pretty obscure. You can add them but I don't see them being used much. Picking the best default for each protocol is what's most important.
I am also concerned about some other things but will write about them later. For now, I would like to hear your opinions on the above matters. The first alpha version of the module can be downloaded from this Ncrack branch: svn://svn.insecure.org/nmap-exp/ithilgore/ncrack-ssh
Please provide instructions for checking out, compiling, and testing it against an SSH server. I'm sure there are people (like me) who would be happy to test it but need some more guidance. In particular, I would like a little HOWTO on setting up an sshd locally with a custom passwd file, if that's possible. It's best if people can test this without creating new users with insecure passwords on their own systems. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Ncrack ssh module ithilgore (Jul 12)
- Re: Ncrack ssh module David Fifield (Jul 13)
- Re: Ncrack ssh module ithilgore (Jul 14)
- Re: Ncrack ssh module ithilgore (Jul 14)
- Re: Ncrack ssh module ithilgore (Jul 14)
- Re: Ncrack ssh module David Fifield (Jul 13)