On Thu, May 28, 2009 at 12:20:38AM +0300, Toni Ruottu wrote:
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.
Hi Toni. Thanks for your feedback. Our meaning is basically the same
as normal URLs, which is a reason for the syntax. In the example you
quoted above, we're requesting ssh protocol interaction against the IP
10.0.0.10 and port number 3000. A couple arguments are included as
well. This is the same as it would look in a web browser if you had
an SSH plugin except that it would likely take different arguments (if
any) and web browsers usually separate arguments with '&' rather than
The target specification looking like an url immediately raises questions,
like "Can I point ncrack at a website and get the login cracked?"
Yes! The requirements document specifies that Ncrack must be able to
crack web forms as well as http basic authentication. I'd like for it
to be able to parse the page and find the form fields so you don't
have to specify them all yourself.
happens, if I supply login credentials as part of the url? (e.g.
http://account () host com/)"
We aren't currently planning to support this. Even web browsers seem
to consider this deprecated now and give you a security warning
because phishers have abused the syntax so much. But if there is
demand for this sort of feature in Ncrack, we may be able to add it
someday. Especially if the person who requests it adds a patch.
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.
I agree with all this. I'd guess that most people use web form
authentication more than any other authentication type these days, so
I think it is critical that Ncrack be able to support them.
Regarding mere layout, the description for the url implies : is compulsory,
which I don't think is intentional.
Right, it will be optional.
Also, usually url parameters are
separated by & and not ,.
Good point. The problem is that tcsh and bash both require escaping
of ampersands. So I think ',' is a good compromise.
For these reasons I suggest that, if you decide to go with a url, create a
new proper ncrack url scheme.
Maybe something like
Well, ssh is the actual protocol that is used for the communication,
and ncrack is just the client for that protocol. I've used web
browsers which would open a telnet client and connect you to telnet://
URLs, and the current ncrack syntax (ssh://...) seems quite similar.
Thanks again for your feedback! We have a lot of code to write this
summer, so it is extremely useful when people on nmap-dev test the
code and send their ideas.