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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-26

Gestion du document

Référence CERTA-2007-ACT-026
Titre Bulletin d’actualité 2007-26
Date de la première version 29 juin 2007
Date de la dernière version 29 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 Attaques contre EVA-WEB

Depuis le début de la semaine, de nombreuses attaques ciblant l’applicatif EVA-WEB ont eu lieu. Ces attaques exploitent une vulnérabilité de type php include rendue publique et corrigée en janvier 2007. Elles laissent des traces très significatives dans les journaux visibles en effectuant des recherches du type :

egrep ‘(aide|perso).http’ access_log

Le CERTA recommande l’application du correctif de sécurité disponible à l’adresse suivante :

http://www.spip-edu.edres74.net/article.php3?id_article=210

Le CERTA invite également les administrateurs de sites utilisant EVA-WEB à rechercher dans leurs journaux d’éventuelles attaques à l’aide de la commande indiquée précédemment.

2 Sage comme une image ?

Une manière de cacher du code consiste à le dissimuler dans un fichier d’image dont la spécification du format est laxiste.

En effet, une propriété de certains formats de fichiers permet à des images GIF, JPG ou BMP par exemple d’être également des scripts PHP fonctionnels.

Cette propriété est par exemple représentée par les commentaires de texte insérés dans le fichier image, interprétables par PHP qui y retrouve les balises attendues.

Il peut s’agir d’une image GIF par exemple.

certa@labo:~$ file MonImage.gif
monImage.gif: GIF image data, version 89a, 50 x 80

Cette image pourra être visualisée par tout outil de dessin. Mais elle pourra également être interprétée directement dans un script PHP. Des preuves de faisabilité intégrant du code comme phpinfo() ou alert(0); ont été rapidement publiées. Par exemple, la page HTML suivante affichera une alerte :

certa@labo:~$ cat page.html
<_img src=MonImage.gif></_img>
<!– affiche l’image dans le navigateur –>
<_script src=MonImage.gif></_script>
<!– ex�cute l’alerte incluse dans le fichier –>

Les motivations qui peuvent pousser à utiliser de telles images peuvent être :

  • certaines applications de téléchargement, notamment écrites en PHP, filtrent et vérifient uniquement le type MIME indiqué. Les images sont rarement refusées. Rien n’empêche, cependant, une personne malveillante de modifier l’en-tête de sa requête, et d’y insérer une image particulière en ajoutant le paramètre Content-Type: image/gif. Le type MIME n’est pas représentatif du contenu du fichier. C’est donc une façon incidieuse d’introduire un script.
  • D’autres tests pour vérifier qu’il s’agit d’une image consistent à vérifier sa taille par la commande dédiée getimagesize() sous PHP. D’autres encore vérifient simplement l’extension. Dans tous les cas, ces politiques de filtrage ne sont clairement pas suffisantes pour éviter l’exécution de tels fichiers.
  • les extensions de fichiers passées à l’interpréteur PHP dépendent souvent de la configuration du serveur Web. Or cette configuration est souvent méconnue des développeurs et mainteneurs de sites.

Une page insérée sur un site et contenant de telles images peut donc passer inaperçue. Un rapide survol du code source des pages par l’administrateur ne permettra pas de visualiser le code injecté.

Les sites hébergeant de telles images peuvent également servir de relais pour exécuter indirectement du code. Par exemple, si l’image MonImage.gif est placée sur SiteA :

  • SiteA peut être un hébergeur d’images, ce service étant proposé sur plusieurs sites directement ;
  • SiteA a une faille d’inclusion dans son code ayant permis l’insertion illégitime de l’image ;
  • SiteA autorise le téléchargement de fichiers, ou des commandes de type PUT, ou php_include() ;
La personne malveillante peut inciter un utilisateur à cliquer sur le lien : 
http://SiteA.addresse/images/MonImage.gif?les_commandes_malveillantes
Le code malveillant sera exécuté à partir du script hébergépar SiteA.

2.1 Recommandations du CERTA

Le CERTA recommande donc fortement aux administrateurs :

  • de bien vérifier au cours d’un téléchargement la nature de l’image, en la renommant, ou mieux, en la convertissant par exemple ;
  • d’avoir une politique de nommage cohérente des images ;
  • de vérifier régulièrement l’intégrité des répertoires et des fichiers du site sur le serveur Web ;
  • de regarder avec attention les journaux du serveur Web, afin de détecter toute requête anormale (GET MonImage.gif?variable=).

Le CERTA rappelle enfin aux utilisateurs de désactiver le JavaScript par défaut, et de ne l’utiliser que sur des sites de confiance, quand cela est nécessaire ;

3 De nouveaux formats pour les applications bureautiques

Le CERTA a publié dans son bulletin d’actualité CERTA-2007-ACT-024 une mise en garde contre les informations qui peuvent se dissimuler dans les documents bureautiques Office. Les données visibles par le biais de l’application ne sont pas nécessairement celles présentes dans le fichier. D’autres peuvent subsister.

Depuis 2006, de nouveaux formats, dits « ouverts » ont fait leur apparition. Parmi ceux-ci, deux se distinguent actuellement :

  • OpenDocument : sa version 1 est actuellement proposée par les suites Open Office version 2, Sun Star Office, Koffice, Neo Office ou Abiword. Il est standardisé sous l’ISO/IEC 26300:2006 et les extensions des fichiers associées sont notamment .odt, .ods, .odp, .odg ;
  • Open XML : ce standard ECMA-376 est utilisé essentiellement dans la suite Microsoft Office 2007. Les extensions associées les plus courantes sont .docx, .xlsx, .pptx, .accdb, ou alors .docm, .xlsm ou .pptm s’ils contiennent des macros ;

La compatibilité entre ces deux formats est plus ou moins assurée par des outils tiers ou offerts par les différentes applications, mais ils gardent chacun des caractéristiques propres. Hormis le fait qu’un document est en réalité un fichier compressé ZIP contenant différents fichiers XML, voici les structures classiques de chacun d’eux :

  1. une fois décompressé, un fichier Open XML peut contenir :
    • [Content_Types].xml qui décrit les fichiers de l’archive ;
    • word/styles.xml qui contiennent les styles du document ;
    • word/settings.xml qui donnent certains paramètres pour le document ;
    • les fichiers .rel dans le répertoire _rels qui indiquent les relations entre les différents fichiers XML composant le document ;
    • un répertoire embeddings qui peut contenir les fichiers imbriqués dans le document ;
    • un répertoire media qui regroupent les différentes images, sons et autres fichiers annexes.
  2. une fois décompressé, un fichier OpenDocument peut contenir :
    • content.xml qui est le corps du document ;
    • styles.xml qui donne la description du style du document ;
    • meta.xml qui produit les méta-données du document, comme le nom de l’auteur ou le titre ;
    • settings.xml qui fournit les paramètres globaux du document ;
    • META-INF/manifest.xml qui décrit les fichiers de l’archive ;
    • les images ou objets éventuels.

Malgré l’apparente clarté de ces deux formats, il y a quelques problématiques à prendre en compte avant de déployer et utiliser de tels formats :

  • la gestion des « macros » n’est pas simple. Les deux formats prennent en compte différents langages comme Basic, Javascript, Java ou Python. Dans OpenDocument, leur exécution peut être liée à des événements, comme l’ouverture ou la fermeture du document, et elles ne sont pas signées avec le reste du document.
  • les objets OLE lient très étroitement l’application de bureautique à la version du système d’exploitation Windows. Leur format propre n’est pas forcément « ouvert » (OLE2) ;
  • les scripts ne sont pas directement interprétés, mais peuvent l’être suite à une conversion particulière ;
  • les macros peuvent être ou non signalées, en fonction des documents imbriqués. De manière générale, les imbrications de documents peuvent toujours être trompeuses ;
  • l’interprétation de ces documents repose sur le désarchivage, la décompression, et l’encodage. En d’autres termes, la fragilité des bibliothèques associées peut être également l’objet d’une exploitation par ces documents.

Le CERTA recommande, en conclusion, de bien préparer la transition vers ces nouveaux formats. L’administrateur doit adapter ses règles de filtrage aux vicissitudes de ces derniers, et ne pas considérer, trop simplement, que l’« ouverture » de ses nouveaux formats soit nécessairement un signe de confiance. L’ouverture de ces formats ne signifie pas non plus que tout le contenu soit lisible et compréhensible. Des fichiers au format propriétaire peuvent très bien se dissimuler dans l’archive.

4 Rappel sur les mots de passe

Dans le bulletin d’actualité CERTA-2007-ACT-027 de la semaine dernière était publié un article sur les mots de passe. Celui-ci détaillait les principaux risques liés à ceux-ci :

  • les mots de passe faibles, dérivés du nom de compte, de mots du dictionnaire, de dates, de noms propres, etc. ;
  • les mots de passe mal protégés : stockés dans un fichier accessible par tous ;
  • les mots de passe qui transitent en clair : utilisés par des applications non sécurisées comme Telnet et FTP, par exemple.

Le CERTA rappelle l’importance de ces trois points, et dans ce contexte avertit également du risque de l’utilisation d’outils en ligne en rapport avec des mots de passe ou clés de chiffrement.

Pour illustration, des outils de calcul en ligne de clés PSK WPA existent sur l’Internet, obtenus à partir de la passphrase et du SSID que l’on doit fournir. Certains fonctionnent uniquement en local avec du code Javascript, mais d’autres envoient les informations au serveur. Ces informations envoyées peuvent évidemment être utilisées à mauvais escient, soit directement contre le réseau de la machine client ou simplement pour renforcer des dictionnaires. Si les créateurs de l’outil peuvent être de bonne foi (le service a été proposé cette semaine dans le cadre d’un projet de bonne réputation), ces informations peuvent cependant être envoyées en clair, ou récupérées à cause d’un keylogger (enregistreur de frappes clavier) même si le code fonctionne uniquement en local sur le navigateur.

Il ne faut pas sous-estimer ce qu’il est possible de faire en JavaScript, et croire que son exécution sur le poste client implique que les données manipulées resteront sur le poste client uniquement.

Le CERTA recommande ainsi que l’utilisation de telles applications se fasse sur des postes isolés de l’Internet.

4.1 Documentation

Note d’information CERTA-2005-INF-001 « Les mots de passe »

http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-001/

Rappel des avis émis

Dans la période du 18 au 24 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 29 juin 2007
    version initiale.