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-2009-ACT-001

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 02 janvier 2009
No CERTA-2009-ACT-001

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2009-01


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-2009-ACT-001

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-2009-ACT-001.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-2009-ACT-001/

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.


7 Rappel des avis émis

Dans la période du 26 décembre 2008 au 02 janvier 2009, le CERTA a émis les avis suivants :

  • CERTA-2008-AVI-612 : Vulnérabilités dans SPIP
  • CERTA-2008-AVI-613 : Vulnérabilité de phpPgAdmin
  • CERTA-2008-AVI-614 : Vulnérabilité du noyau FreeBSD


Liste des tableaux

Gestion détaillée du document

02 janvier 2009
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