[26298] in bugtraq
Re: VNC authentication weakness
daemon@ATHENA.MIT.EDU (=?iso-8859-1?Q?Iv=E1n_Arce?=)
Wed Jul 24 17:49:14 2002
Message-ID: <046e01c23358$2e3662d0$2e58a8c0@ffornicario>
From: =?iso-8859-1?Q?Iv=E1n_Arce?= <core.lists.bugtraq@core-sdi.com>
To: <BUGTRAQ@securityfocus.com>
Cc: <jepler@unpythonic.net>, <core.lists.bugtraq@corest.com>
Date: Wed, 24 Jul 2002 18:22:14 -0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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>
