Re: VNC authentication weakness

[Iván Arce <core.lists.bugtraq () core-sdi com>]

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>