Re: Ncrack command-line reloaded

[Toni Ruottu <toni.ruottu () gmail com>]

> The current scheme was decided over others given the flexibility it
> provides
> over specifying host-specific options.


That is a good feature.


> 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


This is good also.


> 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).

Yep. The problem is it looks exactly like one.


> 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.

You are making a very strong assumption that people actually read the
documentation trough fully. In reality this is very rare. People usually
learn by seeing some one using the software or scanning trough how-tos and
usage example without reading the actual prose.

> 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.

You can use very generic url-whatever later, even if you do not have
anything that looks like a url in the first release.

> 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.

Oh, I see. I guess avoiding & is a good idea then, as long as the url is
nmap specific.

> 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.


Taking into account your feed back I'd go with something like ncrack://
10.0.0.10:3000/ssh/cl=20.al=20

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