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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-01

Gestion du document

Référence CERTA-2009-ACT-001
Titre Bulletin d’actualité 2009-01
Date de la première version 02 janvier 2009
Date de la dernière version 02 janvier 2009
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 Incidents de la semaine

1.1 Un ancien traitement peu rigoureux

Cette semaine le CERTA a participé au traitement d’un incident relatif au dépôt d’un kit de filoutage (phishing) sur un site Internet. A la suite de l’information de la compromission, le responsable du site en question a pris contact avec son administrateur technique pour analyser le problème. Cette analyse a révélé que les troubles venaient d’une compromission antérieure qui n’avait pas fait l’objet d’un traitement rigoureux. En effet, seules les conséquences de la précédente compromission avaient été corrigées. Les attaquants n’ont donc eu aucune difficulté à revenir modifier ce site Web.

Lors d’une compromission, les conséquences et autres traces laissées par l’attaquant ne sont que la partie visible de l’iceberg. Avant de remettre un service en production, il est préférable de s’assurer que la vulnérabilité exploitée a été correctement corrigée. Le CERTA rappelle que suite à une compromission, d’autant plus quand la cause n’a pas été clairement identifiée, il est indispensable de réaliser un audit de sécurité. Il est par exemple parfaitement inefficace de changer les mots de passe si une porte dérobée est présente. Les bons réflexes, suite à un incident, sont détaillés dans la note d’information du CERTA CERTA-2002-INF-002.

Documentation

1.2 Un hébergement tout en un

Les causes de la compromission d’un site Web peuvent être multiples :

  • une vulnérabilité dans le code ou l’application utilisée ;
  • une compromission d’un serveur ;
  • une compromission des identifiants utilisés pour ce connecter au serveur ;
  • …

Le CERTA a reçu l’appel d’une victime suite à la compromission de son site Internet. Son hébergeur lui a suggéré de modifier son mot de passe de connexion, le site de la victime ne contenant qu’une page PHP ne faisant appel à aucune directive « sensible » de ce langage. Peu de temps après cette modification, son site a de nouveau été modifié à son insu. L’hébergeur a alors pris la décision de suspendre le compte de la victime le temps de trouver la cause de la compromission. Or, la suspension de compte chez cet hébergeur entraine l’arrêt de tous les services associés : Web, messagerie, DNS. La réaction de l’hébergeur peut se comprendre, mais la victime ne peut à présent plus recevoir de courrier électronique, ce qui pourrait mettre en péril l’existence de sa société.

Le CERTA rappelle que le choix d’une solution d’hébergement doit intégrer les possibilités de réaction face à l’incident : service d’analyse, passage en mode dégradé, …

Documentation

2 Les faiblesses dans MD5 exploitées

Le 30 décembre 2008, à Berlin, a eu lieu la vingt-cinquième conférence en sécurité informatique du CCC (Choas Computing Congress). Lors de cette conférence, une présentation a fait grand bruit. En effet, au cours de cette présentation, une équipe de chercheurs a annoncé avoir exploité les faiblesses de l’algorithme MD5 découvertes depuis 2004 afin de créer de faux certificats totalement valides et acceptés automatiquement par les navigateurs usuels.

2.1 Qu’est-ce que MD5 ?

L’algorithme MD5 (Message Digest 5) est une fonction mathématique dite fonction de hachage (hash fonction). À partir d’un bloc de données initial, cette fonction permet d’obtenir un nouveau bloc de données unique de 128 bits. Cette empreinte, ou hash, est censée respecter les propriétés suivantes :

  • il est très difficile de retrouver le message initial à partir de la signature ;
  • à partir d’un message donné, et de sa signature, il est très difficile d’engendrer un autre message qui donne la même signature ;
  • il est très difficile de trouver deux messages aléatoires qui donnent la même signature (résistance aux collisions).

C’est cette résistance aux collisions qui a été mise à mal théoriquement en 2004 pour l’algorithme MD5. Depuis longtemps, MD5 est considéré comme non sûr et n’est pas recommandé par la DCSSI.

2.2 Utilisation de MD5 dans les certificats

Si l’on simplifie la vision des choses, un certificat est un fichier constitué d’ensembles de données, complétés de la signature de celles-ci qui permet de les certifier par une autorité de confiance. La signature des données d’un certificat est réalisée en appliquant une fonction de hachage au bloc de données que l’on veut signer, puis en chiffrant l’empreinte obtenue avec la clef privée de l’autorité de certification.

Malgré la faiblesse avérée de MD5, beaucoup de certificats utilisent malheureusement encore cet algorithme dans leur processus de signature. D’après les auteurs de l’article présenté au 25C3, sur 30000 certificats collectés, 9000 utiliseraient MD5 comme algorithme de hachage.

2.3 Impact de l’attaque

Grâce à leur attaque, les auteurs sont capable de créer un faux certificat signé indirectement par une autorité de certification valide et reconnue par tous les navigateurs.

Il est donc possible entre autres :

  • de faire croire qu’une autorité de certification reconnue a délivré un certificat à un site malveillant ;
  • d’agir en coupure d’une connexion à un site de confiance en imitant son certificat (attaque de type man in the middle).

2.4 Comment se prémunir de ces impacts ?

Lors de la création d’un certificat, il convient de choisir un algorithme réputé comme fiable. Par exemple, il est recommandé, dans le référentiel général de sécurité (RGS), d’utiliser l’algorithme SHA-256.

Si l’on se place du côté de l’utilisateur, il convient de vérifier les certificats proposés par le site Internet au cours d’une transaction particulièrement sensible (transfert d’argent, connexion par identifiants, données personnelles, etc.).

Si le certificat annoncé utilise l’algorithme MD5, l’utilisateur pourrait être en présence d’un certificat faible ou faux.

Documentation

3 Les cadeaux de Noël sur le réseau

Cette période de l’année qui suit Noël est souvent propice à l’apparition de gadgets sur le réseau. Ce fut déjà le cas il y a quelques années avec le célèbre Nabaztag.

Ce phénomène pose néanmoins un problème de sécurité. En effet, ces dispositifs sont des systèmes informatiques et devraient donc respecter la politique de sécurité du système d’information (PSSI). Leurs utilisateurs ne sont généralement pas conscients qu’il s’agit de véritables systèmes d’information et qu’ils comportent les mêmes risques qu’un ordinateur ou qu’une clé USB.

Pour prendre un exemple récent, la société Samsung a récemment indiqué que des CD d’installation du logiciel Frame Manager fourni avec des cadres photos étaient infectés par un code malveillant. La connexion de ce matériel à un ordinateur est donc susceptible d’infecter cette machine, puis le réseau local.

Un incident similaire avait affecté les cadres photos Insignia du producteur Best Buy. Les incidents de ce type sont amenés à se répéter.

Il est donc important, avant de connecter un tel dispositif (matériel et logiciel) sur le réseau, de s’assurer que celui-ci :

  • respecte la politique de sécurité ;
  • n’est pas déjà infecté par un code malveillant.

Une sensibilisation des utilisateurs est également nécessaire, surtout en cette période où de nombreux cadeaux de Noël (potentiellement infectés) sont remis en vente sur des sites spécialisés.

Documentation

4 Téléphones portables

Une conférence récente a permis de rappeler à certains utilisateurs de téléphones portables que ces derniers restent des systèmes d’information comme des ordinateurs avec des vulnérabilités potentielles.

Plus précisément, des chercheurs ont montré qu’il était possible de perturber la réception totale des messages de type SMS ou MMS de certains téléphones mobiles Nokia.

L’attaque en elle-même n’est pas excessivement complexe car elle consiste à envoyer des messages spécifiquement construits à la cible. Ces derniers sont mal interprétés par l’équipement et perturbent le fonctionnement du service de réception.

Le dysfonctionnement n’est pas toujours visible.

Cet événement permet de rappeler que les téléphones sont des appareils communiquants dont les fonctionnalités sont quasi aussi riches que celles des ordinateurs actuels. Les moyens de protection ne sont cependant pas encore très évidents et, compte-tenu de l’hétérogénéité du parc, dépendent très souvent de la version précise du modèle utilisé.

Le CERTA recommande donc la plus grande vigilance quant à leur utilisation et rappelle de ne pas mélanger les usages privés et professionnels. La politique de sécurité doit prendre en compte leur usage. Leur niveau de sécurité est-il suffisant pour manipuler des données professionnelles ? Peuvent-ils être branchés sur tout équipement du réseau ? etc.

5 Note d’information

Cette semaine le CERTA a publié une note d’information CERTA-2008-INF-005 relative à la gestion des journaux d’événements. Ce document a pour but d’aider à la mise en œuvre d’une politique complète de journalisation. Il y est précisé :

  • les préalables à la mise en place d’une infrastructure complète de gestions de journaux ;
  • les bonnes pratiques en matière d’architecture de centralisation ;
  • la nature des éléments à journaliser ;
  • un certain nombre de conseils lors de l’exploitation des journaux pouvant aider dans la détection d’incidents de sécurité.

Documentation

6 Vulnérabilités dans SPIP

De très nombreux sites Internet sont construits avec un logiciel dénommé SPIP. Un correctif très important vient d’être diffusé afin de corriger plusieurs failles, décrites dans l’avis CERTA-2008-AVI-612, qui affectent ce gestionnaire de contenu. L’une de ces vulnérabilités permet d’exécuter du code à distance. Afin d’éviter de multiples défigurations de sites Internet via cette faille facilement exploitable, il est recommandé de faire appliquer le correctif.

Rappel des avis émis

Dans la période du 22 au 28 décembre 2008, 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 02 janvier 2009
    version initiale.