Bugtraq mailing list archives
Re: VNC authentication weakness
From: David Frascone <dave () frascone com>
Date: Wed, 24 Jul 2002 12:08:28 -0500
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.
Current thread:
- VNC authentication weakness jepler (Jul 24)
- Re: VNC authentication weakness David Frascone (Jul 24)
- Re: VNC authentication weakness Iván Arce (Jul 24)
- Re: VNC authentication weakness Jack Lloyd (Jul 25)
- Re: VNC authentication weakness Constantin Kaplinsky (Jul 26)
- Re: VNC authentication weakness Andreas Beck (Jul 25)
- Re: VNC authentication weakness David Wagner (Jul 25)
- Re: VNC authentication weakness Mitch Adair (Jul 26)
- Re: VNC authentication weakness Jose Nazario (Jul 26)
- Re: VNC authentication weakness Ariel Waissbein (Jul 27)
- Re: VNC authentication weakness David Wagner (Jul 25)
- Re: VNC authentication weakness David Frascone (Jul 24)
- <Possible follow-ups>
- RE: VNC authentication weakness Andrew van der Stock (Jul 26)
- Re: VNC authentication weakness Kragen Sitaker (Jul 28)