HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > Retour sur la faille dans RealVNC 4.1.x du 11/05/06
Accéder au : Site HSC des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|Retour sur la faille dans RealVNC 4.1.x du 11/05/06  

par Julien Raeis (12/12/2006)



--[ Retour sur la faille dans RealVNC 4.1.x du 11/05/06 ]-----------------

--[ 1. Introduction ]-----------------------------------------------------

Cette brève effectue un retour sur la faille touchant le mécanisme
d'authentification dans RealVNC 4.1.x (< 4.1.2), qui permet à un client de se
connecter sans authentification auprès du serveur.

VNC utilise le protocole RFB (Remote FrameBuffer), donc le but est de
"téléporter" un bureau complet (entrées et sorties) d'un poste à un autre, par
le réseau. La description complète du protocole est disponible en [1].

Il existe plusieurs implémentations du protocole (RealVNC, tightVNC, Ultr@VNC,
etc.), qui respectent toutes les bases de ce document.
Nous allons ici discuter de RealVNC, qui en est l'implémentation "originale".


--[ 2. La gestion de l'authentification de RealVNC ]----------------------

Par défaut, VNC ne propose aucune sécurité, que cela soit au niveau de
l'authentification des connexions, ou de la confidentialité des transmissions.
Cette dernière n'est d'ailleurs pas assurée dans l'implémentation par défaut de
RealVNC, et il vaut mieux recourir à un tunnel VPN ou SSH. A noter qu'Ultr@VNC
propose du chiffrement, ainsi que RealVNC Personal et Enterprise editions 
(qui ne sont ni libres, ni gratuites).

Du côté de l'authentification, RFB spécifie, par défaut, deux méthodes :
 - "None" : sans authenthification ;
 - "VNC Authentication" : authentification par challenge/response sur 16
   octets, utilisant du chiffrement symétrique (DES), dont la clé est en
   fait dérivée d'un mot de passe fourni par l'utilisateur (8 octets maximum).

Des extensions du protocole sont par ailleurs définies, afin de proposer
d'autres schémas d'authentification, comme du TLS par exemple. Cependant, le
seul dénominateur commun entre tous les clients et les serveurs est, à ce jour,
le couple ("None", "VNC Authentication").

Le protocole RFB existe dans 3 versions : 3.3, 3.7 et 3.8. Outre quelques
améliorations touchant les performances d'affichage et la charge du serveur
VNC, il existe des différences au niveau de la gestion de l'authentification :
 - Dans la version 3.3 (utilisée dans les clients RealVNC 3.x), le serveur
   imposait sa méthode d'authentification. Si le client ne la supportait pas,
   la connexion ne pouvait s'établir. Sinon, il devait se plier aux demandes du
   serveur.
 - A partir de la version 3.7, le serveur propose une liste de toutes les
   méthodes d'authentification qu'il supporte, et le client renvoie celle qu'il
   préfère utiliser. S'il n'y a pas compatibilité entre les deux parties, la
   connexion ne peut évidemment pas s'établir.


--[ 1. La faille du 11 mai 2006 ]-----------------------------------------
 
 * Qui et quand ?
Le 11 mai 2006, Steve Wiseman, développeur pour le compte d'IntelliAdmin ([2]),
trouve, apparemment sans le faire exprès, une faille dans l'implémentation de
l'authentification de RealVNC 4.1.1.

Il publie alors un article ([3]) et poste un message dans la mailing-list
officielle de RealVNC [4], décrivant le phénomène, ainsi qu'une preuve de
concept permettant de tester la sécurité de son propre serveur VNC.

La réaction de la part de RealVNC est immédiate : retrait des sources de VNC
4.1.1, suppression d'une partie de la mailing-list, faisant référence à cette
faille, mise à disposition d'une version binaire numérotée 4.1.2 corrigeant
la-dite faille, puis enfin, quelques longues heures plus tard, remise en place
des mailing-lists, et des sources de la version 4.1.2 corrigée [5].

La chronologie des événements, sur laquelle il est inutile de revenir, est
discutée dans ce fil : [6].

 * Comment ?
Le mécanisme de connexion et de gestion des authentification de VNC est très
simple.

Tout d'abord, le client récupère la version maximale du protocole gérée par
le serveur, puis renvoie la sienne.
Une fois la version à utiliser établie, le mécanisme de décision de la méthode
d'authentification s'effectue :

Le serveur envoie d'abord le nombre de méthodes supporté, puis la liste de ces
méthodes :
SERVEUR -> CLIENT  : 01 02
Ici 01 signifie que la liste ne contiendra qu'une seule méthode. 02 est le code
de la méthode "VNC Authentification" (challenge/response avec mot de passe).

Ensuite, le client lui renvoie la méthode qu'il souhaite utiliser, ou 00 s'il
ne peut pas satisfaire l'authentification :
CLIENT  -> SERVEUR : 02
Ici, le client a renvoyé 02, le serveur va donc maintenant attendre pour le
challenge.

Si tout se conclut correctement, le serveur envoie "00 00 00 00" au client.
SERVEUR -> CLIENT  : 00 00 00 00


Le client VNC de Steve Wiseman envoyait systématiquement "01" comme méthode
d'authentification (à savoir, justement, "aucune authentification"), sans doute
par erreur de conception, ou parce que le code n'était pas terminé.
A sa grande surprise, le serveur acceptait alors la connexion... sans
authentification, et ce même si le serveur n'était pas configuré pour !

Le code ci-dessous, issu d'un diff entre le code source de la version 4.1.1 et
celui de la version 4.1.2, illustre parfaitement ce qui se passait :

diff -rpEb vnc4-4.1.1+X4.3.0.orig/common/rfb/SConnection.cxx
vnc-4_1_2-unixsrc/common/rfb/SConnection.cxx
*** vnc4-4.1.1+X4.3.0.orig/common/rfb/SConnection.cxx	2005-03-11
16:08:41.000000000 +0100
--- vnc-4_1_2-unixsrc/common/rfb/SConnection.cxx	2006-05-15
18:56:20.000000000 +0200
*************** void SConnection::processSecurityTypeMsg
*** 178,183 ****
--- 178,193 ----
  {
    vlog.debug("processing security type message");
    int secType = is->readU8();
+ 
+   // Verify that the requested security type should be offered
+   std::list<rdr::U8> secTypes;
+   std::list<rdr::U8>::iterator i;
+   securityFactory->getSecTypes(&secTypes, reverseConnection);
+   for (i=secTypes.begin(); i!=secTypes.end(); i++)
+     if (*i == secType) break;
+   if (i == secTypes.end())
+     throw Exception("Requested security type not available");
+ 
    vlog.info("Client requests security type %s(%d)",
              secTypeName(secType),secType);


Le code rajouté vérifie bien que le protocole d'authentification demandé par le
client a été proposé par le serveur, ce qui n'était pas le cas auparavant, où
le client pouvait imposer, comme bon il lui semblait, sa méthode (à condition
que le serveur la supporte, ce qui est le cas systématiquement pour "None").

La faille est par ailleurs aussi décrite en détail en [7], par James Evans.


--[ 3. Quelques tests ]---------------------------------------------------
Afin de vérifier la validité de la faille, sa facilité d'exploitation, et son
étendue, quelques tests ont été réalisés par HSC, vers différentes versions
des serveurs RealVNC disponibles.

Le Framework Metasploit, en version 2.5, a été utilisé pour exploiter la
faille, celui-ci intégrant un exploit valide depuis le 15 mai [8].

A noter que d'autres exploits ont été proposés, notamment par Immunity CANVAS.

Cet exploit utilise le client VNC installé sur la machine de l'attaquant. En
fait, n'importe quel client supportant le protocole RFB 3.8 est suffisant, la
faille étant dépendante de la version du serveur.
La machine servant à l'attaque est une Debian GNU/Linux testing, utilisant le
client xvnc4viewer (RealVNC 4.1.1).

Ensuite, l'exploit se positionne en tant que proxy, entre le client et le
serveur, modifiant à la volée la valeur de l'octet indiquant la méthode
d'authentification choisie par le client.
En d'autres termes, il la met systématiquement à "01".

Une deuxième machine, faisant quant à elle office de serveur VNC, a été
déployée dans le but de tester la possibilité d'exploitation sur les
différentes versions de VNC.

Voici les résultats :

+--------------------+-----------+---------------------------------------+
| Version du serveur |  Système  |       Commentaires                    |
+====================+===========+=======================================+
| RealVNC 4.1.1      | GNU/Linux | Connexion immédiate sans mot de passe |
+--------------------+-----------+---------------------------------------+
| RealVNC 4.1.1      | Windows   | Connexion immédiate sans mot de passe |
+--------------------+-----------+---------------------------------------+
| RealVNC 4.1.0      | Windows   | Connexion immédiate sans mot de passe |
+--------------------+-----------+---------------------------------------+
| RealVNC 4.1.2      | Windows   | Connexion coupée (1)                  |
+--------------------+-----------+---------------------------------------+
| RealVNC 4.0        | Windows   | Connexion coupée (1)                  |
+--------------------+-----------+---------------------------------------+
| RealVNC 3.3.7      | GNU/Linux | "This version is not vulnerable" (2)  |
+--------------------+-----------+---------------------------------------+

Notes :
(1) Metasploit ne renvoie pas d'erreur, mais la connexion tcp est brusquement
coupée, rendant l'exploitation impossible.
(2) Cette version utilise le protocole RFB 3.3, qui n'est pas vulnérable à ce
type d'exploit, puisque c'est le serveur qui impose la méthode
d'authentification.


--[ 4. Comment se protéger ? ]--------------------------------------------

Il existe, heureusement, plusieurs moyens de se protéger contre cette faille.

La première, mais peut-être pas la plus heureuse, consiste à utiliser une
version antérieure à la 4.1.x. Cependant, ce n'est évidemment pas recommandé
pour des raisons de performances.
Ensuite, il est aussi possible de passer à une autre implémentation de VNC,
comme tightvnc ou Ultr@VNC qui ne sont pas vulnérables à cette attaque.
Enfin, la meilleure solution consiste à upgrader sa version 4.1.x en 4.1.2 le
plus rapidement possible.

Pour finir, et afin d'améliorer la encore la sécurité de l'infrastructure VNC,
le passage des flux au travers d'un tunnel VPN ou SSH est évidemment recommandé,
tout comme l'utilisation des listes de contrôle d'accès (ACL), qui sont
remplissables directement à partir de l'outil vncconfig, afin de filtrer les
utilisateurs.


--[ 5. Références ]-------------------------------------------------------

[1] http://www.realvnc.com/docs/rfbproto.pdf 
[2] http://www.intelliadmin.com/blog/
[3] http://www.intelliadmin.com/blog/2006/05/security-flaw-in-realvnc-411.html
[4] http://www.realvnc.com/pipermail/vnc-list/2006-May/054900.html
[5] http://www.realvnc.com/pipermail/vnc-announce/2006/000051.html
[6] http://www.realvnc.com/pipermail/vnc-list/2006-May/054925.html
[7] http://msgs.securepoint.com/cgi-bin/get/bugtraq0605/244.html
[8] http://metasploit.com/projects/Framework/exploits.html#realvnc_41_bypass

--[ .EOF. ]---------------------------------------------------------------



Dernière modification le 6 février 2007 à 18:46:59 CET - webmaster@hsc.fr
Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants