S.G.D.S.N

Agence nationale
de la sécurité des
systèmes d'information

Paris, le 16 septembre 2011
N° CERTA-2011-ACT-037
Affaire suivie par: CERT-FR

Bulletin d'actualité du CERT-FR

Objet: Bulletin d'actualité 2011-37

Gestion du document

Référence CERTA-2011-ACT-037
Titre Bulletin d'actualité 2011-37
Date de la première version 16 septembre 2011
Date de la dernière version 16 septembre 2011
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 Mises à jour Microsoft de la semaine

Cette semaine Microsoft a émis cinq bulletins de sécurité concernant Microsoft Windows, Microsoft Office ainsi que des logiciels serveurs Microsoft. Les vulnérabilités qui y sont décrites sont jugées comme étant importantes par l'éditeur.

Le CERTA recommande d'appliquer rapidement les correctifs de sécurité associés.

Documentation

2 Mises à jour Adobe de la semaine

Cette semaine, Adobe a émis plusieurs mises à jour de sécurité concernant différents produits, notamment Adobe Acrobat et Adobe Reader.

Le CERTA recommande d'appliquer ces mises à jour rapidement.

Documentation

3 Filtrage et tunnels chiffrés

3.1 Introduction

Contrôler efficacement des flux chiffrés à l'aide d'équipements actifs se révèle bien souvent problèmatique. En effet, par leur nature, ces flux ne peuvent être inspectés. Ainsi, la plupart du temps ils sont soit autorisés par défaut, soit totalement interdits. Bien entendu, de telles configurations posent des problèmes évidents de sécurité dans le premier cas et d'accessibilité dans le second. Il est effectivement difficile aujourd'hui de bannir totalement un protocole comme SSL mais il est cependant nécessaire de s'assurer que le trafic est légitime. Dans la suite de cet article, nous allons nous concentrer sur SSL et son fonctionnement et fournir quelques pistes de reflexion concernant le filtrage de flux chiffrés.

3.2 SSL et la méthode CONNECT

La gestion de SSL au niveau des équipements actifs fait appel à un mécanisme bien particulier décrit dans la RFC 2616, concernant HTTP/1.1. Il est possible de signifier dynamiquement à un équipement que l'on désire utiliser un tunnel chiffré grâce à la méthode HTTP CONNECT. L'équipement concerné va alors passer en mode tunnel : il va agir comme un simple relais et ne plus exercer son rôle de filtrage sur le flux.

L'utilisation de cette méthode rend donc possible le contournement des équipements de types pare-feux et serveurs mandataires.

Notons que la RFC 2817 complète la RFC 2616 et propose notamment des considérations de sécurité sur la méthode CONNECT.

3.3 Exemple de communication SSL

Lorsqu'un client, situé derrière un serveur mandataire (ou proxy), souhaite établir un tunnel chiffré vers un serveur distant, il s'adresse à son proxy en précisant l'adresse et le port de destination. Ce dernier se charge alors d'établir la connexion avec le serveur distant, si cette dernière est autorisée. Une fois cette connexion établie (réception d'une réponse de type 200), il ne sert plus que de relais entre le client et le serveur distant et n'intervient pas sur les données chiffrées.

Il est aussi possible pour SSL d'utiliser une connection de type SOCKS. Dans ce cas, le tunnel est pré-établi et le proxy n'a pas à effectuer la négociation avec le serveur distant. En terme de filtrage, il n'a alors que deux options, bloquer ou autoriser le flux.

En pratique, la mise en place de filtrage des flux à destination du port SSL (443/TCP) n'est pas courante : les flux sont autorisés par défaut.

3.4 Impact sur la sécurité

Le relatif laxisme envers les flux à destination du port 443/TCP permet notamment de contourner un serveur mandataire ou bien encore d'échapper aux règles des pare-feux.En effet, il est possible, au moyen d'outils spécifiques, de créer un tunnel HTTP vers ce port, grâce à la méthode CONNECT, et d'y faire transiter toutes sortes de flux normalement filtrés (Skype, SSH encapsulé dans du HTTP...). Ces flux, légitimes ou non, ne seront pas bloqués par les équipements de filtrage puisque ces derniers agissent uniquement comme des relais.

De plus, en cas de mauvaise configuration, cela peut également être un point d'entrée dans un réseau : l'attaquant se connecte au relais, et envoie une requête à un serveur interne en utilisant la méthode CONNECT. Ici encore, les équipements de filtrage laisseront passer le flux, pensant qu'il s'agit d'une connexion chiffrée.

L'utilisation de ce type de mécanisme afin de cacher du trafic illégitime a d'ailleurs été observée récement par le centre de détection de l'ANSSI. Il s'agissait d'une fausse connexion SSL dans laquelle étaient encapsulés des flux de type RTMP, afin de faire passer des données en streaming à travers les équipements de contrôle. Ces flux ne sont pas nécessairement malveillants mais peuvent être illégitimes ou bien encore alourdir le trafic.

Le CERTA a également publié une note d'information sur ce type de problèmatiques le 29 août 2001, actualisée le 21 mars 2011.

3.5 Quelles réponses?

Il est important d'observer la nature réelle des flux transitants afin d'en valider la légitimité. Il est par exemple possible de créer une alerte quand un tunnel chiffré à destination du port 443/TCP transporte autre chose que du HTTPS. Il est également envisageable de contrôler par une liste blanche les destinataires légitimes de flux chiffrés. D'autres solutions sont proposées dans la note d'information rédigée par le CERTA.

Des solutions techniques d'inspection directe des flux chiffrés existent mais peuvent entrer en conflit avec le secret de la correspondance et/ou nécessiter une déclaration spécifique à la CNIL.

Documentation

4 Typosquatting et vol de courriels

Deux chercheurs ont mené une étude sur une technique de « typosquatting » nommée le « doppleganger domain ».

Le « typosquatting » de nom de domaine consiste à acheter des noms de domaine dont la graphie ou la phonétique est proche de celle du site d'une marque ou d'une entreprise connue. Les « doppleganger domain » sont des noms approchants du domaine légitime, mais qui diffèrent légèrement par l'absence de séparation entre le sous-domaine et le domaine principal, par exemple : seibm.com à l'instar de se.ibm.com. Les chercheurs ont enregistré 30 « doppleganger domain », visant des entreprises du Fortune 500, et ont récupéré tous les courriels envoyés par erreur à ces adresses. Sur une période de 6 mois, 120 000 courriels représentant un volume de 20 giga-octets de données ont été collectés. Sachant que d'après l'étude publiée, sur les 500 sociétés, 151 sont vulnérables à une telle attaque, soit près de 30%.

Les courriels récupérés grâce à cette technique contenaient des informations sensibles qui pourraient être utilisées de façon malveillante. On peut citer entre autres : les noms de connexions et mots de passe des employés, des informations sur les configurations et les architectures des intranets des entreprises, des accès VPN mais aussi des informations personnelles.

Toutes ces informations peuvent être obtenues de manière passive en mettant en place un « doppleganger domain » et un serveur de courriel. Cependant, l'attaquant peut aussi répondre aux courriels afin d'obtenir plus d'informations.

De plus, durant cette étude, les chercheurs se sont aperçus qu'un certain nombre de grandes entreprises américaines sont victimes de cette pratique.

Afin de se prémunir au mieux de ce type d'attaque il convient :
  • d'utiliser un logiciel de chiffrement afin de protéger les échanges d'informations sensibles ;
  • d'avoir une veille sur les possibles noms de domaines pouvant être « typosquattés » susceptibles d'avoir un impact ;
  • de lancer des procédures de recouvrement de noms de domaines « typosquattés » par des tiers, au moyen d'une procédure UDRP.

Documentation

5 Diffusion d'un faux client BitTorrent malveillant

Cette semaine, le site http://www.bittorent.com a averti ses utilisateurs d'un incident de sécurité survenu sur l'un de ses serveurs hébergeant le client pour réseau pair à pair, uTorrent. En effet, le 13 septembre 2011 entre 11h20 et 13h10 GMT, le site http://www.uTorrent.com a diffusé un code malveillant en lieu et place du client légitime suite à une compromission du serveur. Le code malveillant affichait une fausse alerte antivirale demandant le paiement d'une certaine somme afin de se débarasser du logiciel indésirable.

Le site http://www.bittorent.com a publié une procédure de désinfection sur l'Internet (cf. section documentation). Le CERTA recommande à toute personne ayant téléchargé le client uTorrent pendant la plage horaire indiquée précédemment à suivre les instructions afin de supprimer au plus vite ce code malveillant.

Documentation

Rappel des publications émises

Dans la période du 05 septembre 2011 au 11 septembre 2011, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 16 septembre 2011
    version initiale.