S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 05 février 2010
N° CERTA-2010-ACT-005
Affaire suivie par: CERT-FR
le 05 février 2010

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2010-05

Gestion du document

Référence CERTA-2010-ACT-005
Titre Bulletin d’actualité 2010-05
Date de la première version 05 février 2010
Date de la dernière version 05 février 2010
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 Vulnérabilité dans Internet Explorer

1.1 Résumé

Cette semaine une vulnérabilité non corrigée affectant Internet Explorer a été dévoilée à la conférence BlackHat DC. Cette vulnérabilité n’a pas fait l’objet d’une alerte CERTA vu l’impact limité et l’absence d’exploitation connue.

1.2 Description

Si un utilisateur navigue sur un site spécialement malformé, il est alors possible pour l’attaquant de récupérer des fichiers présents sur le disque de la machine utilisateur.

Il y a cependant plusieurs facteurs atténuants :

  • L’attaquant doit connaître le chemin complet des fichiers (pas de possibilité de lister les fichiers du disque). Les fichiers accessibles dépendent des droits de l’utilisateur et de leur état d’utilisation (impossibilité de copier un fichier ouvert par le système ou une application) ;
  • Microsoft propose plusieurs contournements dans son bulletin de sécurité #980088, dont un paquet FixIt redistribuable utilisant le Network Protocol Lockdown permet de restreindre l’accès au protocole file:// dans la zone Internet.

    Le mode protégé d’Internet Explorer sous Windows Vista et Windows 7 limite aussi l’accès aux fichiers du disque.

Le CERTA recommande l’utilisation du contournement FixIt proposé par l’éditeur si le navigateur n’utilise pas le mode protégé.

2 Documentation

3 Le ciblage comportemental sur Internet

3.1 Un profilage dissimulé

Si Internet est une source d’informations intarissable, il est aussi parfois montré du doigt pour son manque de respect de la vie privée. Les technologies utilisées par ce réseau sont variées et complexes. Il est donc souvent difficile pour un non-technicien de comprendre tous les flux d’information qu’il véhicule, d’autant que le sujet reste très vaste. On va s’intéresser ici plus particulièrement au profilage commercial des personnes sur le Web, appelé aussi « ciblage comportemental ».

Aujourd’hui, les habitués du Web ont globalement conscience que l’ère de la simple recherche d’information sur Internet est largement dépassée. Le présent est aux réseaux sociaux et aux contenus créés par les internautes : le Web social. Il faut savoir que les informations mises à disposition sur Internet peuvent être conservées pendant une période illimitée. Il ne sera pas question ici des réseaux professionnels, sociaux, et autres sites de rencontres, où le profilage commercial relève de l’évidence même.

L’objet de cet article porte sur des méthodes plus dissimulées de ciblage commercial. Par exemple, si vous envoyez un courriel à un ami, avec votre Webmail préféré, précisant votre envie de partir en vacances, il est tout à fait probable que lors de votre prochaine visite sur un site quelconque, des publicités pour des agences de voyage soient affichées.

3.2 Les cookies HTTP

Un cookie, ou fichier de session, est un fichier d’une taille inférieure à 4 Ko qui circule entre le navigateur et le serveur Web à chaque échange de données. Il est créé pour un nom de domaine unique, et ne peut être envoyé qu’à un serveur répondant à ce nom de domaine. Il est utilisé pour des objectifs variés : maintenir une session sur un site Web ou l’état d’un panier d’achats sur une application de commerce en ligne, observer le comportement des utilisateurs sur le site (recherches effectuées, ordre de navigation), etc.

Beaucoup de pages Web vont chercher leurs contenus à des adresses différentes. Ainsi, il est tout à fait possible que l’adresse http://site1.tld aille chercher une partie de son contenu à l’adresse http://site2.tld. Il est donc possible d’échanger des cookies avec le domaine site2.tld alors que l’adresse apparaissant dans le navigateur est http://site1.tld.

Toujours à l’adresse http://site1.tld, si la connexion vers l’adresse http://site2.tld est effectuée par une référence à un code JavaScript situé à l’adresse http://x3.y3.z3/script.js, on échangera toujours des cookies avec le domaine site2.tld mais, sans même le voir apparaître dans le code source de la page téléchargée. On ne verra que la référence au code JavaScript. Ces cookies, au domaine ne correspondant pas à l’adresse qui apparaît dans le navigateur, sont communément appelés « cookies tierce partie ».

3.3 Les méthodes de profilage par cookies HTTP

La plupart des régies publicitaires présentes sur l’Internet utilisent les cookies tierce partie. Mais comment fonctionnent-ils ? En voici un exemple : un webmestre désire gagner un peu d’argent et veut donc placer de la publicité sur son site Web. Il contacte alors une régie publicitaire, par exemple http://www.exemplefictifdepub.tld, qui lui fournit une référence vers un code JavaScript à placer sur ses pages Web. Ce code JavaScript va charger des bannières publicitaires venant d’autres domaines, et fabriquer un cookie ayant pour domaine exemplefictifdepub.tld.

De plus, le code JavaScript va activer un robot qui va lire et qualifier le contenu de la page Web. Ainsi, à chaque fois qu’un utilisateur viendra sur cette page, il recevra un cookie sauvegardant, d’une manière ou d’une autre, le type de contenu de la page.

Imaginons maintenant que la société http://www.exemplefictifdepub.tld ait pignon sur rue, et que beaucoup de sites Web de la planète utilisent ses services. Chaque internaute a donc de bonnes chances d’avoir un cookie avec pour le domaine exemplefictifdepub.tld et répertoriant l’ensemble des types de contenu qu’il est allé visiter. À chaque fois que l’internaute va sur un site qui utilise ce code JavaScript, ce cookie est mis à jour en ajoutant un nouveau contenu. Et comme ce code JavaScript est aussi celui qui va chercher les publicités à afficher, il choisit les publicités qui correspondent aux types de contenu visités. Un profil commercial de l’utilisateur est donc établi de façon tout à fait transparente, alors que l’internaute n’a fait que quelques recherches sur l’Internet.

L’exemple des Webmail de l’introduction prend ici tout son sens. Certains Webmails référencent également ce type de code JavaScript qui se charge également de qualifier les courriels de l’internaute. A chaque fois que l’internaute ouvre un de ses messages, ce dernier est automatiquement lu et qualifié par un robot. Et ce pour pouvoir lui offrir de la publicité correspondant au contenu de ses courriels.

3.4 Eviter le profilage commercial par cookie HTTP

La grande majorité de ces techniques utilisent JavaScript, la désactivation du moteur JavaScript dans le navigateur les rend de fait inefficaces. Les navigateurs modernes proposent également une option réservée aux cookies tierce partie, qui propose de les rejeter systématiquement.

Enfin, l’association NAI (http://www.networkadvertising.org) regroupant 35 régies publicitaires, dont les 10 plus importantes des États-Unis, imposent des règles de bonne conduite à ses adhérents, notamment la possibilité de refuser ces cookies publicitaires en utilisant les cookies OPT-OUT. Ces derniers rejettent l’ajout d’informations de contenu pour un domaine. De nombreux modules de navigateur Web permettent aussi l’ajout et le maintien de ces cookies sur le système de l’utilisateur. Sans oublier la possibilité de créer ces cookies OPT-OUT à l’adresse http://www.networkadvertising.org/managing/opt_out.asp. Cette page permet aussi de savoir quels cookies tierce partie sont actuellement installés sur le système.

Les techniques présentées dans la section précédente sont très répandues sur le Web. Elles ne posent pas de problèmes de sécurité immédiats, mais peuvent s’avérer gênantes pour certaines personnes et organisations. Il est donc déconseillé à une organisation qui a des besoins de sécurité et de confidentialité importants d’utiliser des sites ou Webmails forçant ce genre de pratique.

3.5 Les journaux

Le cookie n’est pas le seul mécanisme de profilage. L’immense majorité des sites ont des journaux de serveurs Web pouvant tracer un utilisateur de manière très fine, parfois plus qu’avec l’aide de cookies. À la différence des cookies tierce partie, ces journaux n’informent que le gestionnaire du site sur lequel l’internaute se connecte.

4 Mise en œuvre de DNSSEC

Depuis cette semaine le serveur DNS racine L.root-servers.net (199.7.83.42) met en œuvre la signature d’un certain nombre d’informations dans ses réponses par le biais de DNSSEC. Comme le prévoit ce protocole, le serveur géré par l’ICANN inclut donc dans ses réponses des éléments de signatures des enregistrements fournis. Ce déploiement progressif devrait se poursuivre jusqu’en juillet.

Ainsi, il est désormais possible pour les administrateurs de DNS de tester leur future configuration DNSSEC mais également de vérifier la compatibilité de leurs équipements de filtrage avec la RFC 2671 qui précise qu’il est désormais possible pour des serveurs DNS d’émettre des paquets UDP de taille supérieure à 512 octets. En effet, historiquement, si une réponse dépassait cette limite, le serveur utilisait TCP.

Désormais, ce n’est plus le cas et l’utilisation de DNSSEC engendrera quasi systématiquement des paquets de taille supérieure à 512 octets.

4.1 Recommandation

Si l’on envisage un déploiement de DNSSEC, il est indispensable de vérifier que les équipements de filtrage et routage en amont du serveur DNS sont capables de supporter et « router » des paquets UDP supérieurs à 512 octets. Le serveur L.root-servers.net est un bon moyen de tester cet état de fait.

4.2 Documentation

Rappel des avis émis

Dans la période du 25 au 31 janvier 2010, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 05 février 2010
    version initiale.