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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-23

Gestion du document

Référence CERTA-2007-ACT-023
Titre Bulletin d’actualité 2007-23
Date de la première version 08 juin 2007
Date de la dernière version 08 juin 2007
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 Les versions des applications sur un serveur Web

Dans un incident traité cette semaine au CERTA, la personne malintentionnée a déterminé l’application vulnérable en faisant une simple recherche sur Google. Ces attaques, qui sont très souvent opportunistes, reposent sur le fait que chaque application utilisée pour mettre en œuvre un site Web peut révéler publiquement son numéro de version. Une personne malveillante ayant accès au code d’exploitation d’une vulnérabilité affectant une version donnée d’une application effectue simplement une requête sur un moteur de recherche avec comme mots-clés l’application en question et son numéro de version. Cette technique est très fréquemment rencontrée par le CERTA.

Par exemple, pour une faille touchant phpBB 2.0.10, le pirate effectuera une recherche ‘Powered by phpBB 2.0.10’, signature de cette application. Il obtiendra immédiatement une liste de sites vulnérables. Dans le cas de serveurs Web, ce sont les requêtes provoquant des erreurs (erreur 404 par exemple) qui permettent souvent de connaître les produits utilisés et leurs versions.

Il existe des techniques beaucoup plus sophistiquées (fingerprinting ou prise d’empreinte) pour déterminer les applications et leurs versions utilisées et ainsi choisir le bon code d’exploitation. Dans le cas présent, il est recommandé, pour éviter d’être une cible qui apparaît dans les moteurs de recherche, d’anonymiser au maximum les applications utilisées sur Internet. Ces moteurs de recherche indexent le texte affiché sur le site et les adresses correspondantes, il est donc important qu’aucun texte permettant d’identifier précisément la version de l’application, voire aussi son nom, ne soit contenu dans le site. Ceci inclut les codes source (les numéros de version sont souvent en commentaire dans les codes HTML) et les pages d’erreur. Par exemple, la plupart des serveurs Web ont une page d’erreur par défaut, qu’il faut modifier.

Cependant, si de telles mesures sont nécessaires, car elles protègent de recherches de sites vulnérables à un type de faille donnée, elles ne protègent pas contre ces vulnérabilités et ne protègent pas contre les attaques lancées « en aveugle ». Il est donc toujours important de mettre à jour régulièrement ses applications et d’appliquer les autres mesures de protection habituelles.

1.2 Des outils de filoutage à disposition

Cette semaine le CERTA a rencontré des sites mettant à disposition plusieurs dizaines d’outils permettant d’installer des sites de filoutage (phishing) reproduisant frauduleusement les sites de plusieurs sociétés dont certaines françaises (ou filiales françaises de sociétés internationales) : Free, Hotmail, eBay et Paypal. N’importe quel autre site aurait pu également se trouver « copié ».

Le CERTA rappelle que l’utilisation comme la détention de tels outils est réprimée par la loi.

Le CERTA recommande aussi d’être particulièrement vigilant lors de la saisie de données personnelles et/ou confidentielles sur un site Internet. Le CERTA rappelle également d’éviter de cliquer dans un lien se trouvant dans un courrier électronique. Il est préférable de saisir le lien souhaité sois-même à la main dans son navigateur. Cet incident montre une nouvelle fois que les clients de toute société peuvent être visés par ces actions malveillantes, pas uniquement ceux des banques.

1.3 Évolution d’un site Web hébergeant des pages de filoutage : le retour

Dans son bulletin d’actualité numéro CERTA-2007-ACT-020, le CERTA indiquait l’évolution d’une compromission d’un serveur Web entraînant la mise en place de multiples sites de filoutage (phishing). Cette semaine, c’est au tour d’une banque australienne d’être victime d’un site frauduleux hébergeux sur ce même serveur. Cette évolution peut s’expliquer de plusieurs façon :

  • la faille exploitée n’a pas été corrigée : en effet bien que l’accès à un module vulnérable (ExtCalendar) ait été supprim é, les fichiers vulnérables étaient toujours présents sur le serveur ;
  • les individus malveillants ont pu revenir en utilisant un outils d éposé lors des précédentes compromissions ;
  • ce site étant mutualisé avec d’autre site web, les attaquants peuvent compromettre ce site en utilisant une faille présente sur un autre site. De la même façon, tous les autres sites mutualisés sur ce serveur sont susceptibles d’être compromis.

Cet exemple montre qu’en l’absence d’un traitement complet de l’incident, on ne peut pas comprendre la vulnérabilité à l’origine de l’attaque, ainsi que la portée de cette dernière. On s’expose donc à de multiples récidives.

Documentation

2 Retour sur les récentes vulnérabilités des navigateurs Mozilla Firefox et Microsoft Internet Explorer

2.1 Vulnérabilité IFRAME dans Firefox

Cette semaine, le CERTA a publié l’alerte CERTA-2007-ALE-012 relative aux vulnérabilités non-corrigées dans Mozilla Firefox. Deux d’entre elles ont déjà été abordées dans les bulletins d’actualité CERTA-2007-ACT-020 et CERTA-2007-ACT-022. Plusieurs autres vulnérabilités ont été rendues publiques cette semaine. En particulier, l’une d’entre elles concerne une mauvaise gestion des IFRAME (Inline HTML frames). Celles-ci sont très souvent utilisées conjointement avec la requête XMLHttpRequest afin de produire des effets dynamiques dans des pages web comme des « glisser/déposer » ou le rafraîchissement d’une partie de la page…

Dans Firefox, il est possible à une page tierce de modifier une IFRAME par l’intermédiaire de la méthode document.write(). Malgré un contrôle plus strict dans les dernières versions de Firefox, il est encore possible d’utiliser cettte méthode de façon malveillante lors du chargement de l’IFRAME que l’on veut modifier.

Dans les faits, cette vulnérabilité permet à une page malveillante de remplacer une IFRAME d’une autre page web en cours de chargement par une IFRAME disposant de fonctionnalités arbitraires comme de la capture de frappes clavier par exemple. Il est à noter qu’il existe déjà des preuves de faisabilité (proof of concept) disponibles sur l’Internet.

2.2 L’interprétation des extensions de fichiers sous Firefox

Une autre vulnérabilité importante est due au fait que Firefox ne filtre pas correctement les extensions des fichiers qui lui sont fournies via une adresse réticulaire (URL). Il est ainsi possible de modifier le comportement de Firefox vis-à-vis d’un fichier par le biais d’une extension construite de façon particulière. Cette faille permet donc à un utilisateur malveillant d’exécuter du code arbitraire à distance. Une attaque en deux temps pourrait consister en la consultation par la victime d’une page d’extension .html puis une seconde fois mais avec une URL légèrement modifiée. La deuxième consultation provoque alors l’exécution de code et non plus l’affichage d’une page web.

2.3 Vulnérabilités dans Microsoft Internet Explorer

Deux vulnérabilités affectant l’explorateur de Microsoft ont été rendues publiques cette semaine et sont actuellement sans correctif.

La première affecte les dernières versions, même à jour. Il est possible d’exécuter des scripts arbitraires provenant d’une page sur une autre page. Cela permettrait par exemple de récupérer des informations de l’utilisateur lié à cette page (fichiers de sessions, ou cookies) ou de modifier la destination des informations soumises à un formulaire, et ainsi dérober des données personnelles.

La seconde concerne uniquement la version 6 d’Internet Explorer. Il est possible pour une personne malveillante d’afficher un contenu arbitraire en remplacement de la barre d’adresse qui affiche normalement celle du site légitime. L’utilisateur pense alors naviguer sur des pages de confiance. Cette méthode pourrait être utilisée dans une attaque en filoutage : le fait de vérifier visuellement l’adresse affichée ne permettrait pas de détecter la supercherie.

Dans les deux cas, la désactivation du JavaScript rend les vulnérabilités inexploitables. Pour qu’un site reste de confiance, il ne faut pas s’y rendre depuis une source non sûre, i.e. en cliquant sur un lien dans un courrier électronique, ou sur un site tiers, etc.

3 Les documents composites

Les applications bureautiques permettent très souvent à l’utilisateur d’insérer, au sein d’un document, un autre document, qui peut être dans un format très différent. Ainsi, un fichier au format .doc de Word peut contenir des fichiers .xls produits à partir du tableur Excel, ou des transparents .ppt d’un fichier Powerpoint, etc. Sous Microsoft Office, cela peut se faire de la manière suivante :

  1. créer un nouveau document certa.doc
  2. choisir dans « Insertion » l’option « Objet »
  3. insérer l’objet voulu, en cochant éventuellement « Afficher sous forme d’icône »
Cette succession de fichiers insérés les uns dans les autres, à la manière des fameuses matriochkas ou poupées russes gigognes, peut être de n’importe quelle profondeur.

Le problème est alors assez simple : le fichier original peut être d’apparence « sain », mais contenir d’autres fichiers qui, eux, contiennent du code malveillant. Une pratique courante consiste à convertir les fichiers avant de les ouvrir. Cette approche est intéressante, et a, par exemple, fait l’objet de l’apparition d’une récente application chez Microsoft : MOICE (pour Microsoft Office Isolated Conversion Environment), qui a été présenté dans CERTA-2007-ACT-021. Il peut aussi s’agir d’une conversion dans des formats comme .pdf. L’idée sous-jacente et attendue consiste à estimer qu’un fichier construit spécifiquement pour exploiter une vulnérabilité dans un format donné deviendra inoffensif sous un autre format.

Que deviennent les documents insérés au cours de cette conversion ? Sont-ils conservés ? Modifiés ? Supprimés ? En d’autres termes, il est important de déterminer si la phase de conversion élimine ou non les risques pouvant être introduits par les documents insérés.

En effet, une personne malveillante peut profiter de cette technique pour contourner les politiques de filtrage d’extensions (pièce jointe à un courrier électronique par exemple), ou les antivirus. L’utilisateur, en revanche, a toutes les chances, s’il ouvre le premier document, d’ouvrir également ceux qui y sont insérés.

Le CERTA recommande donc les actions suivantes :

  • sensibiliser les utilisateurs à ne pas utiliser ces techniques d’insertion. Des liens relatifs peuvent remplacer l’insertion d’un document. Il faut alors échanger l’ensemble des documents.
  • vérifier que les solutions de conversion, si elles sont utilisées à des fins de sécurité, prennent en compte ce problème. En particulier, la solution MOICE actuelle ne permet pas de le faire, tandis qu’Acrobat Distiller semble ignorer ces fichiers insérés.
  • s’assurer que les filtrages mis en place, par exemple aux niveaux des messageries pour vérifier les extensions, ne sont pas vulnérables à ces insertions chaînées. Pour cela, des tests simples avec des pièces jointes peuvent être lancés.

4 Une commande Unix vulnérable

La commande Unix file permet, via une ligne de commande, d’afficher les propriétés d’un fichier, obtenues par certains tests :

test@labo:~/Desktop$ file MonFichier.pdf
MonFichier.pdf: PDF document, version 1.6
test@labo:~/Desktop$ file MonDeuxiemeFichier.odt
MonDeuxiemeFichier.odt: Zip archive data, at least v2.0 to extract
test@labo:~/Desktop$ file MonAutreFichier.txt
MonAutreFichier.text: MS-DOS executable (EXE)
Cet exemple illustre que l’extension peut parfois êtretrompeuse. Un exécutable peut très bien se cacher derrière uneextension .txt.

Le CERTA a publié cette semaine une mise à jour de l’avis CERTA-2007-AVI-138. Ce dernier évoque une vulnérabilité dan s la commande file utilisée par plusieurs systèmes d’exploitation.

La vulnérabilité, de type « débordement d’entier », peut être exploitée sous la forme d’un fichier spécialement construit qui, manipulé par file, exécutera du code arbitraire à l’insu de l’utilisateur.

Le CERTA profite de cette occasion pour signaler que le fait de ne pas utiliser régulièrement dans un terminal ce genre de commandes ne signifie pas pour autant qu’une infection de la machine de cette manière est impossible. En effet, les commandes offertes par le système d’exploitation, comme ici file peuvent très bien être utilisées par d’autres applications. C’est le cas du logiciel libre antiviral AMaViS (branche maintenue : amarisd-new) qui utilise file pour caractériser les fichiers extraits des courriers électroniques. Ce dernier a donc publié un avis de sécurité le 05 juin 2007. Des développements internes d’applications peuvent présenter les mêmes vulnérabilités.

Documentation associée

5 Les documents Microsoft Office, et la diffusion d’information

Le problème n’est pas récent, mais il semblerait qu’il reste méconnu auprès des utilisateurs de la suite bureautique Microsoft Office.

Lorsqu’un document est enregistré pour la première fois, par exemple certa.doc, il contient des données affichées à l’écran par Word. Supposons que le mot « CERTA » est ajouté dans le document.

Lorsque le document est modifié, c’est-à-dire que des données sont ajoutées, mais aussi effacées et changées, et que l’enregistrement se limite à appuyer sur Ctrl + S ou « Enregistrer », toutes les données peuvent être sauvegardées dans le corps du fichier. Dans l’exemple précédent, remplaçons « CERTA » par « CSIRT français ».

L’utilisateur pense que celles-ci n’existent plus, car elle n’apparaissent plus à l’ouverture de Word. Or il faut bien comprendre que Word interprète le fameux fichier, pour en afficher ce qu’il estime nécessaire. Visualiser le même fichier avec bloc-notes par exemple peut révéler que les informations pourtant effacées dans l’interface de saisie sont toujours présentes dans le document. Dans notre exemple, On y retrouve alors la chaîne de caractères CERTA qui avait pourtant été effacée.

Cette propriété est due à une option bien précise de Microsoft Office, qui s’appelle « les enregistrements rapides ». Lorsque celle-ci est activée, elle peut porter préjudice quand le document se diffuse, car il peut contenir des modifications, mais aussi des commentaires et d’autres informations que l’utilisateur n’a pas forcément envie de communiquer.

Pour toutes ses raisons, il est important de penser à :

  • vérifier que l’option est bien désactivée. Elle l’est par défaut sous Office 2002 et Office 2007. En revanche, ce n’est pas le cas par exemple avec Office 98 et Office 2000. Pour cela :
    • cliquer en haut de la fenêtre sur « Outils »
    • sélectionner « Options »
    • se rendre dans l’onglet « enregistrement »
    • décocher la case : « Autoriser les enregistrements rapides »
  • créer un nouveau document régulièrement, et de ne pas travailler en permanence sur les mêmes souches de fichiers ;
  • convertir les documents avant de les communiquer à d’autres personnes sous un autre format ;

Rappel des avis émis

Dans la période du 28 mai au 03 juin 2007, 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 08 juin 2007
    version initiale.