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-2007-ACT-023

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 08 juin 2007
No CERTA-2007-ACT-023

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2007-23


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-2007-ACT-023

Gestion du document

Une gestion de version détaillée se trouve à la fin de ce 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-2007-ACT-023.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-2007-ACT-023/

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 être trompeuse. Un exécutable peut très bien se cacher derrière une extension .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 ;


6 Rappel des avis émis

Durant la période du 01 au 07 juin 2007, le CERTA a émis les avis suivants :

  • CERTA-2007-AVI-240 : Vulnérabilité dans GIMP
  • CERTA-2007-AVI-241 : Multiples vulnérabilités dans IBM AIX
  • CERTA-2007-AVI-242 : Vulnérabilité dans libpng
  • CERTA-2007-AVI-243 : Vulnérabilité des produits Nortel
  • CERTA-2007-AVI-244 : Multiples vulnérabilités des produits F-Secure
  • CERTA-2007-AVI-245 : Multiples vulnérabilités dans les produits Mozilla
  • CERTA-2007-AVI-246 : Vulnérabilité dans Novell Groupwise
  • CERTA-2007-AVI-247 : Vulnérabilité dans inetd sur Sun Solaris
  • CERTA-2007-AVI-248 : Vulnérabilités dans Symantec Veritas Storage
  • CERTA-2007-AVI-249 : Vulnérabilité dans IBM Lotus Domino
  • CERTA-2007-AVI-250 : Vulnérabilités dans Symantec Reporting Server
  • CERTA-2007-AVI-251 : Vulnérabilité dans Sun Solaris Management Console
  • CERTA-2007-AVI-252 : Multiples vulnérabilités de produits Computer Associates
  • CERTA-2007-AVI-253 : Multiples vulnérabilités du serveur CIFS de HP-UX
  • CERTA-2007-AVI-254 : Vulnérabilités de Symantec Ghost
  • CERTA-2007-AVI-255 : Multiples vulnérabilités dans la machine virtuelle Java de Sun

Pendant la même période, les avis suivants ont été mis à jour :

  • CERTA-2007-AVI-122-001 : Vulnérabilité dans MPlayer et Xine-lib

    (ajout des références aux bulletins de sécurité Gentoo, Mandrivo, SuSE)

  • CERTA-2007-AVI-138-003 : Vulnérabilité dans file

    (ajout de la référence CVE et des références aux bulletins de sécurité Gentoo, RedHat)

  • CERTA-2007-AVI-226-001 : Vulnérabilité dans FreeType

    (ajout des références aux bulletins de sécurité Gentoo, Ubuntu)


Liste des tableaux

Gestion détaillée du document

08 juin 2007
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-09-22