Re: Ncrack command-line interface overview

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

ithilgore wrote:
> ithilgore wrote:
> > ====== Module Argument Specification ======
> >
> > Another issue is how each service module will take its arguments. Each module
> > might need to take arguments that are either unique to it based on the
> > particular service it handles (e.g http module needs to take a url) or arguments
> > that have to do with general timing options like maximum connections per minute
> > / maximum login attempts per minute.
> >
> > This hasn't been implemented yet so I am awaiting for your suggestions. One idea
> > is to specify it like this:
> >
> > $ ncrack scanme.nmap.org -p ssh,80 -m http:c6,l8,url://main.html -m ssh:c7,t10
> >
> > Where -m is the module argument switch, cX are the connection attempts per
> > minute (or another time measurement unit), lX are the login attempts per minute
> > (both can be applied to all modules) and url:// specifies the url for the http
> > module only.
> >
> > Of course, module arguments will be applied to every host that has selected the
> > particular service for cracking.
> >
> >
> > -- ithilgore
>
> An issue with the above approach is that since module arguments are applied to
> all hosts, we cannot differentiate between unique host-specific arguments. One
> example is when we want to provide different url paths for the http module to
> attack 2 different web servers. To solve that we could allow url paths to be
> inserted next to hostnames to accommodate for this problem. Then it would go
> like this:
>
> $ ncrack scanme.nmap.org/main.html www.google.com/foo.html -m http:c7
>
> And since we've added url paths, it would enable the http module by default even
> if we didn't specify it explicitly in the command-line.
> However, if the above scheme is implemented, then we will probably have to
> remove netmask functionality in host specification (inherited by Nmap) since it
> uses a / to define it (cidr notation)
>
>
> In general, do you think that it is important to allow for unique host-specific
> arguments? The best way to do it cleanly is completely change the current
> implementation and go with a url-like scheme which goes like this (Fyodor
> already suggested it in a conversation we recently had):
>
> $ ncrack ssh://scanme.nmap.org:2000,c8,l10 http://scanme.nmap.org/main.html,c10
> ssh://10.0.0.10 ftp://10.0.0.10:999,c8
>
> You can notice that the above approach perfectly allows specifying
> host-and-service-specific arguments for a unique differentiation between everything.
>
> However, if we do implement that, then
>
> 1) we lose the benefit of Nmap's notation for multiple hosts (although it could
> be perhaps supported up to a point: imagine specifying something like this:
> $ ncrack ssh://10.0.0.*,c8
> and it will crack ssh for all 10.0.0.1-254 hosts.
> However using cidr notation will again be a problem for http url paths.
>
> 2) the user will have to specify too many times the same thing if he wants to
> crack different services for the same host and even more times if he wants to
> crack different services for many different hosts
>
>
> Having seen the above, it would be best if we conclude to the final resolution
> this time, since we now have the complete picture of what might be needed.
>
> Waiting to hear your suggestions,
> ithilgore


To clarify things a bit, since they might sound a bit confusing at first glance
we have the following categories of arguments:
I will take as an example the number of concurrent connections per minute. This
will also prove useful for brainstorming some of the timing options about which
I will soon write a separate thread.

1) Host:
========

How many total concurrent connections for the particular host. This means that
if the host is scanned for more than 1 service, this will limit their
corresponding arguments as an upper total threshold. If for example, I want to
crack host1 for services ssh and ftp and we have imposed a limit of
3 concurrent connections for ssh
10 for ftp and
11 in total for the host then

ncrack will never surpass 11 total connections per minute regardless of whether
it could perhaps go as far as 10+3 connections per minute. This might be useful
for evading IDSs and firewalls which can filter on a per-host basis (as in total
connections or number of packets from a particular IP in a certain time period).

However, this particular argument could as well be calculated by the user
knowing that if he never wants to surpass a certain threshold of say 11 then he
should account for it so that the sum of concurrent connections on each service
for that particular host is less or equal than 11. In our example he would
perhaps specify 8 maximum connections for ftp. This makes this option
essentially redundant.


2) Host-service:
================

How many concurrent connections for the particular service for the particular host.


3) Global-service:
==================

How many concurrent connections for each service. This will be applied to every
service that a particular host has selected it to be cracked.


4) Global-global:
=================

How many concurrent connections in total for everyone. This will be implemented
as a separate option which can be invoked in a way like this: -T c100,l30

This means that we have a total maximum number of 100 parallel connections and
30 login attempts per minute. However this is also redundant information since
the user can calculate the sum based on the sum of all hosts' maximum
connections for all services.
On the other hand, what might be useful would be an option that will act as the
default for every host/service that hasn't overridden it with one of its own.
This will be uniformly applied to every service on every host. So if I have
specified the below:

$ ncrack http://scanme.nmap.org,c30,l10 ssh://www.foo.com svn://svn.bar.org:3000
-T c10

then we will have 10 maximum concurrent connections for ssh://www.foo.com and
svn://svn.bar.org:3000 while scanme.nmap.org will be cracked with 30 maximum
concurrent connections. Of course there will be defaults (which will also be
optimized for each service) in case the user doesn't specify these options.



The problem with the currently proposed command-line interface
($ ncrack scanme.nmap.org -p ssh,80 -m http:c6,l8,url://main.html -m ssh:c7,t10)
is that we can only specify a global-service argument. So if one host is more
strict for ssh and another is less (so we can crack the latter with more
concurrent connections) there is no way to make this distinction if we want to
ncrack them with one ncrack instance. If, however, we implement the url-like
scheme ( $ ncrack ssh://scanme.nmap.org:2000,c8,l10
http://scanme.nmap.org/main.html,c10 ssh://10.0.0.10 ftp://10.0.0.10:999,c8 )
then this will be made possible.

Note that we the discussion is based on the fact that we can do all these things
with only 1 ncrack invocation. If someone wants to crack completely different
hosts he can always exec another ncrack instance. So it is really important to
decide what we really want to do and what the most convenient usage will be.

-- ithilgore


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