Re: VNC authentication weakness

[David Frascone <dave () frascone com>]

In all fairness, they *hope* people leverage more secure transport
solutions.  From the FAQ:

Q55 How secure is VNC?

   Access to your VNC desktop generally allows access to your whole
   environment, so security is obviously important. VNC uses a
   challenge-response password scheme to make the initial connection: the
   server sends a random series of bytes, which are encrypted using the
   password typed in, and then returned to the server, which checks them
   against the 'right' answer. After that the data is unencrypted and could,
   in theory, be watched by other malicious users, though it's a bit harder
   to snoop a VNC session than, say, a telnet, rlogin, or X session. Since
   VNC runs over a simple single TCP/IP socket, it is easy to add support
   for SSL or some other encryption scheme if this is important to you, or
   to tunnel it through something like SSH or Zebedee.

   SSH allows you to redirect remote TCP/IP ports so that all traffic is
   strongly encrypted, and this can be combined with VNC. SSH can also
   compress the encrypted data - this can be very useful if using VNC over
   slow links. See the 'Using SSH with VNC' page. Zebedee is a similar
   system which can be sometimes simpler to use. You can find info here.

   While we're on the subject of security, you should also be aware that
   only the first 8 characters of VNC passwords are significant. This is
   because the 'getpass' call used in the Unix server to read a password has
   this restriction, and the other platforms have been made compatible with
   this.

   Wolfram Gloger < wmglo () dent med uni-muenchen de> has built Xvnc with the
   TCP Wrapper library, allowing you more control over which hosts are
   allowed to connect. See the contribs page for details.


Q56 Are you going to make it more secure?

   We do hope eventually to add better security to VNC, but there's also a
   good argument for not doing so. If security is a concern, it can be
   better to use a single system such as SSH, FreeS/WAN, or Zebedee to
   encrypt all your traffic, rather than relying on the individual packages
   to do the right thing. Then, if you decide in a year's time that one
   system is too easily crackable, you can replace it yourself and all of
   your communications will benefit. It may also be easier to fit in with
   corporate security systems this way.


On Wednesday, 24 Jul 2002, jepler () unpythonic net wrote:
> VNC authentication weakness
> ---------------------------
>
> VNC uses a DES-encrypted challenge-response system to avoid passing passwords
> over the wire in plaintext.
>
> However, it seems that a weakness in the way the challenge is generated by
> some servers would make this useless.
>
> The following program attempts to repeatedly connect to a vnc server and
> prints the challenge string.
>
> Against tightvnc-1.2.1_unixsrc, you'll see output like
> $ python pvc.py somehost:1
> 4b24fbab355452b55729d630fcf73d43
> b3acdf3fab422b7aa49b8d786f93def3
> b3acdf3fab422b7aa49b8d786f93def3
> b3acdf3fab422b7aa49b8d786f93def3
> b3acdf3fab422b7aa49b8d786f93def3
> 88e37f1677c4e4f56eb2fa00a2804ded
> 88e37f1677c4e4f56eb2fa00a2804ded
> 88e37f1677c4e4f56eb2fa00a2804ded
> 88e37f1677c4e4f56eb2fa00a2804ded
> [...]
> each time the same string is printed twice in a row the server has
> repeated a challenge.
>
> WinVNC version 3.3.3R9 will display output more like
> $ python pvc.py otherhost:0
> Server declined connection
> Server declined connection
> 91ff701f7dce8c6eebbc6062ffebcc6a
> Server declined connection
> Server declined connection
> [...]
> It appears that connects are rate-limited, even if the connects come
> from two distinct machines.  This appears to foil the below attack on
> VNC authentication.  (Whether this means there is a good DoS opportunity
> against WinVNC is a separate question)
>
> If your server will give the same challenge repeatedly, and you can
> sniff somebody else's challenge and response, it appears that you could
> authenticate without knowing the password simply by connecting within
> the 1-second window to get the same challenge, and then send the same
> response as the legitimate client.
>
> Another weakness in the challenge is that it uses 'random()%256'.  Many 
> implementations of random() have highly predictable low bits.  It's not
> clear that this leads to as easy a compromise as the repeated challenge
> problem, but it's something that warrants consideration..
>
> On systems with /dev/urandom, the following function will give challenge
> strings which should be immune to the problems discussed:
>
> void
> vncRandomBytes(unsigned char *bytes)
> {
>     int f;
>     
>     f = open("/dev/urandom", O_RDONLY);
>     while(read(f, bytes, 16) != 16) ;
>     close(f);
> }
>
> #------------------------------------------------------------------------
> #   pvc.py -- check for weak vnc challenges
> #------------------------------------------------------------------------
> import socket, sys, time
>
>
> def print_vnc_challenge(host, port):
>     s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>     s.connect((host, port))
>     f = s.makefile("r+")
>     banner = f.readline()
>     f.write("RFB 003.003\n")
>     response = f.read(20)
>     if response[:4] != "\0\0\0\2":
>       print "Server declined connection"
>       return
>     challenge = response[4:]
>     print "".join(map(lambda x: "%02x" % ord(x), challenge))
>
> if len(sys.argv) > 1:
>     host_port = sys.argv[1]
>     if ":" in host_port:
>       host, port = host_port.split(":")
>       port = int(port) + 5900
>     else:
>       host, port = host_port, 5900
> else:
>     host, port = "", 5900
>
> for x in range(20):
>     print_vnc_challenge(host, port)

-- 
David Frascone

                SPECIMEN: An Italian astronaut.