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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2010-04

Gestion du document

Référence CERTA-2010-ACT-004
Titre Bulletin d’actualité 2010-04
Date de la première version 29 janvier 2010
Date de la dernière version 29 janvier 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

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

Rappel des avis émis

Dans la période du 18 au 24 janvier 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 29 janvier 2010
    version initiale.