1 MS08-067, Conficker…une histoire sans fin ?

Le CERTA a informé ses correspondants à plusieurs reprises depuis octobre 2008 de la nécessité d’appliquer le correctif du bulletin MS08-067 puis de l’existence de codes d’exploitation utilisant pour se propager la vulnérabilité corrigée.

L’un d’eux, dénommé Conficker (ou Downadup ou Kido) a été largement médiatisé du fait du nombre de machines qu’il a réussi à compromettre. Le code évolue depuis janvier 2009, en réaction à certaines contremesures mises en place par les éditeurs et des équipes de sécurité.

La version la plus récente a été détectée la première semaine de mars. Les analyses en cours de cette souche indiquent que les méthodes de détection des versions précédentes ne sont plus, pour certaines, pertinentes. Bien que cette souche ait été installée sur des postes infectés depuis début mars, certains blocs fonctionnels ne seraient activés qu’ultérieurement, dans les premiers jours d’avril.

La nouvelle version rend plus complexe, du point de vue opérationnel, les moyens de surveillance des réseaux vis-à-vis du ver. En particulier :

  • un contrôle du ver qui s’appuie sur des listes noires de noms de domaine s’avère très difficile à mettre en place. En effet, le code « pioche » chaque jour des noms parmi une liste de 50 000 aléatoires renouvelés quotidiennement ;
  • un contrôle du ver qui s’appuie sur un blocage au niveau des passerelles de navigation est difficile à mettre en place. Les précédentes versions permettaient d’identifier des requêtes Web caractéristiques. La nouvelle souche génère une requête GET vide.

En revanche, la nouvelle version dispose de plusieurs méthodes pour communiquer. L’une d’elles consiste en une forme de protocole pair-à-pair. Elle implique l’ouverture de plusieurs ports non privilégiés en UDP et TCP visibles sur la machine dans les clés de registres comme :

SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\
StandardProfile\GloballyOpenPorts\List

Ce canal de communication ne fonctionne pas correctement si les pare-feux en périphérie appliquent une politique de filtrage des connexions sortantes rigoureuse et restrictive.

2.1.2 Documentation

Liens du CERTA :

Portail de la sécurité informatique :

http://www.securite-informatique.gouv.fr
Liens complémentaires :

2 Incidents de la semaine

2.1 Un problème d’étanchéité

2.1.1 Présentation

Cette semaine le CERTA a traité un incident de sécurité relatif à la compromission d’un serveur Web mutualisant une trentaine de sites Internet. La compromission d’un simple compte utilisateur (disposant d’un mot de passe trivial) a permis aux attaquants de déposer des archives de filoutage (phishing) sur tous les sites cohébergés parmi lesquels 2 administrations françaises.

Cet incident regroupe plusieurs problèmes :

  • la sécurité des hébergements mutualisés : les restrictions d’accès des comptes utilisateurs doivent interdire toute modification en dehors du périmètre autorisé ;
  • la compromission à partir d’un accès distant : dans la mesure du possible, les accès distants doivent être filtrés ou restreints aux seules personnes autorisées ;
  • le mot de passe faible : les ordinateurs connectés à l’Internet sont régulièrement victimes de tentatives d’attaques sur les comptes et mots de passe standards ou prévisibles. Il convient donc de choisir des mots de passe dits « forts » pour réduire le succès de ces attaques.

Il s’avère, de plus, que ce serveur était loin d’être à jour en termes de correctifs de sécurité, l’hébergeur justifiant cette situation par la prochaine migration de ses clients sur une nouvelle architecture.

Le choix d’une solution de mutualisation ou de cohébergement doit faire l’objet d’une attention toute particulière quant à la sécurité mise en œuvre car dans ce contexte le niveau de sécurité effectif du serveur sera celui du site Internet cohébergé le moins sécurisé ou n’appliquant pas les correctifs de sécurité.

2.1.2 Documentation

2.2 Utilisation d’un script par un cheval de Troie

Le CERTA a été informé cette semaine d’un incident peu courant. Le site Web d’une administration hébergeait un script (légitime) qui permettait d’envoyer des messages électroniques. Ce script n’ayant pas de protection particulière, il était accessible à tout internaute et permettait, entre autres, de relayer des courriels non désirés.

Dans le cadre de cet incident, ce script a été utilisé à une tout autre fin. En effet, un cheval de Troie destiné à obtenir frauduleusement des données de connexions saisies au clavier (par le biais d’un keylogger) utilisait ce site Web pour l’envoi des informations ainsi obtenues.

Les journaux d’accès au serveur Web ainsi que ceux de la messagerie étaient chargés par les accès des machines infectées. En cas de propagation importante de ce cheval de Troie, cela peut se traduire par un déni de service. La lecture de ces journaux permet néanmoins de détecter les machines ainsi infectées.

3 Deux nouvelles alertes

Cette semaine le CERTA a publié deux nouvelles alertes, la première relative à une vulnérabilité dans Apple Mac OS X et la seconde à une vulnérabilité dans Mozilla Firefox.

3.1 Vulnérabilité dans Mac OS X

Une vulnérabilité non corrigée dans Mac OS X permet à une personne malintentionnée d’élever ses privilèges sur la machine cible. Cette vulnérabilité affecte un appel système lié au format de système de fichiers HFS+. Des codes d’exploitation sont déjà disponibles sur l’Internet.

Le CERTA recommande donc de rester prudent dans l’exécution de fichiers provenant d’une source non sûre afin de limiter les possibilités d’installation d’un code malveillant.

A titre d’exemple, cette semaine un éditeur d’antivirus a détecté la nouvelle variante OSX/RSPlug-F d’un cheval de Troie. Ce code malveillant repose sur les mêmes méthodes que DNSChanger. La propagation de ce code se fait sous la forme d’un faux programme HDTV/DTV nommé MacCinema.

3.2 Vulnérabilité dans Mozilla Firefox

L’alerte CERTA-2009-ALE-004 publiée aujourd’hui fait état d’une vulnérabilité non corrigée dans le navigateur Mozilla Firefox. Une personne malveillante peut exécuter du code arbitraire à distance via une erreur dans l’interprétation des fichiers au format XSL. Des preuves de faisabilité sont disponibles sur l’Internet et un correctif est en cours d’élaboration. Ce dernier doit être fourni dans la prochaine version 3.0.8 du navigateur le 01 avril 2009.

Dans l’attente de correctif, le CERTA recommande d’utiliser un navigateur alternatif et d’appliquer les bonnes pratiques suivantes pour limiter les risques :

  • désactiver l’interprétation du JavaScript ;
  • naviguer avec un compte utilisateur aux droits limités.

3.3 Documentation

4 Noyau Linux 2.6.29 et nouvelles fonctionnalités

4.1 Détails

La dernière version du noyau Linux a été publiée cette semaine apportant son lot de nouveautés et de corrections de bogues. Pour ce deuxième aspect, le CERTA reviendra dans un article ultérieur sur la politique à adopter en la matière. En ce qui concerne les nouvelles fonctionnalités apportées par cette version, on pourra s’attarder sur deux d’entre elles en particulier :

  1. le kernel modesetting ;
  2. un nouveau format de système de fichiers, le btrfs.

Le premier cas (le kernel modesetting) concerne une fonctionnalité fort intéressante qui consiste à mettre en œuvre le changement de mode de la carte graphique dans le noyau et non plus à la fois en espace noyau et en espace utilisateur comme c’est le cas actuellement. Le mode d’une carte graphique définit ce qu’elle est capable d’afficher en matière de résolution : largeur, hauteur, nombre de couleurs possibles, …

Ainsi, lorsque l’on « passe » du serveur X à une console par l’appui simultané de Crtl+Alt+F1 par exemple, on change le mode de la carte graphique. Or, cette opération est complexe : on passe d’un pilote de serveur X en espace utilisateur à un pilote de type « framebuffer » géré par le noyau. Chaque passage de l’un à l’autre nécessite une réinitialisation de la carte graphique. Ceci n’est pas sans conséquence sur la stabilité et la robustesse du système, en particulier lorsque le pilote du serveur X pour des raisons de performance est couplé à un pilote noyau mettant en œuvre du DRI (Direct Rendering Interface).

Un apport majeur de cette délégation au noyau est donc d’éviter cette réinitialisation. En termes de sécurité, cela apporte également la possibilité de faire fonctionner un serveur X sans les privilèges de l’administrateur autrefois nécessaires à certains pilotes (drivers) qui devaient disposer d’un accès direct à la mémoire de la carte vidéo. Dorénavant, tout est géré en espace noyau.

Cette fonctionnalité, bien qu’intéressante, manque encore de son « pendant » en mode utilisateur car il faudra adapter certains pilotes et certaines applications du serveur X pour s’interfacer correctement avec ce nouveau mode de fonctionnement.

Le deuxième cas est le système de fichiers btrfs dont la vocation est de « concurrencer » les systèmes de fichiers comme ZFS de Sun ou Hammer de DragonFlyBSD. Il apporterait donc le même type de fonctionnalités attendues pour des systèmes de fichiers modernes utilisés sur des serveurs. Cependant, selon l’avis même des développeurs, ce système de fichiers n’est qu’en phase d’évaluation et reste expérimental.

4.2 Recommandations

Dans les deux cas présentés précédemment, les nouvelles fonctionnalités de cette version du noyau Linux apportent un gain en robustesse ou en sécurité. Cependant, il faut bien garder à l’esprit que, comme toute nouvelle fonctionnalité, elle n’a pas encore été éprouvée et peut même encore être considérée comme expérimentale. Il conviendra donc de rester prudent et de ne pas céder à l’attrait de la nouveauté, en particulier dans un environnement de production.

5 Mises à jour Adobe

Le CERTA a précisé dans son précédent bulletin d’actualité l’existence de correctifs fournis par Adobe pour la vulnérabilité concernant les objets encodés en JBIG2 (alerte CERTA-2009-ALE-001). Adobe a également fourni des correctifs pour les versions de ses applications Adobe Reader et Acrobat sous Mac OS, Linux et Solaris. La mise à jour du bulletin de l’éditeur APSB09-04 précise que l’exploitation de cette vulnérabilité peut également conduire sous ces systèmes d’exploitation à l’exécution de commandes arbitraires. La mise à jour Adobe corrige les vulnérabilités référencées suivantes : CVE-2008-2549, CVE-2009-4813, CVE-2009-4814, CVE-2009-0193, CVE-2009-0658, CVE-2009-0927, CVE-2009-0928, CVE-2009-1061, CVE-2009-1062.

Plusieurs codes d’exploitation circulent actuellement sur l’Internet. Le CERTA en profite donc une nouvelle fois pour rappeler l’impérative nécessité de mettre à jour ses applications Adobe.

Documentation

6 Mise à jour de la note d’information CERTA-2000-INF-002

La note d’information CERTA-2000-INF-002 traite des mesures de prévention relatives à la messagerie. La mise à jour de cette note actualise, par exemple, les captures d’écran pour la configuration des clients de messagerie dans leurs dernières versions et permet de lire et envoyer ses messages électroniques au format texte ou d’extraire les en-têtes des messages reçus.

Documentation

Rappel des avis émis

Dans la période du 16 au 22 mars 2009, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :