Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTA-2010-ACT-005

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 05 février 2010
No CERTA-2010-ACT-005

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2010-05


Conditions d'utilisation de ce document : http://www.certa.ssi.gouv.fr/certa/apropos.html
Dernière version de ce document : http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-005

Gestion du document

Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-005.pdf

Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-005/

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


5 Rappel des avis émis

Dans la période du 29 janvier au 04 février 2010, le CERTA a émis les avis suivants :

  • CERTA-2010-AVI-033 : Vulnérabilités dans Sun Java System Web Server
  • CERTA-2010-AVI-034 : Multiples vulnérabilités dans Cisco Unified MeetingPlace
  • CERTA-2010-AVI-035 : Multiples vulnérabilités dans Wireshark
  • CERTA-2010-AVI-036 : Vulnérabilité dans HP OpenView Storage Data Protector
  • CERTA-2010-AVI-037 : Vulnérabilité des produits Hitachi
  • CERTA-2010-AVI-038 : Vulnérabilité dans Samba
  • CERTA-2010-AVI-039 : Vulnérabilité dans IBM DataPower
  • CERTA-2010-AVI-040 : Vulnérabilité dans Symantec Altiris Notification Server
  • CERTA-2010-AVI-042 : Vulnérabilité dans Cisco Secure Desktop
  • CERTA-2010-AVI-043 : Multiples vulnérabilités dans les produits VMware
  • CERTA-2010-AVI-044 : Vulnérabilité dans BIND avec DNSSEC
  • CERTA-2010-AVI-045 : Vulnérabilités dans Squid
  • CERTA-2010-AVI-046 : Multiples vulnérabilités dans Apple iPhone OS
  • CERTA-2010-AVI-047 : Vulnérabilité dans Adobe ColdFusion
  • CERTA-2010-AVI-048 : Vulnérabilité dans Citrix XenServer
  • CERTA-2010-AVI-049 : Vulnérabilité dans OpenVMS RMS
  • CERTA-2010-AVI-050 : Vulnérabilité dans Fetchmail
  • CERTA-2010-AVI-051 : Vulnérabilité dans Asterisk
  • CERTA-2010-AVI-052 : Vulnérabilité dans Trend Micro OfficeScan
  • CERTA-2010-AVI-053 : Vulnérabilité dans Novell NetStorage
  • CERTA-2010-AVI-054 : Vulnérabilité dans Apache HTTP Server
  • CERTA-2010-AVI-055 : Vulnérabilité dans lighttpd

Durant la même période, les avis suivants ont été mis à jour :

  • CERTA-2010-AVI-041-001 : Multiples vulnérabilités dans Apache Tomcat (précision de la section Solution du document )


Liste des tableaux

Gestion détaillée du document

05 février 2010
version initiale.


CERTA
2014-01-17
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-09-22