Howartd,

Reading the protocol description of VNC you can determine that this form of
attack could take place in both LAN and Internet environments. The advisory
states that the man-in-the-middle needs to be able to re-write packets
destined for the legitimate client. To be guaranteed of success this would
require the hacker to either be a router or similar infrastructure device
between the server and a legitimate client. If not an infrastructure device
the hacker could theoretically create network noise as soon as it sees the
packet intended for the legitimate client in the hope that the client has
not received the packet yet, but this would only work if the hacker was on
the same LAN segment as either the server, client, or in some cases a router
in-between, and even then only occasionally and only using certain network
topologies.

Many factors would require to come together for this attack to work. It
doesn't mean that you are secure against an attack but it does make it
highly unlikely. It would be relatively trivial to to extend the protocol to
make it more secure.

The *real* problem with the protocol is that all data is sent between the
client and server unencrypted. In my mind this is much more of a problem
than that the advisory outlines. The web-pages for VNC even suggest that for
secure communications you use SSH or similar (and this is contained in the
advisory also). Again, the protocol could be extended to provide end-to-end
encryption of data thus defeating a man-in-the-middle attack but the
developers have prided themselves on the simplicity of the protocol.

If you want a more secure solution look towards pcAnywhere (not without
problems of its own) or use Windows NT 4 Terminal Server or Windows 2000
Terminal Services as RDP is a much more secure protocol.

john...

----- Original Message -----
From: "Howard Marsh" <HowardGAWB.QLD.GOV.AU>
To: <win2ksecadviceLISTSERV.NTSECURITY.NET>
Sent: Tuesday, January 23, 2001 3:25 PM
Subject: Re: [CORE SDI ADVISORY] Weak authentication in ATT's VNC

Interesting..... I use VNC to access a number of servers across a LAN and I
also have clients using VNC to access their work computers from home. In
every case, the fact that VNC refused the connection would raise warning
flags and an attempt to reconnect would be made immediately, making sure
that all entries were typed more carefully - assuming, as usual, operator
error ;-).

By default, the VNC configuration allows only one connection per box. Yes,
there is a facility to ask for a concurrent connection but that is not the
default and is certainly not used in the above scenarios. If an attacker
hijacked a connection via VNC and then the legitimate client made another
connection attempt to the same box, would not the original connection be
disconnected? If so, this vulnerability would be fairly shortlived under the
above circumstances. If not, the genuine client user would be pretty
suspicious about the connection being rejected twice.

I'd like to see a little more information on this advisory:

- does this vulnerability affect only connections made across the Internet?
If so, why doesn't it apply on a LAN? (If the answer is obvious, please
pardon my ignorance but tell me any way!!)

- no mention has been made of the need to enter a password. I presume the
password required by the client is for the client's end only and therefore
doesn't affect the attacker, but what about the password required to
authenticate the user if the server requires it (an NT box for example)?
Wouldn't the attacker need to do some more work or be left staring at a
login screen?

- would a subsequent connection attempt disconnect the attacker?

It's not often that one of these advisories actually affects me or my
clients so I am intrigued by this one. More information please!

Regards,
Howard Marsh
HWM Consulting Pty Ltd
QLD, Australia.

-----Original Message-----
From: Iván Arce [mailto:core.lists.win2ksecadviceCORE-SDI.COM]
Sent: Wednesday, 24 January 2001 8:52
To: win2ksecadviceLISTSERV.NTSECURITY.NET
Subject: [CORE SDI ADVISORY] Weak authentication in ATT's VNC

                                    CORE SDI
                           http://www.core-sdi.com

        Vulnerability report for weak authentication in ATT VNC

Date Published: 2001-01-23

Advisory ID: CORE-2001011501

Bugtraq ID: 2275

CVE CAN: None currently assigned.

Title: Weak authentication in ATT VNC

Class: Design error

Remotely Exploitable: yes

Locally Exploitable: no

Release Mode: USER RELEASE

Vulnerability Description:

 As stated in the VNC home page ( http://www.uk.research.att.com/vnc/ ):

 "VNC stands for Virtual Network Computing. It is, in essence, a remote
 display system which allows you to view a computing 'desktop'
 environment not only on the machine where it is running, but from
 anywhere on the Internet and from a wide variety of machine
 architectures".

 VNC uses a challenge/response mechanism for authenticating
 clients in order to avoid the transmition of clear text passwords
 over insecure channels and prevent unauthorized clients to
 get access to the VNC server.

 A design flaw in the client authentication mechanism permits an attacker
 to obtain legit credentials from a valid client in order to gain
 unauthorized access to the server.
 The attack can be perfomed by an attacker eavesdropping the client/server
 communications with the ability to modify the data flow. NO TCP hijacking
 techniques are required.

 There are other security issues related to the fact that
 VNC does not provide a secure transport protocol that ensures
 confidentiality for the data transmited, those are well known and
 considered design decisions from the VNC development team.
 This advisory does not include them, the advisory addresses a
 security flaw in the design of the authentication mechanism that
 makes it unsuitable to fulfill its design goal.

Vulnerable Packages/Systems:

 VNC up to version 3.3.3 on all supported platforms.

Solution/Vendor Information/Workaround:

 It is advisable to tunnel communications between the VNC server and
 client through a cryptographycally strong end-to-end authenticated
 channel.
 References for doing so are provided in the VNC FAQ
 (http://www.uk.research.att.com/vnc/faq.html) and specifics on how to
 tunnel VNC over SSH are provided at:

  http://www.uk.research.att.com/vnc/sshvnc.html

Vendor notified on: 2001-01-15

Credits:

 This vulnerability was found by Emiliano Kargieman, Agustin Azubel
 and Maximiliano Caceres from Core SDI, http://www.core-sdi.com

 This advisory was drafted with the help of the SecurityFocus.com
 Vulnerability Help Team. For more information or assistance drafting
 advisories please mail vulnhelpsecurityfocus.com.

 This and other CORE SDI advisories are available at:
 http://www.core-sdi.com/english/publications.html

Technical Description:

 1. Man in the middle attack against client/server authentication

  VNC authenticates communication between client and server using a
  challenge-response mechanism.
  Due to design flaws in the challenge/response mechanism it is
  possible to perfom a man in the middle attack and obtain
  unauthorized access to the VNC server.

  The client authentication mechanism is described below:

   Asumming that C (the VNC client) is trying to authenticate to
   S (the VNC server), the following protocol is used:

   - A DES key (k) is shared by both endpoints and used for the
     challenge-response.

   - 'C' connects to 'S' and both endpoints exchange software/protocol
     version information

   - 'S' generates a 16 byte challenge and sends it to 'C'

   - 'C' encrypts the received challenge with 'k' and sends the result
     ('rc') to 'S'

   - 'S' encrypt the challenge with 'k' and compares the result ('rs')
      with the response 'rc' received from the client.

   - If rc==rs access is granted to the client. Otherwise access is
     denied.

  A classical man-in-the-middle attack can be perfomed against the
  described protocol.

  Assuming that the attacker ('M') has access to the data flowing between
  client and server and is able to modify such data, an attack scenario
  THAT DOES NOT imply a TCP session hijacking attack is outlined:

  - 'M' connects to 'S' and both endpoints exchange software/protocol
     version information

  - 'S' generates a 16 byte challenge ('r1') and sends it to 'M', now
    'M' has a connection established with 'S' with the authentication
     pending a response to the server.

  - 'M' waits for a connection from a legit client 'C' to 'S'

  - Upon connection from the client 'C' to the server 'S', the server
    (as per the protocol design) generates a 16 byte challenge
    ('r2') and sends it to 'C'.

  - 'M' modifies the data traveling from 'S' to 'C' and replaces
     'r2' with 'r1'

  - 'C' receives 'r1' and encrypts it with the shared key 'k', the
     result ('r1c') is sent to the server 'S'

  - 'M' captures the response 'r1c' sent to the server 'S' and uses
    it in its own pending connection.

  - 'S' receives 2 equal responses (r1c), one from 'C' and one from
    'M'. It encrypts with 'k' the challenges (r1 and r2) sent
     and compares the results (r1s and r2s) against the received responses

  - For the legit client connection ( r2s != r1c ) and therefore access
    is not granted

  - For the attacker M connection ( r1s == r1c ) and therefore access
    is granted

  The attacker obtains unauthoraized access to the server using the
  client to generate a valid response to the challenge received.

 2. Weakness in the generation of the random challenge data.

  Additionally, the challenge is generated via rand(3) calls,
  initializing the randseed with a call to time(2).
  The 128 bits which comprises the challenge are generated by sucessive
  calls to rand, each one returning 8 bits of data.
  This actually reduces the useful randomness of the challenge to just
  16 bits, depending on the return value of time() (with precision of a
  second).

  The above two facts together render the challenge highly predictable,
  and could enable an attacker eavesdropping connections from a client
  to capture responses and reuse them at a different time in order to
  obtain unauthorized access to the server.

DISCLAIMER:

 The contents of this advisory are copyright (c) 2000 CORE SDI Inc.
 and may be distributed freely provided that no fee is charged for this
 distribution and proper credit is given.

$Id: VNC-auth-advisory.txt,v 1.7 2001/01/23 21:28:53 max Exp $

---
"Understanding. A cerebral secretion that enables one having it to know
 a house from a horse by the roof on the house,
 Its nature and laws have been exhaustively expounded by Locke,
 who rode a house, and Kant, who lived in a horse." - Ambrose Bierce
==================[ CORE Seguridad de la Informacion S.A. ]=========
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A
email   : iarcecore-sdi.com
http://www.core-sdi.com
Florida 141 2do cuerpo Piso 7
C1005AAG Buenos Aires, Argentina.
Tel/Fax : +(54-11) 4331-5402
=====================================================================
--- For a personal reply use iarcecore-sdi.com
_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net
IMPORTANT: This e-mail may contain information that represents the views and
opinions of the author and so may not necessarily reflect the views and
opinions of the Gladstone Area Water Board as an organisation.
The information in this e-mail may be privileged and confidential. It is
intended solely for the use of the addressee(s) named. Any unauthorised use
of the e-mail or contents is expressly prohibited.
If you have received this e-mail in error, please advise us immediately by
return email or by telephone and then delete it.
Gladstone Area Water Board, PO Box 466, 147 Goondoon Street, Gladstone QLD
4680, Australia.
ABN 88 409 667 181 phone: +61 7 4976 3000 fax: +61 7 4972 5632
E-Mail: gawbgawb.qld.gov.au  Web Site: www.gawb.qld.gov.au
_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net
_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]