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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-11

Gestion du document

Référence CERTA-2009-ACT-011
Titre Bulletin d’actualité 2009-11
Date de la première version 13 mars 2009
Date de la dernière version 13 mars 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 traités cette semaine

1.1 Vulnérabilités PDF et exploitations

Le CERTA a traité cette semaine des incidents avec une méthode de compromission présentant plusieurs points communs :

  • quelques utilisateurs ont été destinataires de courriels usurpant une adresse légitime ;
  • les courriels contenaient plusieurs pièces jointes, la majorité au format PDF.

Les fichiers PDF analysés exploitent deux types de vulnérabilités :

  • celles associées à la fonction Adobe JavaScript Collab.CollectEmailInfo() corrigée en 2008 et mentionnées dans le bulletin d’actualité CERTA-2008-ACT-020 ;
  • la vulnérabilité récente touchant l’interprétation des flux encodés en JBIG2 dans un fichier PDF et faisant l’objet de l’alerte CERTA-2009-ALE-001.

Ces incidents sont assez représentatifs de la problématique de ces vulnérabilités : les antivirus ont beaucoup de difficultés à les détecter. Il est donc très important de prendre plusieurs mesures préventives dont :

  • désactiver l’interprétation de JavaScript dans Adobe par défaut ;
  • mettre à jour les applications dès que les correctifs sont disponibles ;
  • être très circonspect lors de la réception soit d’un courriel provenant d’un expéditeur mal connu, soit d’un courriel inattendu d’un expéditeur connu. Dans ce dernier cas, l’analyse de l’en-tête peut s’avérer utile.

L’alerte CERTA-2009-ALE-001 mentionne plusieurs contournements provisoires ainsi que l’avancement des publications de correctifs par Adobe selon les versions des logiciels.

1.2 Un site à l’abandon

1.2.1 Présentation

Cette semaine le CERTA a informé le propriétaire d’un site Web de la compromission de ce dernier. En effet des attaquants avaient réussi à contourner les mesures de sécurité du site afin d’y déposer des fichiers malveillants. L’administrateur du serveur a informé le CERTA que ce site n’était plus utilisé depuis plusieurs mois et que suite à l’information du CERTA, le site serait totalement supprimé car inutile.

Les sites abandonnés comme celui-ci posent plusieurs problèmes :

  • les correctifs de sécurité ne sont plus appliqués ;
  • personne ne suit les journaux des connexions afin de découvrir une tentative d’attaque ou une attaque réussie ;
  • les contacts mentionnés sur le site ne sont plus valides ;
  • une attaque avérée ne sera pas détectée et traitée immédiatement.

Dans le cas d’un site ou de pages Web devenus inutiles, le CERTA recommande de supprimer toutes les applications et pages (exemple : CMS et autres composants) potentiellement vulnérables et de prévenir, éventuellement, les internautes de cette disparition au moyen d’un page statique.

1.2.2 Documentation

1.3 Comportements étranges…

Cette semaine, le CERTA a traité un incident concernant plusieurs compromissions dans une administration. Comme bien souvent, ces compromissions ont été facilitées par l’utilisation d’un logiciel non mis à jour.

Les postes étaient infectés par un enregistreur de frappes clavier (ou keylogger) qui envoyait ces informations sur un serveur distant. Le code malveillant a pu être repéré par l’impossibilité pour les utilisateurs d’effectuer certaines combinaisons de touches, notamment les accents circonflexes et les trémas. Cette propriété est assez courante pour un enregistreur de frappes.

S’il ne faut évidemment pas se reposer sur ce genre de symptôme pour détecter la présence de codes malveillants, le CERTA rappelle que tout comportement suspect d’une machine (problèmes de touches, messages d’erreur, utilisation anormale du CPU, etc. ) doit être remonté à son administrateur réseau qui pourra alors investiguer le problème.

Ce sont souvent des comportements bizarres qui permettent de mettre en évidence un incident. Ils ne doivent pas être sous-estimés.

2 La mise à jour qui dérape

Cette semaine un éditeur d’antivirus a publié une mise à jour qui, suite à une erreur humaine, n’a pas été signée. Cette absence de signature a provoqué des alertes au sein même des logiciels de l’éditeur. Les utilisateurs ont observé des demandes d’autorisation d’accès à l’Internet d’un fichier exécutable. Ce fichier, légitime et appartenant aux applications de l’éditeur, a ainsi provoqué une certaine panique chez certains des utilisateurs mais aussi une euphorie chez certaines personnes malveillantes.

Les premiers ont cherché sur l’Internet des solutions afin de déterminer l’origine et la dangerosité du fichier exécutable et les seconds ont tenté de conduire les premiers sur de fausses solutions antivirales ou sites malveillants en tout genre.

L’éditeur affirme que cette mise à jour n’est été diffusée que pendant un court délai et que peu de personnes ont été touchées. Cet incident permet néanmoins de tirer quelques enseignements :

  • la capacité de réaction des attaquants est très grande dès qu’il s’agit de leurrer les utilisateurs. Ils ont réussi à monter en quelques heures des sites malveillants permettant, via une bonne indexation de certains moteurs de recherche, de pousser des personnes à installer des logiciels à l’origine douteuse contenant des chevaux de Troie ;
  • une mesure de sécurité qui n’est pas correctement respectée peut aboutir à une compromission. Les mises à jour doivent être récupérées sur les sites officiels avec toutes les garanties d’authentification et d’intégrité. En cas de doute ou d’anomalie détectée, il convient de s’informer directement auprès de l’éditeur.

3 Interfaces actives et réseaux ouverts

Devant le nombre croissant de supports publicitaires utilisant la technologie Bluetooth pour intéragir avec les utilisateurs, le CERTA tient à rappeler les risques inhérents à cette technologie.

La note d’information CERTA-2007-INF-003 recommande aux utilisateurs de désactiver leurs interfaces réseau Bluetooth lorsque celui-ci n’est pas indispensable. De plus, il est fortement recommandé de ne pas procéder à un jumelage d’appareils dans un environnement non sûr. Cette même note d’information recense également les risques spécifiques liés à l’utilisation de technologie, sans oublier les risques affectant plus généralement les réseaux sans-fil.

De manière générale, les supports publicitaires imposent une configuration très laxiste de l’équipement pour pouvoir communiquer les informations. La portée n’est pas un argument suffisant, comme il a été souligné dans l’article « Portée et Bluetooth » du bulletin d’actualité CERTA-2008-ACT-017. La portée ne dépend pas que de la puissance du signal d’émission. Des antennes externes branchées sur des cartes peuvent, par exemple, considérablement augmenter la qualité de réception.

4 Le système de fichiers ext4

4.1 Présentation

La nouvelle version du système de fichiers Extended Filesystem 4 est désormais considérée comme stable et n’est plus estampillée expérimentale dans le noyau Linux depuis sa version 2.6.28.

Hormis des capacités revues à la hausse en terme de taille maximale de fichier ou de partitions, ce système de fichiers apporte son lot de nouveautés dont certaines peuvent présenter un intérêt non négligeable pour la sécurité :

  • un mécanisme de récupération de fichiers (undelete) intégré. Ce mécanisme n’est pas mis en oeuvre pour le moment mais le format du système de fichier peut le supporter nativement ;
  • des informations supplémentaires apparaissent dans le contenu des inœuds (inodes) comme la date de suppressions d’un fichier ou une granularité de temps descendue à la nanoseconde (milliseconde auparavant).

Ces deux fonctionnalités sont assez prometteuses surtout dans un contexte d’autopsie suite à un incident. Il existe, par ailleurs, une certaine compatibilité ascendante entre ext4 et ext3 et des outils standards de migration vers ext4. Cependant, certaines nouvelles fonctionnalités introduites dans le nouveau format ne permettent pas d’avoir le même niveau de compatibilité que l’on a entre ext2 et ext3.

Par exemple, un des changements majeurs est le mécanisme d’allocation par extents1 « casse » le mécanisme d’allocation traditionnelle s’appuyant par des blocs d’adresses indirectes ou doublement indirectes.

Ainsi lorsque l’on convertira un système de fichiers ext3 en ext4, l’actuelle partie allouée du système restera de type ext3 et les nouveaux fichiers créés le seront « à la mode » ext4 par extents. Dans ce cas, on ne pourra plus monter le système ext4 en ext3 car le format ext3 ignore totalement la logique d’extents. Ceci peut être crucial lors d’une récupération d’un système endommagé avec un outil ne supportant que l’ext3 au maximum.

4.2 Recommandations

Bien que le système ext4 semble très prometteur tant en terme de performances que de fonctionnalités offertes et dans la mesure où toutes les distributions GNU/Linux ne le proposent pas nativement, il reste préférable d’attendre un support et une intégration plus accrus dans les distributions avant d’envisager une migration de ses sytèmes de fichiers ext3 vers ce nouveau format. Il n’en reste pas moins que certaines des fonctionnalités offertes seront assez appréciables dans un contexte de traitement d’incident.

Rappel des avis émis

Dans la période du 02 au 08 mars 2009, 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 13 mars 2009
    version initiale.