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-030

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 30 juillet 2010
No CERTA-2010-ACT-030

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2010-30


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-030

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-030.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-030/

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.


5 Rappel des avis émis

Dans la période du 23 au 29 juillet 2010, le CERTA a émis les avis suivants :

  • CERTA-2010-AVI-335 : Vulnérabilité dans Mozilla Firefox
  • CERTA-2010-AVI-336 : Vulnérabilité dans JBoss ESB
  • CERTA-2010-AVI-337 : Vulnérabilités dans Google Chrome
  • CERTA-2010-AVI-338 : Vulnérabilités dans IBM Lotus Notes
  • CERTA-2010-AVI-339 : Multiples vulnérabilités dans les produits Symantec
  • CERTA-2010-AVI-340 : Vulnérabilité dans Nessus Web Server Plugin
  • CERTA-2010-AVI-341 : Vulnérabilité dans GnuPG
  • CERTA-2010-AVI-342 : Multiples vulnérabilités dans Apple Safari
  • CERTA-2010-AVI-343 : Vulnérabilité de Dovecot
  • CERTA-2010-AVI-344 : Multiples vulnérabilités dans SAP NetWeaver

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

  • CERTA-2009-AVI-482-009 : Vulnérabilité du protocole SSL/TLS (ajout des bulletins de sécurité HP)
  • CERTA-2010-AVI-044-001 : Vulnérabilité dans BIND avec DNSSEC (ajout de la référence au bulletin IBM)


Liste des tableaux

Gestion détaillée du document

30 juillet 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-06-22