Re: Ncrack command-line reloaded

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

Toni Ruottu wrote:
> > Hosts will usually be specified in the following format:
> > <service>://<IP or hostname>:<optional non-default
> > port>?arg1=arg1val,arg2=arg2val
> >
> > e.g  ssh://10.0.0.10:3000?cl=50,al=20
>
>
> I think there is lots of problems with this design. Most importantly you are
> giving new meanings to standard url's. Also the parameters are not
> parameters related to the protocol, but to an external piece of software.
> The target specification looking like an url immediately raises questions,
> like "Can I point ncrack at a website and get the login cracked?" and "What
> happens, if I supply login credentials as part of the url? (e.g.
> http://account () host com/)"


The current scheme was decided over others given the flexibility it provides
over specifying host-specific options. Ncrack also supports Nmap notation in
that you can supply just an address and a port/service (-p option) and will
automatically adapt to cracking these services using default parameters.
e.g $ ncrack 10.0.0.10 -p ssh

The current scheme is url-like (it is *not* a try to copy the url notation) and
the only thing it actually imitates is the delimiter between host and service
(being '://'). Imagine that this could possibly be another delimiter like :/ or
just : (though this would collide with the optional non-default port
specification - e.g  ssh://10.0.0.10:3000).

Anyone that won't bother reading the documentation/man page at all, will
probably just input a plain IP address or hostname and a port using -p. Everyone
else who will probably be more demanding (as in wanting to specify certain
timing options e.g connection limit) will not have trouble understanding the
url-like scheme by reading the relevant documentation.


> Web logins are probably the most common type of login these days and the url
> notations implies that ncrack would be able to hack them, yet I have
> understood that it is not a heuristic that crawls the page for potential
> authentication web forms to try different passwords at, but rather something
> that tries to crack the http authentication. Some day the feature for
> cracking web forms might still be implemented. The first version might
> require the user to provide an actual url and mark the locations of wild
> cards (i.e. user account and/or password) in that url.

Web logins may be the most common type of logins but that doesn't mean that
ncrack will be tailored according to the needs of http only. It will need to
support many different kinds of protocols (we hope to even surpass thc-hydra in
that regard someday) and the url-like scheme combined with the rest of the
command-line interface provides a generic way to accomplish that.

> Regarding mere layout, the description for the url implies : is compulsory,
> which I don't think is intentional. Also, usually url parameters are
> separated by & and not ,. Originally urls were used for identifying network
> "locations". As years has passed the meaning of a location has blurred a
> lot. I'm not sure password cracking results are a good result for probing a
> location, but I do realize some people want to use urls for all kinds of
> different purposes, and I guess in some cases that might be ok. In such a
> case considering URNs and URIs as alternatives for URLs might be a good
> idea.

Using a '&' automatically means that the user will need to escape it (in every
shell afaik), a thing that we want to avoid.


> For these reasons I suggest that, if you decide to go with a url, create a
> new proper ncrack url scheme.
> Maybe something like
> ncrack://10.0.0.10:3000?protocol=ssh&cl=50&al=20<http://10.0.0.10:3000/?cl=50,al=20>in
> respect of your current ideas.

This seems a bit too bloated using the keyword 'protocol' as a separate option
for specifying the current service.

>   may the lockpicks be with you --Toni


-- ithilgore


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