S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 13 novembre 2009
N° CERTA-2009-ACT-046
Affaire suivie par: CERT-FR
le 13 novembre 2009

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-46

Gestion du document

Référence CERTA-2009-ACT-046
Titre Bulletin d’actualité 2009-46
Date de la première version 13 novembre 2009
Date de la dernière version 13 novembre 2009
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Bulletins Microsoft du mois de novembre

Cette semaine, Microsoft a émis six nouveaux bulletins de sécurité corrigeant 15 vulnérabilités, dont trois ont un niveau critique et trois important selon la métrique définie par l’éditeur :

  • une faille dans WSDAPI (Web Service on Devices API) présent dans Windows Vista et Server 2008 permet à une personne sur le même sous-réseau d’exécuter du code arbitraire (MS09-063) ;
  • une vulnérabilité dans le serveur de licences d’enregistrement sous Windows 2000 permet l’exécution de code arbitraire à distance au moyen d’un paquet RPC spécialement conçu (MS09-064) ;
  • des vulnérabilités dans les pilotes en mode-noyau de Windows permettent l’exécution de code arbitraire à distance (MS09-065) ;
  • une faille dans Active Directory permet de provoquer un déni de service à distance (MS09-066) ;
  • plusieurs vulnérabilités dans Excel et dans Word permettent à une personne malintentionnée de provoquer l’exécution de code arbitraire en incitant une victime à ouvrir un fichier spécialement conçu (MS09-067, MS09-068).

Des preuves de faisabilité pour certaines des vulnérabilités sont déjà disponibles sur l’internet et il est donc indispensable d’appliquer les correctifs dès que possible.

2 Retour sur la vulnérabilité TLS/SSL

2.1 Introduction

SSL (Secure Socket Layer) est un protocole mis au point par Netscape à partir de 1995 pour permettre l’établissement d’une connexion sécurisée (chiffrée, intègre et authentifiée). Suite à une normalisation par l’IETF en 2001, le protocole a changé de nom pour s’appeler TLS (Transport Layer for Security).

Les différentes versions de ces protocoles sont :

  • SSLv2 qui est une version obsolète, vulnérable à de nombreuses attaques et qui ne doit plus être utilisée ;
  • SSLv3 qui est une version de compatibilité, à éviter ;
  • TLSv1.0, correspondant à SSLv3.1, qui est la première version formellement définie par l’IETF (RFC 2246) ;
  • TLSv1.1, la version la plus déployée aujourd’hui (RFC 4346) ;
  • TLSv1.2, standard défini depuis août 2008 (RFC 5246), mais qui n’est pas encore largement déployé.

Afin de permettre l’établissement d’un canal de communication chiffré et intègre, les deux parties doivent s’entendre sur les algorithmes et paramètres à utiliser : on parle de négociation. Durant cette étape de négociation, le serveur présente un certificat au client. Ce certificat permet au client d’authentifier le serveur. Il est également possible pour le serveur de demander au client de s’authentifier de la même façon à l’aide d’un certificat.

Par la suite, il est possible aux deux parties de renégocier les algorithmes et les paramètres cryptographiques. Parmi les raisons légitimes d’une telle renégociation, on peut citer :

  • le rafraîchissement des clés cryptographiques avant leur usure ;
  • la demande tardive par le serveur d’un certificat de la part du client (en cas de tentative d’accès à du contenu protégé) ;
  • la nécessité d’employer des algorithmes différents en fonction des données échangées (notons que ce dernier cas est généralement une mauvaise raison).
C’est ce mécanisme de renégociation du protocole TLS qui présente une faille décrite ci-dessous.

2.2 Description de l’attaque

Remarquons que dans le cadre de cet article, les termes SSL et TLS sont interchangeables. En effet, la vulnérabilité mise en évidence affecte toutes les versions des protocoles SSL et TLS existantes à ce jour.

Le 4 novembre dernier, deux chercheurs, Marsh Ray et Steve Dispensa, ont publié des éléments démontrant l’existence d’une faille conceptuelle dans la gestion de la renégociation des sessions TLS. Plusieurs scénarios ont été décrits, mettant en jeu un client et un serveur légitimes, ainsi qu’un attaquant se plaçant « au milieu », c’est-à-dire capable d’intercepter, de modifier et d’injecter tout trafic entre les deux parties légitimes.

Dans tous les cas, l’attaquant a besoin que le client démarre une connexion SSL ou TLS. Le premier message du client (« Client Hello ») est conservé par l’attaquant dans un premier temps, pendant qu’il entame une session SSL avec le serveur. Une fois cette première négociation effectuée entre l’attaquant et le serveur, il est possible au premier d’injecter des commandes auprès du serveur. Lorsqu’il a envoyé tous les éléments nécessaires à son attaque, l’attaquant transmet le message initial du client au serveur, puis relaie de part et d’autre les messages de la renégociation qui a lieu entre le client et le serveur (qui se trouve être la négociation initiale du point de vue du client), en chiffrant/déchiffrant les messages côté serveur. A l’issue de cette négociation, il existe un canal chiffré entre le client et le serveur, auquel l’attaquant n’a plus accès. Le client commence alors à envoyer des messages, sans se douter que l’attaquant a déjà émis des données avant la renégociation. Il est donc possible à l’attaquant d’émettre en clair n’importe quelle quantité de données avant que le client démarre réellement sa connexion et émette ses requêtes, et ce sans qu’aucune des parties légitimes ne puisse le détecter.

Il existe des variantes de cette attaque : par exemple, l’attaquant peut entamer une session HTTPS non authentifiée (côté client), et demander à avoir accès à une page web sécurisée demandant une modification de mot de passe par exemple. Le serveur arrête alors la communication applicative pour demander un certificat au client qui le fournira sans se douter qu’une requête a déjà été émise en son nom. Enfin, la requête sera exécutée par le serveur une fois la renégociation terminée, même si la requête provenait d’un échange alors non authentifié !

2.3 Impact de l’attaque

A priori, seul HTTPS est vulnérable

Cette attaque permet à l’attaquant d’injecter des messages précédant les requêtes d’un client légitime auprès d’un serveur, dans toute connexion TLS permettant la renégociation. Cependant, cela ne semble pas avoir d’impact sur un grand nombre de protocoles utilisant SSL : SMTPS, IMAPS, POPS, etc. En effet, si l’utilisateur veut bénéficier des privilèges d’un utilisateur, il a besoin que celui-ci s’authentifie ; or ces protocoles réalisent l’authentification avant l’exécution des requêtes, ce qui rend inefficace l’injection préalable de trafic, lequel serait perçu comme un ensemble de requêtes non authentifiées.

Il existe toutefois une exception majeure, HTTPS. En effet, il s’agit d’un protocole sans état, dans lequel le contenu de la requête précède l’envoi des éléments d’authentification. Par exemple, on peut voir des échanges légitimes de la forme:

GET /change-mot-de-passe.php?mdp=secret
Cookies: login=georges;session=03462f4a47cd67f

où la première ligne correspond à la requête, alors que la seconde contient les éléments d’authentification. On peut dès lors imaginer des attaques où injecter des lignes permet à l’attaquant d’obtenir des accès privilégiés. Par exemple, s’il injecte le contenu suivant :

GET /change-mot-de-passe.php?mdp=secret
X-Forget-This:

sans terminer la seconde ligne, et que le client légitime envoie la requête :

GET /index.php
Cookies: login=georges;session=03462f4a47cd67f

cela donne au final, vu du serveur:

GET /change-mot-de-passe.php?mdp=secret
X-Forget-This: GET /index.php
Cookies: login=georges;session=03462f4a47cd67f

où l’en-tête spécifique X-Forget-This rend inopérante la requête réelle du client.

La vulnérabilité n’est cependant pas critique

Bien que les implémentations actuelles de SSL et de HTTPS soient vulnérables aux attaques ci-dessus, puisqu’elles acceptent les renégociations, cette attaque ressemble à une autre classe d’attaques déjà bien connues, les CSRF (Cross-Site Request Forgeries). Ces dernières consistent par exemple à utiliser le fait qu’un utilisateur se soit authentifié sur un site donné pour essayer de faire une requête vers ce site depuis une autre page contrôlée par l’attaquant, en bénéficiant des cookies d’authentification.

Dans les deux cas, il s’agit d’attaques « en aveugle » : l’attaquant ne récolte jamais la réponse de la requête qu’il a effectuée, il n’y a pas d’atteinte à la confidentialité de l’échange entre le client et le serveur. L’attaquant ne dispose que d’une seule requête authentifiée pour déclencher son attaque.

La réponse classique pour contrer les CSRF est l’utilisation de jetons liant un formulaire sensible (changement de mot de passe) lorsqu’il est affiché à l’utilisateur à la réponse qu’envoie ce client. Si l’affichage du formulaire n’a jamais eu lieu, comme dans les attaques décrites, aucun jeton n’a été généré et il ne peut y avoir correspondance : la requête sera rejetée.

Ainsi, la vulnérabilité existe mais est atténuée par les contre-mesures souvent déjà existantes qui ont été mises en place pour lutter contre une classe d’attaques voisine.

2.4 Contre-mesures

Nous l’avons vu, des contre-mesures au niveau applicatif permettent de limiter l’impact d’une telle attaque. Il n’en reste pas moins qu’un problème structurel a été mis en évidence dans le protocole SSL : à l’heure actuelle, il n’est pas possible de vérifier que les différentes négociations qui ont lieu au sein d’une même connexion ont été réalisées avec les mêmes interlocuteurs.

Une contre-mesure efficace est d’ores et déjà possible aujourd’hui : elle consiste à simplement refuser toute renégociation côté serveur. C’est le comportement par défaut de la version 0.9.8l de la bibliothèque OpenSSL, publiée le 5 novembre dernier. Cela assure alors au serveur qu’aucun client ne sera attaqué. Cependant, le client n’a toujours aucun moyen de s’assurer de son côté que sa connexion n’a pas été altérée. Cette contre-mesure a des effets secondaires. Elle remet en cause la configuration d’un serveur HTTPS qui fait dépendre les options SSL du répertoire visé. La faille décrite ici peut avoir un impact réel sur la sécurité, d’où la difficulté pour gérer correctement la transition en attendant la nouvelle extension. Il est cependant essentiel de comprendre que l’impact est très dépendant de la couche applicative.

D’autres implémentations (PostgreSQL, VPN SSL…) peuvent être affectées par la vulnérabilité ou sensibles à la contre-mesure précédente. L’analyse doit être faite au cas par cas, pour confirmer ou infirmer le risque.

Dans le cas particulier où une authentification par certificat client doit avoir lieu, une autre contre-mesure intéressante est que le serveur demande ce certificat dès la première négociation, afin d’éviter qu’un attaquant non authentifié puisse injecter des éléments, puisque sa négociation échouera. Cependant là encore, seul le serveur pourra s’assurer de l’absence d’attaque.

Pour résoudre le problème durablement, un projet de RFC (Request For Comments) a été publié (cf. la section Documentation). Ce projet décrit une nouvelle extension TLS, émise à chaque négociation par le client, puis par le serveur (si le client la supporte) et donnant des éléments sur la négociation précédente. Dans l’attaque décrite plus haut, il sera alors possible au client (qui croit réaliser une première négociation) et au serveur (qui pense effectuer une renégociation) de se rendre compte qu’ils ont été dupés, et la négociation échouera.

2.5 Conclusion

Une vulnérabilité conceptuelle du protocole SSL a été découverte par des chercheurs début novembre 2009. Son impact est a priori limité au protocole HTTPS, mais est atténué par des contre-mesures déjà existantes en réponse à une classe d’attaque voisine, les CSRF.

Cette attaque ne remet pas en cause l’intérêt de SSL et TLS pour gérer l’authentification des serveurs et des clients sur Internet. Il est cependant aujourd’hui essentiel de supprimer la possibilité de renégocier les paramètres SSL sur tous les serveurs qui le permettent. Dans un second temps, il faudra mettre à jour la bibliothèque gérant la couche TLS dès qu’une version intégrant la nouvelle extension sera disponible.

2.6 Documentation

3 Gestion des mots de passe dans les applications

Lors d’une analyse d’incident le CERTA a pu constater que certaines applications stockaient les mots de passe de façon peu sûre ou dangereuse lorsque l’utilisateur utilisait la fonctionnalité de « Favoris » de l’application.

Ainsi certains logiciels, pourtant assez connus comme des clients libres de messagerie instantanée ou de transfert de fichiers (FTP), stockent sur le disque les identifiants et mots de passe en clair lorsqu’on leurs demande de sauvegarder les données de connexions d’un site.

Pour certains d’entres eux, les fichiers contenant ces informations sensibles portent un nom très explicite et sont des fichiers au format XML présentant des balises de type <login>…</login> ou bien encore <password>…</password>. Ces balises, elles aussi très explicites, délimitent pour la première un nom d’utilisateur et pour la seconde un mot de passe en clair. Cette grammaire facilite la recherche des donnés sensibles par les programmes et les utilisateurs malveillants.

Il existe pourtant des mécanismes permettant de protéger un carnet de favoris intégrant la sauvegarde des identifiants, en s’appuyant sur des fonctions cryptographiques pour protéger ce type d’informations.

Recommandations :

Lorsque l’on veut utiliser un logiciel, il est indispensable de s’assurer de la manière dont il stocke les données sensibles qu’il aurait à traiter. Dans le cas de la sauvegarde des identifiants de connexion, si cette fonctionnalité doit être utilisée, elle doit garantir, au minimum, la confidentialité des données qu’elle mémorise.

Pour l’utilisateur, une bonne pratique consiste à se souvenir des mots de passe et à ne pas faire confiance en ce genre de fonctionnalité.

4 Codes malveillants pour iPhone/iPod Touch déverrouillé

Dans le bulletin d’actualité de la semaine dernière, nous avions parlé des dangers du déverrouillage (Jailbreak) sur iPhone et iPod Touch. Cette semaine sont apparus de nouveaux codes malveillants exploitant la même faiblesse : l’accès au serveur SSH en utilisant le mot de passe par défaut du compte administrateur.

Jusqu’à présent, les codes exploitant cette erreur de conception étaient plus ou moins inoffensifs. Ils provoquaient par exemple un changement de fond d’écran. Aujourd’hui, il existe des vers réellement malveillants qui permettent d’avoir accès aux données personnelles de l’utilisateur : courriels, répertoire, SMS, calendrier, photos…

Ces codes malveillants parcourent l’Internet, de façon plus ou moins intelligente, à la recherche de services 22/TCP en écoute. Quand ils en trouvent un, ils essaient d’ouvrir une session administrateur en utilisant une attaque par dictionnaire. Les mots de passe testés sont ceux par défaut des comptes administrateur des iPhone/iPod Touch. Cette attaque fonctionne car les utilisateurs qui déverrouillent leurs téléphones et installent un serveur SSH, changent rarement le mot de passe du compte administrateur de leur système.

D’une façon générale, il est clair que les risques en matière de sécurité informatique sont mal évalués lorsqu’on parle de ce type d’appareil. Les bonnes pratiques d’utilisation des ordinateurs sont applicables de la même façon aux smartphones et autres assistants personnels… Comme ne pas surfer sur le Web avec un compte administrateur.

Encore une fois, le CERTA recommande de ne pas effectuer ce type de manipulation, qui a pour conséquence de contourner le modèle de sécurité mis en place dans les iPhone/iPod Touch, et de les rendre plus vulnérables aux attaques informatiques.

Rappel des avis émis

Dans la période du 02 au 08 novembre 2009, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 13 novembre 2009
    version initiale.