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

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 29 janvier 2010
No CERTA-2010-ACT-004

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2010-04


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

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

1 Incident de la semaine

1.1 Conficker : appliquer le correctif MS08-067 nécessaire et insuffisant

1.1.1 Faits

Cette semaine le CERTA a été contacté pour une infection récente par Conficker, ver apparu il y a plus d'un an. Le ver s'est propagé sur l'ensemble du réseau, ralentissant fortement les activités de l'entité.

Les administrateurs informatiques se sont étonnés de l'ampleur de la propagation car le correctif MS08-067 de Microsoft, corrigeant une vulnérabilité du service Server de Windows, avait été appliqué sur tous les ordinateurs du parc, postes de travail et serveurs. Ce problème est l'objet de l'avis CERTA-2008-AVI-523 du 23 octobre 2008.

En fait, le ver a évolué entre la fin 2008 et le premier trimestre 2009 et a diversifié ses modes de propagation.

Outre l'attaque exploitant la vulnérabilité mentionnée précédemment, le ver se propage :

  • par les supports amovibles dont les clefs USB, en exploitant l'exécution automatique (Autorun) activée par défaut sur les versions 2000, XP et 2003 de Microsoft Windows ;
  • par les partages réseau, en volant un jeton d'authentification ou en réalisant une attaque par dictionnaire sur la base d'une liste d'une centaine de mots de passe.

Dans l'incident, le correctif désactivant l'Autorun n'avait pas été appliqué, permettant une première infection. Ensuite, les partages réseau ont servi à la propagation rapide du ver.

1.1.2 Recommandations

Des recommandations contre le ver Conficker sont généralisables au maintien d'un niveau de sécurité minimal :

  • appliquer les correctifs de sécurité, tous les correctifs, dans un délai le plus court possible, après qualification ;
  • cloisonner le système d'information (réseau, partages, applications) et isoler très fortement les ordinateurs pour lesquels la mise à jour n'est pas possible ou différée ;
  • utiliser des mots de passe robustes mais facilement mémorisables par leurs détenteurs ;
  • utiliser au quotidien des comptes utilisateur aux droits restreints ;
  • éviter de se connecter sur un ordinateur compromis en tant qu'administrateur, local ou du domaine. Préférer la connexion en utilisateur ordinaire et la fonction runas ou Exécuter comme ;
  • surveiller les différents journaux disponibles (pare-feu, relais HTTP, serveurs, etc.) pour réagir rapidement aux anomalies ;
  • se méfier des supports amovibles.

1.1.3 Documentation

2 Qualification de vulnérabilité et liste de changements

Il y a deux semaines, était publié sur l'Internet les détails d'une vulnérabilité affectant le noyau Linux. On trouve également la preuve de faisabilité associée. En susbtance cette faille permet à un utilisateur local d'élever ses privilèges sous certaines conditions pour devenir root. Cette vulnérabilité a été prise en compte par les développeurs et corrigée à partir de la version 2.6.32.4 du noyau.

Pour obtenir un peu plus d'informations sur cette faille et sur la nature du correctif, on peut s'intéresser à la liste de changements apportés à cette version du noyau : Changelog-2.6.32.4. On cherche alors la fonction vulnérable (do_mremap()) et la correction associée. Voici ce que l'on peut lire :



À la simple lecture de ce rapport de changement , il est quasiment impossible d'évaluer si ceci correspond à une vulnérabilité et, si tel était le cas, quelle en serait la nature. Ainsi, comment être sûr que ce descriptif correspond bien à la vulnérabilité en question. Comme cela a déjà été précisé par le CERTA, il est indispensable pour un éditeur de publier des bulletins de sécurité clairs et précis concernant ses produits. Ceci aide le travail quotidien de veille des CSIRT comme le CERTA mais également celui des résponsables sécurité soucieux du niveau de mise à jour de leur parc informatique.

3 Des petites causes pour de grandes conséquences

Parfois, des éléments paraissant anodins peuvent être à l'origine de grandes problématiques. Un exemple concret nous est parvenu ces derniers temps.

Suite à une réorganisation minime, un service a dû changer de nom. Jusque là, rien de bien difficile et surtout rien qui ne concerne la sécurité informatique a priori. Seulement, si on se penche un peu sur les effets de bords d'un changement de nom, on s'aperçoit que le nom d'un service ou d'une entité est utilisé dans plusieurs mécanismes, notamment de sécurité :

  • certains noms de domaine intègrent le nom du service ou de l'entité. Il faut alors revoir toute la configuration du système de nommage, ce qui n'est pas anodin. C'est aussi le cas pour les domaines Active Directory et, par extension, pour tous les systèmes utilisant le nom du service comme identification d'un noeud ;
  • le nom d'un service intervient aussi fréquemment dans les infrastructures de gestion de clefs. Ainsi, le changement du nom d'un ou plusieurs services oblige à changer toute la branche de l'IGC. Ceci a un coût en termes de ressources humaines, mais aussi financier (achat éventuel des nouveaux certificats, changement des cartes à puces, etc.) ;
  • d'autres effets de bords peuvent être à prévoir dans des applications métier.

4 HTML5

La version 4 de HTML datant de décembre 1997 et le « Web 2.0 » commençant déja à dater, la presse spécialisée parle régulièrement du HTML5 comme étant l'avenir de la toile. Mais en réalité, de quoi s'agit-il ? Il s'agit d'un nouveau standard coécrit par les membres du WHATWG (Web Hypertext Application Technology Working Group) et du W3C HTML Working Group. Elle n'est pas attendue en version finie avant 2012 mais son implémentation et son utilisation ont déjà commencé.

4.1 Qu'est ce qui change ?

Si les principes restent globalement inchangés, cette nouvelle version du langage Web apporte son lot de renouvellement de balises. On voit, entre autres, apparaitre les balises audio et video qui devraient simplifier l'intégration du multimédia. En effet, jusque là, pour qu'une page ait un contenu multimédia, il fallait y insérer un lecteur sous forme d'appel à un module externe avec comme paramètre le contenu désiré. L'utilisation de ces nouvelles balises est similaire à celle de IMG. Qu'elle soit au format PNG, JPEG ou GIF importe peu, à charge du navigateur de l'afficher. Il en ira de même pour les balises multimédia, le navigateur devra gérer ses codecs afin de pouvoir jouer les contenus. Le choix de ces codecs est en cours de discussion. Chaque éditeur voulant mettre en avant son format, il se pose des problèmes légaux, car certains ne sont pas libres d'utilisation en fonction des pays. Ainsi, les navigateurs qui voudraient être compatibles avec le format H.264 devront acheter une licence, au risque sinon de ne pas pouvoir afficher le contenu de certaines pages. Ce nouveau langage aura aussi la particularité de respecter, contrairement à la version 4, la double syntaxe HTML et XML.

4.2 Quand pourra-t-on l'utiliser ?

Si la version finale de ce nouveau langage n'est pas attendue avant plusieurs années, HTML5 commence déja à être intégré et pris en compte dans les nouvelles versions des navigateurs. Cette semaine, par exemple, on peut lire dans la liste des changements apportés à Firefox 3.6 l'ajout de l'API File. Sur le bloc-notes francais concernant Internet Explorer, on trouve qu'IE 8 prend actuellement en compte la norme la plus répandue (CSS 2.1) et une partie du HTML5 et qu'IE 9 vise l'excellence sur HTML5 et CSS.

4.3 Où en est-on ?

Le standard et son implémentation dans les navigateurs évoluant en parallèle, il faut à la fois suivre l'actuelle version de travail disponible sur le site du W3C Working Group qui date du 25 août 2009 (cf. Documentation) et les listes de fonctionnalités et de changements apportés aux navigateurs. Il existe aussi quelques sites qui référencent les différents niveaux d'avancement de certains moteurs de rendu HTML tel que Trident, Gecko et WebKit. (cf. Documentation)

4.4 Et la sécurité ?

Les nouvelles fonctionnalités apportant toujours leur lot de bogues, leur utilisation doit être faite avec une certaine prudence. Un autre problème apparaît avec certaines nouvelles balises, telle que la video nécessitant des codecs. En effet, qui aura en charge de les maintenir à jour ? Pourra-t-on les désactiver facilement ?

4.5 En conclusion

La migration entre les différentes versions de langage va se faire petit à petit, les navigateurs tentant de rester le plus possible compatibles, et ne devrait pas poser de problème aux utilisateurs. Le CERTA recommande bien sur la mise à jour régulière des navigateurs mais aussi de se tenir informé des impacts, au niveau des risques et de la sécurité, des nouvelles fonctionnalités intégrées.

4.6 Documentation


5 Rappel des avis émis

Dans la période du 22 au 28 janvier 2010, le CERTA a émis les avis suivants :

  • CERTA-2010-AVI-025 : Multiples vulnérabilités dans Internet Explorer
  • CERTA-2010-AVI-026 : Vulnérabilités des produits SAP
  • CERTA-2010-AVI-027 : Multiples vulnérabilités dans HP Power Manager
  • CERTA-2010-AVI-028 : Multiples vulnérabilités dans gzip
  • CERTA-2010-AVI-029 : Vulnérabilité dans Cisco IOS
  • CERTA-2010-AVI-030 : Multiples vulnérabilités dans Google Chrome
  • CERTA-2010-AVI-031 : Vulnérabilité dans Citrix XenServer
  • CERTA-2010-AVI-032 : Vulnérabilité dans Apache mod_proxy

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

  • CERTA-2009-AVI-482-005 : Vulnérabilité du protocole SSL/TLS (ajout des bulletins de sécurité IBM du 22 et 27 janvier 2010)


Liste des tableaux

Gestion détaillée du document

29 janvier 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-03-23