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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2010-30

Gestion du document

Référence CERTA-2010-ACT-030
Titre Bulletin d’actualité 2010-30
Date de la première version 30 juillet 2010
Date de la dernière version 30 juillet 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 Incident de la semaine

Du JavaScript malveillant pour courriel

Dernièrement, le COSSI a constaté une augmentation du nombre de courriels incluant une iFrame pour télécharger du code JavaScript malveillant. On peut identifier au moins deux cibles pour ce type d’attaque :

  • les clients de messagerie intégrant un moteur JavaScript avec un modèle DOM associé, le modèle DOM est alors spécifique et le JavaScript malveillant cible ce modèle en particulier ;
  • les Webmails, qui eux utilisent un navigateur Web qui possède de facto un moteur JavaScript et un DOM relativement standard. La surface d’attaque est donc bien plus importante que dans le premier cas.

Le CERTA recommande la plus grande précaution lors de l’ouverture d’un message électronique. En particulier, il est conseillé de configurer son client de messagerie pour ouvrir les messages en mode texte uniquement. Dans le cas des Webmails, qui sont rarement configurables en lecture texte uniquement, une alternative est d’utiliser une extension au navigateur bloquant l’exécution de code actif.

Les bonnes pratiques liées à l’utilisation de la messagerie sont résumées dans la note d’information du CERTA suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2000-INF-002/.

2 La sécurité de WPA/WPA2 mise en péril?

Cette semaine, un chercheur en sécurité présentait, lors d’une conférence, une vulnérabilité de WPA/WPA2. Cette vulnérabilité a été annoncée comme sérieuse dans la presse. Mais, maintenant qu’elle a été dévoilée, qu’en est-il réellement?

Tout d’abord, précisons que cette vulnérabilité n’est pas basée sur une faiblesse de pilote, ou d’implémentation, mais bien sur la dernière spécification 802.11i (http://standards.ieee.org/getieee802/download/802.11-2007.pdf). Elle concerne uniquement WPA/WPA2 Entreprise, puisqu’elle n’a pas d’incidence sur WPA PSK. Elle ne peut être utilisée qu’à travers une station authentifiée et associée à un point d’accès Wifi, ce qui réduit donc grandement la surface d’attaque.

Pour mémoire, dans le cadre de WPA/WPA2 Entreprise, deux types de clés sont utilisées :

  • La PTK (Pairwise Transient Key), propre à chaque station, utilisée pour protéger le trafic entre la station et le point d’accès.
  • La GTK (Group Temporal Key), partagée entre toutes les stations, qui est utilisée pour chiffrer ce qui est envoyé sur l’adresse de broadcast, depuis le point d’accès, vers les clients.

Une station malveillante peut utiliser la connaissance de la GTK pour forger son propre paquet et l’envoyer sur l’adresse de broadcast, en se faisant passer pour le point d’accès. Ce paquet peut ainsi être utilisé, pour faire de l’empoisonnement de cache ARP, et rediriger le trafic des autres stations vers la station malveillante. Les paquets redirigés seront chiffrés, à l’aide de la PTK de la station victime, entre cette dernière et le point d’accès, puis ils seront transmis à la station malveillante, en étant, cette fois, chiffrés par sa propre PTK. Il est important de souligner que, contrairement a ce qui a pu être annoncé, les PTK des autres stations ne sont à aucun moment accessible à l’attaquant.

La redirection de paquet par une station authentifiée n’a rien de nouveau, cette technique va simplement apporter plus de discrétion puisque la station malveillante usurpe l’identité du point d’accès lors de l’envoi des messages à l’adresse de broadcast.

Face à cette vulnérabilité, plusieurs contre mesures sont proposées, comme surveiller les stations émettant des paquets sur l’adresse de broadcast, ou même mettre en place des mécanismes d’isolation entre les stations. Il est également important de bien isoler les différents réseaux Wifi selon la nature des données circulant et des personnes se connectant à ces réseaux.

Enfin, le CERTA tient à rappeler qu’il est impératif de rester prudent lors de connexion à des réseaux Wifi publiquement accessibles (lieu de restauration, aéroport, hôtels …), et des informations qu’on laissera transiter sur ces réseaux.

3 Actualité autour de DNSSEC

Cette semaine, lors d’une célèbre conférence sur la sécurité, l’ICANN (Internet Corporation for Assigned Names and Numbers) et la société Verisign ont fait l’annonce que, désormais, l’ensemble des serveurs DNS racines (root servers) pouvaient fournir des enregistrements de type DNSSEC valides. Ainsi, les informations fournies par ces serveurs racines peuvent donc maintenant êtres signées numériquement.

Certains, à tort, anticipent déjà sur le fait que cela permette de réduire un certains nombre d’actions malveillantes sur l’Internet comme le filoutage (phishing) ou les pourriels (spam) car il sera possible d’identifier le domaine de provenance d’un message de façon « sûre ». Il est clair que le fait de donner la possibilité de vérifier le contenu des zones fournies par les serveurs racines est une avancée notable méritant une communication officielle. Mais il reste tout de même du chemin avant que les différents points suivants soient réglés :

  • que chaque TLD (Top Level Domain eg. .fr, .org, .com, etc) signe ses enregistrements ;
  • que chaque domaine et sous domaine en fasse de même ;
  • que chaque logiciel faisant de la mise en cache DNS soit capable d’exploiter ses informations pour filtrer le bon grain de l’ivraie provenant de serveurs autorité ou d’autres serveurs cache ;
  • que les clients DNS ou resolver mettent en œuvre cette technologie de signature.
  • que l’ensemble des logiciels ou composants sus cités soient dans leur dernière version afin d’utiliser pleinement ces nouvelles fonctionnalités ;
  • que l’ensemble des équipements (pare-feu, routeur, mandataires, …) soit compatible avec les subtilités liées à DNSSEC (cf. CERTA-2010-ACT-005) ;
  • et enfin, que chaque utilisateur soit à même d’appréhender la différence de comportement à adopter vis-à-vis d’un domaine signer d’un autre qui ne le serait pas ;
  • etc.

Tout ceci constitue des obstacles techniques, organisationnels et humains qu’il faudra surmonter pour atteindre l’objectif que certains considèrent, un peu hâtivement, comme déjà acquis.

4 Une application Android indiscrète

Après un module additionnel malveillant pour Firefox et l’application iPhone « lampe de poche » aux fonctionnalités cachées, c’est maintenant au tour d’Android d’être visé par une application indiscrète. En effet, lors de la même conférence que dans les articles précédents, une présentation a pointé du doigt une application de fond d’écran qui envoyait les données de l’appareil (agenda, contacts, IMSI, …) vers un serveur à l’étranger. Cette application a été retirée par Google de l’ « Android Market » une fois signalée comme malveillante.

Ces trois affaires ont en commun qu’elles reposent sur la décision de l’utilisateur d’installer une application. Cette opération étant grandement simplifiée par l’utilisation de fournisseurs officiels avec des procédures automatisées et qui apportent un sentiment de confiance, l’utilisateur à tendance à faire moins attention à ce qu’il installe. Le CERTA recommande la plus grande prudence lors de l’installation de modules tiers, comme pour l’installation de tout logiciel. Une mesure de prudence est de n’installer que les programmes nécessaires et de suivre les mises à jour et publications les concernant, et, si possible, d’attendre avant d’installer une application nouvellement disponible, qu’elle soit évaluée par la communauté des utilisateurs.

Rappel des avis émis

Dans la période du 19 au 25 juillet 2010, 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 30 juillet 2010
    version initiale.