Re: ncrack vnc

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

On 09/28/2010 06:41 PM, Ryan Hayward wrote:
>  Attached is a patch for a rough version of a VNC module for ncrack. There
> are several TODO's remaining, mostly involving error checking.

That's great! What are the things left to do to complete it?


> To get the patch to work, I had to do the following:
>
>
> 1. patch < ncrack_vnc.patch
> 2. since modules/modules.h failed to patch, I added the line 'void
> ncrack_rdp(nsock_pool nsp, Connection *con);' at the end of the modules list.
> 3. mv d3des.cc ncrack_vnc.cc modules/
> 4. ./configure
> 5. patch < ncrack_vnc_makefiles.patch
> 6. modules/Makefile didn't patch, so I added 'd3des.cc ncrack_vnc.cc' to
> the end of the SRCS line and 'd3des.o ncrack_vnc.o' to the end of the OBJS
> line.
> 7. make

Have you checked if we could use the DES implementation that is already
provided by OpenSSH? Ncrack's SSH module already relies in opensshlib which
has hacked out of the original OpenSSH code which has a lot of crypto in
it. In addition, it would be best if all the generic crypto stuff went into
the relevant file 'crypto.cc' in the central Ncrack directory and the
modules/ dir should only contain clean modules, rather than libraries or
other stuff they depend on.


> That got me a version that would make, and run.
>
> A couple of other notes:
>
> 1. User doesn't matter, as VNC auth just uses a password.  I've been
> calling it with '--user whatever' just to make it not try a bunch of
> different users.

Currently there is no other way for a module to only check for passwords,
but I could make a patch in the engine which allows modules to flag a
relevant option. I suppose this could be used for other protocols that are
password-only as well.

> 2. Currently the patch only adds 5901 to the ncrack-services.  I've tested
> adding 5900, 5901 and 5902 to the ncrack-services, and it works fine.  A
> range would be nice, though.
>
> 3. On the tightvncserver version I was testing against, a run-away brute
> force would lead to many
>
>     "vnc://127.0.0.1:5901 Too many authentication failures"
>
> messages.  I'm currently just doing the following in that case:
>
>       if (memsearch((const char *)con->inbuf->get_dataptr(), "Too many
> authentication failures", con->inbuf->get_len())) {
>         error("%s Too many authentication failures\n", serv->HostInfo());
>         return ncrack_module_end(nsp, con);
>       }
>
> But it seems to me that when the vnc thread receives that, it should
> suspend for some amount of time before trying that pass again, or trying a
> different pass.  I don't know what that would be, nor was I able to find an
> example of how to suspend a thread in a polite manner.

Does VNC exhibit this behaviour when a particular password is tried over
many times or whenever it just receives too many attempts overall? I think
it will probably be the latter in which case, the Ncrack engine will only
back off for a bit only when it receives RST or senses connection timeouts.
Since this appears to be protocol-specific (or it might even be server
specific), the only way to solve this would be to introduce some additional
module options that are 'commands' to the central engine. In general, we
want to avoid this as much as possible, as the modules should only concern
themselves about the protocol itself and not have to deal with the raw TCP
stuff which are better handled by the Ncrack engine. However, there are
already some options in the Connection class, like 'force_close' which
whenever set by a module, orders Ncrack to forcefully close the connection
regardless of its state. This is currently only used by the RDP module (but
might come in handy in the future for other protocols) and there are also
some other connection-related options. These features that the VNC module
and potentially others in the future might need, will be part of the
'Ncrack engine extension' which is already in the TODO list.

Btw, have you checked if this is the behaviour in other popular VNC
software? Which software did you try it against?

Regards,
ithilgore

--
http://sock-raw.org
http://twitter.com/ithilgore


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