Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Ncrack command-line reloaded
From: Toni Ruottu <toni.ruottu () gmail com>
Date: Wed, 3 Jun 2009 00:28:41 +0300

  Thank you for continuing the discussion!

Your email is very enlightening, and I do now agree that your
direction is correct. Yet you still don't provide any rationale for
having ncrack specific options as parts of the url. I see no benefit
of that, and it causes an obvious problem, if some url happens to use
the same keys for the actual server query. I understand that this
might be unlikely with just two options, but one day there might be
other options as well. It also wouldn't be clear to a Sunday ncrack
user that cl and al are parameters to ncrack and not the service at
the target end.

Creating a completely separate ncrack target specification format
might make sense. We could still use the url for pointing at the
service. For example you could go with a comma separated list of
options. Say...


The length could be optimized by changing url into just u...


, or the url could just always be the last element...


it could be emphasized that the options are optional, while the url is


or maybe


it might make sense to add an identifier at the front


or it might not


My point being that using url's is good, but extending them in
unexpected ways is not necessary, nor preferable.


On Tue, Jun 2, 2009 at 4:22 AM, Fyodor <fyodor () insecure org> wrote:
On Thu, May 28, 2009 at 12:20:38AM +0300, Toni Ruottu wrote:

e.g  ssh://,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.

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

and "What
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.


Sent through the nmap-dev mailing list
Archived at http://SecLists.Org

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]