Ncrack timing

[ithilgore <ithilgore.ryu.l () gmail com>]

This week, I finished implementing a major part of Ncrack's timing engine.
Timing is one of the most crucial features of Ncrack as a network authentication
cracking tool and given the flexibility which distinguishes it, makes it one of
its most powerful ones.

Currently, the supported timing options are:
- Connection Limit
- Authentication Limit
- Connection Delay

Additional timing options will be:
- Timeout (not implemented at all yet)
- Maximum Retries (not implemented in timing engine yet)



Connection Limit
-----------------
(Abbreviated as 'cl' in options)

This denotes how many maximum concurrent connections for a given service or in
total will take place at the same time.


Authentication Limit
---------------------
(Abbreviated as 'al' in options)

This denotes how many authentication attempts will be tried out *per
connection*. This is very handy for bypassing logging utilities which rely on
counting how many login attempts are made per connection. For example specifying
an authentication limit of 2 you could avoid being logged by sshd:

(taken from sshd_config's manual)

 MaxAuthTries
              Specifies the maximum number of authentication attempts permitted
per connection.  Once the number of failures reaches half this value, additional
failures are logged.  The default is 6.

Note that the authentication limit may never be surpassed since many services
exist that usually drop the connection after a certain number of failed
attempts. For example, specifying an authentication limit of 6 against a default
configured proftpd will still make a maximum of 3 authentication attempts before
our connections is closed.



Connection Delay
-----------------
(Abbreviated as 'cd' in options)

This denotes how many milliseconds Ncrack will wait after the last connection
before initiating another connection. As you can see, by combining the
"Connection Limit" with the "Connection Delay" you can implicitly specify a
"Connections per <minute/sec>" option (which doesn't exist on its own).


Timeout
--------

After <timeout> seconds/minutes/hours pass, then drop any cracking activity
related to the particular service.


Maximum Retries
----------------
(Abbreviated as 'mr' in options)

This denotes how many times Ncrack will try reconnecting to a service after
failing to connect (either in the beginning or during cracking). This might be
used for completely dropping services that don't answer after 'maximum retries'
when *first* connecting to them, or by giving up on services that seemingly
blacklisted us for opening too many connections against them during cracking.



As you might have noticed, all options except for 'Connection Limit' are applied
on a per-service basis. 'Connection Limit' can be either applied on a specific
service or in a total sum threshold. In the latter case, it means that Ncrack
will never surpass that many connections *in total* at any given time. For example:

$ ncrack ftp://10.0.0.12?cl=10 ftp://10.0.0.20?cl=5 --connection-limit 10

This will limit the connections made against host's 10.0.0.12 ftp service to 10
and against host's 10.0.0.20 ftp to 5. However, --connection-limit will limit
the total sum number of connections against every service to 10, which
essentially means that some services will probably get less connections than the
maximum 'cl' option they specified individually.


Timing Templates
-----------------

Ncrack can be configured to apply a general timing template ranging from T0
(Paranoid) to T5(Insane) to every service. The default is -T3 (Normal) and is
always applied when no other template has been specified. The timing template
configures all the above options and applies them to every service. However,
these options imposed by the templates can be overridden by the option hierarchy
(-g, -m, or host-specific options). See my other mail for understanding how this
works: http://seclists.org/nmap-dev/2009/q2/0484.html



Additional ideas - Dynamic Timing
----------------------------------

Ncrack may be able in the future to dynamically (at runtime) change its timing
options by getting feedback from the victim's replies. If for example, at a time
the victim starts answering with RSTs or doesn't respond at all, while
previously it did, then Ncrack might slow down by temporarily imposing a
stricter connection limit and/or connection delay.



Do you think any other timing option is deemed important and useful? Any other
ideas on how the timing engine could be extended?

I will also probably write a technical analysis of the timing engine in the near
future.

And some timing-measurement info:
Ncrack managed to make about 5000 login attempts per minute against a local
network proftpd server with a default connection-limit of 25 and a 0 ms
connection delay (without breaking anything of course).


Cheers,
ithilgore




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