Nmap Development mailing list archives
Re: Ncrack ssh module
From: ithilgore <ithilgore.ryu.l () gmail com>
Date: Tue, 14 Jul 2009 17:06:52 +0300
ithilgore wrote:
David Fifield wrote: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.The reconnaissance probe is being sent out on all occasions against every service for the following reasons: * It is used to gather timing information like how much time the server delays between sending him our credentials and showing us the results of the authentication attempt. This will be used by the Ncrack dynamic engine to infer whether it will be faster to later open even more connections instead of trying to wait for a possibly long time between each auth-attempt of the same connection. This happens when the sum of the 3way handshake time and the time of the pre-authentication protocol exchange is less than the time of the delay imposed by the server when showing the results of an auth-attempt. In particular, it will be even more important for services that impose an exponential increase for each attempt in the same connection (e.g 1 sec in the first attempt, 5 secs in the second and 15 in the 3rd) * It is sent in the beginning when no other connection has been opened against that particular service, so that makes it reliable enough. We haven't started hitting the server with a load of connections yet and thus we are more certain that we won't be disconnected in the middle of the authentication (which tends to happen even in a local network when the number of connections increases dramatically) * It isn't really time-consuming since it only happens for one time in the beginning of each service cracking. * There are services out there that require you to try N+1 times to authenticate before they disconnect you and then you realize that only N attempts are allowed. In these cases, sending out the +1 packet *for each* connection is a total waste of bandwidth. Examples of these services that I have encountered so far are many telnet daemons.
I also forgot to mention another reason that an initial connection on its own makes sense: if the user specified a multitude of hosts (for example using wildmasks or subnet-masks) then it is quite possible that some of them do not actually listen on the selected ports. If Ncrack gets an RST on the first probe, then it marks the service as having ended and doesn't concern itself anymore with it. It would be quite a waste having sent multiple connections all at once from the beginning ending up getting that many RSTs back. Multiply that with the number of hosts that don't listen on the port and you get a serious bandwidth waste. The same holds true for special cases of services that while they do listen on the selected port, we can deduce that there is no point in hitting them. An example would be an FTP server that explicitly says that it only accepts anonymous logins. Of course, that could also be an admin's spoof so it would probably be a good idea to have an option like --force-crack that doesn't take into account the above warning. -- ithilgore _______________________________________________ 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)