Re: WinVNC 3.3.x

[David LeBlanc <dleblanc () MINDSPRING COM>]

At 02:48 AM 11/19/2000 +0000, Gossi The Dog wrote:
> So, you use WinVNC and Windows NT4 Workstation/Server...?
>
> During the InstallShield setup utility, it creates the registry key:
>
> HKEY_LOCAL_MACHINE\Software\ORL\WinVNC3\

> which is used to store all of WinVNC's default settings.  By default,
> Administrator and SYSTEM have full control, and Everybody has Special
> Access (read and modify).

> Ding dong.  The connection password, ip and query restrictions and other
> settings are all stored here, all editable by anybody.

That's nice. Something else to make my job of securing things just a little
harder.  BTW, would the password happen to be in the clear? Maybe XOR'd?

Something that I think is really important to point out is that it is the
developer's responsibility to set permissions on new things that they
create. The defaults that you inherit from the parent keys are meant to
allow nearly anything to work, but isn't appropriate for passwords, or
anything else that's sensitive.

However, VNC doesn't seem especially interested in security - that's why
passwords are limited to 8 characters and are fairly crackable. It's why
the information travels in the clear. This particular application is such a
menace to security that we strongly discourage its use at work.

> This completely comprises any workstation [or server] running WinVNC,
> unless its been tightened.  You can just use regedit remotely to blank the
> password value and set the key "AuthRequired" to 0, to allow the blank
> password...

Well - let's get a little more specific about this. Any local user,
certainly. With respect to the network, it gets a lot more complicated.
First, consider the winreg key - ANY user who has ANY permissions to the
winreg key has access to the rest of the registry as regulated by the
permissions on the keys. In particular, NT 4.0 Workstations will have weak
permissions UNLESS the registry permission fix has been applied that
tightens up several other keys in the process. NT 4.0 servers and Win2k
systems should have this restricted to admins for the most part. Next thing
to consider is the AllowedPaths - these are exceptions to winreg - but
HKML\Software isn't on the allowed paths on any version by default. Thus to
exploit this from the network, the machine needs to be an NT 4.0 system
missing the registry permission patch. If you're missing the registry
permissions patch, then there are several other Bad Things that can happen
to you (e.g., AeDebug - hi RFP). So if the machine is either Win2k or
properly patched, you've got to be admin (or close to it - I think backup
ops will do) in order to gain access from the network.

> Under Windows 2000, network users with "Standard User" (aka Power User)
> privs can do the same by default - really only admins should have access
> to this key.

Never heard it called standard users. Be careful with who you make power
users, as they are really admins-lite. BTW, this also depends on who you
want to be able to USE VNC - I'd bet that they require anyone using it to
have access to these keys. Also not an especially wonderful thing from a
security standpoint.

> This isn't anything brilliantly new (lax security permissions by default
> under NT4), but since WinVNC allows complete remote access to a system, I
> feel its important people realise what they are deploying.

That's always nice to know. However, MS is only to blame for permissions
that aren't ideal when a MS product created the key. If some other vendor
goes writing to the registry or disk, and doesn't set permissions properly,
that's their mistake. I'd bet that if you check, VNC default install puts
executables in places that can be tampered with, too. I wrote a couple of
articles on this that might be helpful to someone programming this sort of
thing:

http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=9696
http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=9796

You might note that when I originally wrote the NT version of the ISS
Scanner, properly setting registry and file system permissions were one of
the first things it did.

> FIX - Use regedt32 to remove Everybody's permissions on the key entirely.

A better fix is to use something more secure. Another fix detailed in
Stephan Norberg's new book from O'Reilly is to tunnel VNC though ssh, or if
you have Win2k, wrap the whole thing in IPSec. And fix the registry
permissions - also check the file system permissions, as I'd bet they do
the same thing there.


David LeBlanc
dleblanc () mindspring com