Date: Tue, 23 Jan 2001 19:48:30 -0300
From: “Iván Arce” core.lists.bugtraq@CORE-SDI.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: [CORE SDI ADVISORY] Weakl 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 vulnhelp@securityfocus.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
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1
F65A
email : iarce@core-sdi.com
http://www.core-sdi.com
Florida 141 2do cuerpo Piso 7
C1005AAC Buenos Aires, Argentina.
Tel/Fax : +(54-11) 4331-5402