FYI CORE released an advisory on VNC authentication weaknesses and suggested tunneling over an encrypted transport on January 23rd, 2001 URL to the original advisory is below: http://www.corest.com/common/showdoc.php?idx=117&idxseccion=10 -ivan --- Perscriptio in manibus tabellariorum est Noli me vocare, ego te vocabo Ivan Arce CTO CORE SECURITY TECHNOLOGIES 44 Wall Street - New York, NY 10005 Ph: (212) 461-2345 Fax: (212) 461-2346 http://www.corest.com PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A ----- Original Message ----- From: David Frascone <core.lists.bugtraq@core-sdi.com> To: <BUGTRAQ@SECURITYFOCUS.COM> Cc: <bugtraq@securityfocus.com> Sent: Wednesday, July 24, 2002 2:08 PM Subject: Re: VNC authentication weakness > 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: > > --- for a personal reply use: =?iso-8859-1?Q?Iv=E1n_Arce?= <ivan.arce@corest.com>
