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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-27

Gestion du document

Référence CERTA-2008-ACT-027
Titre Bulletin d’actualité 2008-27
Date de la première version 04 juillet 2008
Date de la dernière version 04 juillet 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 Incident de la semaine

1.1 La synchronisation des serveurs

Le CERTA a traité un incident impliquant une application Web. L’architecture de l’application comporte un portail Web, hébergé sur un serveur Apache sous Linux, et une base de données, hébergée sur un serveur Windows 2000 Serveur. Lors du traitement de l’incident, le CERTA peut avoir besoin de croiser plusieurs journaux venant des deux serveurs. Le problème est que les serveurs n’étaient pas synchronisés sur une base de temps. Ce défaut de configuration a provoqué au bout d’un certain temps un décalage plus ou moins important même si les serveurs avaient été configurés à la main à la même date à l’origine. Il s’avère finalement que les deux serveurs étaient décalés de 48 minutes et 53 secondes à la date de l’incident. Une des méthodes permettant de supprimer ce décalage consiste à choisir une base de temps et à modifier les journaux.

Prenons la date suivante : « 05/12/2007 14:25:07 ». Le but de l’opération sera de mettre en début de ligne la date modifiée, ou non, dans un format permettant un tri en ordre chronologique de la forme :

[Ann�e][Mois][Jour][Heure][Minute][Seconde]
Dans l’exemple cela donne : « 20071205142507 ».

Voici un exemple de code permettant de décaler cette date de 48 minutes et 53 secondes :

echo « 05/12/2007 14:25:07 » |
  perl -ne ‘print « $3$2$1$4$5$6 $_ » if /^(\d+)\/(\d+)\/(\d+) (\d+):(\d
+):(\d+)/’ |
  perl -MDate::Manip -ane ‘@F = (split / /);’\
       -e ‘$F[0] = DateCalc ($F[0], « +48 minutes 53 seconds »);’\
       -e ‘$F[0]=~ s/[:]//g;’\
       -e ‘print join  » « , @F;’

Cette commande donne le résultat : « 20071205151400 05/12/2007 14:25:07 » ; soit la nouvelle date « 20071205151400 » qui équivaut à « 05/12/2007 15:14:00 » (48 minutes et 53 secondes plus tard).

Il ne reste plus qu’à utiliser la commande sort pour trier les résultats. Cette commande n’est cependant valable que sur des entrées d’une courte période où l’hypothèse d’un même décalage d’horloge est faite.

Le CERTA rappelle à cette occasion qu’il est important de synchroniser tout son parc sur une même base référentielle afin de croiser les lectures et les interprétations de journaux.

2 Vacances d’été

Le CERTA souhaite aux lecteurs de ce bulletin d’actualité d’excellentes vacances d’été. Il rappelle à cet égard qu’il est important d’identifier au sein de son administration des systèmes d’information une personne suppléante qui pourra prendre en charge les problèmes de sécurité pendant l’été.

Les retours de congés sont une période critique à anticiper. L’utilisateur rallume un poste qui peut présenter des retards dans les mises à jour du système. Cela peut concerner le système d’exploitation, les applications bureautiques ou spécialisées, les logiciels divers comme les antivirus, les utilitaires de transferts, d’archivage ou de sauvegarde …

Avant et pendant tout le processus de la mise à jour, les vulnérabilités des logiciels ne sont pas encore corrigées. En revanche, elles ont été publiées. Les agresseurs les ont analysées. Ils ont eu le temps de préparer des programmes qui exploitent les faiblesses et leur permettent de prendre éventuellement le contrôle des postes.

L’organisation, la politique des droits, l’architecture et les outils présents sur le réseau de l’organisme permettent de répondre de manière très variée à ce problème. Une solution, peu réaliste hors des très petites structures, consiste à ce qu’un utilisateur présent allume les postes des absents lorsque son propre poste se met à jour et provoque (ou laisse se faire) la mise à jour des postes des absents. L’outillage, par exemple un gestionnaire de configuration, peut forcer la mise à jour du poste dès qu’il est allumé. Une autre stratégie consiste à utiliser un sas virtuel. Tout poste non complètement à jour n’est autorisé à effectuer que des connexions restreintes. Lorsque le poste, rallumé, a fini sa mise à niveau, il recouvre entièrement ses droits de connexion.

Dans tous les cas, l’utilisateur doit être informé de la fragilité de son poste lorsqu’il rentre d’une absence prolongée. La navigation sur Internet doit être limitée ou retardée. La vigilance doit être renforcée lors de la lecture des courriels qui se sont accumulés dans la boîte aux lettres. Il vaut ainsi mieux attendre la fin des mises à jour pour ouvrir les pièces jointes des courriels.

3 Retours sur quelques navigateurs

3.1 Les versions de navigateurs

Le navigateur étant l’élément le plus exposé d’un poste de travail, l’importance de le maintenir à jour n’est plus à démontrer, mais qu’en est-il réellement ? Une étude récemment publiée fait le point sur les versions des navigateurs utilisées en se basant sur les statistiques du moteur de recherche Google et plus précisément sur les versions visibles dans les champs USER-AGENT de l’en-tête HTTP1.

Elle a porté sur des données collectées entre janvier 2007 et juin 2008 et a fourni les résultats suivants :

  • En juin 2008, 78% des navigateurs vus par Google étaient identifiés comme Internet Explorer (IE), 16% comme Firefox , 3.4% comme Safari et 0.8% comme Opera ;
  • parmi ceux-ci, les navigateurs à jour représentaient 47,6% pour IE, 58,1% pour Opera, 85,3% pour Safari et 83,3% pour Firefox.
  • Les dernieres versions majeures d’Internet Explorer (IE7) et Firefox (FF2), au moment de l’étude, sont disponibles depuis octobre 2006, et représentent respectivement, en juin 2008, 52,5% des IE et 92,2% des Firefox.

Le propos n’est pas ici de discuter de la qualité ni des hypothèses de l’expérimentation mais d’en extraire quelques faits marquants. On remarque une disparité dans le niveau de mise à jour des différents navigateurs utilisés, certainement liés au principe de mise à jour automatique : un grand nombre de personnes utilisent encore une version obsolète de navigateur. L’information n’étant pas disponible dans les données de Google, l’étude ne prend pas en compte les vulnérabilités liées à l’utilisation de modules tiers vulnérables. La proportion des navigateurs vulnérables peut donc être supérieure à celle constatée ici.

Le CERTA rappelle qu’il est important de mettre à jour son navigateur et tous les programmes tiers associés.

3.2 Mozilla Firefox

Cette semaine, le CERTA a émis l’avis CERTA-2008-AVI-350 concernant Firefox2. La mise à jour 2.0.0.15 corrige plusieurs vulnérabilités dont quatre indiquées comme critiques par Mozilla et certaines permettant l’exécution de code arbitraire à distance. La version 2 du navigateur sera maintenue jusqu’à la fin de l’année mais l’éditeur préconise de passer à la version 3, version présentée dans le bulletin d’actualité du CERTA du 20 juin 2008. À propos de cette dernière, aucune information supplémentaire concernant la vulnérablité annoncée peu après sa mise à disposition n’est encore disponible.

3.3 Vulnérabilité dans Internet Explorer

3.3.1 Présentation

Une vulnérabilité non corrigée de type Cross-Domain Scripting affecte le navigateur Internet Explorer. L’exploitation de cette vulnérabilité semble possible pour les versions 6 et 7 du navigateur.

Une vulnérabilité de type Cross-Domain Scripting permet à une personne malintentionnée d’obtenir des informations concernant les pages de navigation appartenant à une autre zone de sécurité.

En effet, Internet Explorer cloisonne les données relatives à des cadres (ou FRAME) provenant de différentes sources. Afin de différencier les sources, une notion de « zone de sécurité » a été introduite. Ce modèle de sécurité est présent afin d’empêcher le code issu d’un domaine d’accéder à des informations appartenant à un autre domaine.

Cette vulnérabilité est à rapprocher des vulnérabilités de type injection de code indirecte (Cross-Site Scripting – XSS). Une personne malveillante, en forçant la visualisation d’une page spécialement conçue, peut accéder des informations de l’utilisateur entrées pour d’autres zones. Une exploitation de cette vulnérabilité pourrait même, par exemple, permettre l’enregistrement des frappes clavier dans les formulaires des autres zones, et cela via un simple lien.

Des codes d’exploitation de cette vulnérabilité sont disponibles sur l’Internet. Le CERTA recommande donc une grande prudence quant à l’utilisation d’Internet Explorer :

  • filtrage de balises de types FRAME et/ou IFRAME lorsque cela est possible ;
  • désactivation de l’interprétation des langages dynamiques (JavaScript, Flash, …) dans le navigateur par défaut ;
  • navigation sur des sites de confiance ;
  • utilisation d’un navigateur alternatif dans l’attente d’un correctif de l’éditeur.

3.3.2 Documentation

4 Injections SQL : vérification des pages ASP

4.1 Présentation des faits

Le CERTA a publié depuis le début d’année différents articles concernant des corruptions de bases de données via des variables de codes ASP incorrectement contrôlées. Parmi eux :

Les incidents utilisant de telles méthodes sont relativement courants depuis le début d’année.

Il est donc important d’auditer avec attention son code afin de vérifier que les valeurs passées aux variables sont correctement filtrées. Ces incidents ont motivé l’apparition de nouveaux outils de vérification de code. L’objet n’est pas ici de les comparer avec d’autres qui existent mais de signaler au lecteur leur existence.

  • Microsoft Source Code Analyzer for SQL Injection
  • Scrawlr (produit conjointement par HP et Microsoft)
  • URLScan (version 3.0 Beta)

Il faut bien comprendre que les outils présentés ne sont pas des outils complets d’audit d’injection SQL mais ils effectuent des tests à la recherche de défauts dans les pages souvent indexés par les moteurs de recherche. Leur utilisation peut donc réduire les risques et limiter les injections SQL massives mais doit être complétée par une analyse directe du code pendant et après la phase de développement.

4.2 Documentation

5 Vulnérabilités Ruby

5.1 Présentation

Le CERTA a publié le 27 juin 2008 l’avis CERTA-2008-AVI-342 sur des vulnérabilités présentes dans le langage Ruby. Certaines de ces vulnérabilités permettent à un utilisateur distant d’exécuter du code arbitraire. Hormis le fait que le CERTA recommande d’appliquer les correctifs associés dans les plus brefs délais, il tient à préciser quelques points supplémentaires.

Il convient, tout d’abord, de bien différencier les langages dits interprétés des langages compilés. Dans le premier cas, on utilise un intrerpréteur qui lira un fichier texte dit « de script » pour réaliser des tâches. Dans le second cas, on utilise un compilateur qui transforme un ou plusieurs fichiers de texte ou « code source » en fichier(s) binaires exécutables compréhensibles uniquement par le système d’exploitation ou l’ordinateur lui-même. Ainsi dans le cas de Ruby, il s’agit, en fait, d’un langage interprété utilisant un interpréteur de commandes : ruby. Il n’est pas rare que cet interpréteur de commande soit programmé dans un autre langage souvent compilé. Pour ruby, une partie des fonctions de base sont écrites en utilisant le langage ruby lui-même mais l’interpréteur est programmé avec un langage compilé : C. C’est pourquoi, dans le bulletin de sécurité de ruby, on parle de vulnérabilités touchant l’interpréteur ruby affectant des fonctions en C présentes dans le code source de l’interpréteur (fichiers en .c).

Ces familles de langages ont chacune leurs avantages et leurs inconvénients et il n’appartient pas au CERTA de définir quel autre langage il faut utiliser dans tel ou tel cas. Il tient simplement à rappeler que pour des langages interprétés et lorsqu’une vulnérabilité est publiée à leur sujet, il conviendra de bien dissocier les failles relatives à l’interpréteur de celles relatives aux extensions ou aux fonctions mises en œuvre dans ce langage.

Ainsi, si l’on prend comme exemple php, il faudra faire la différence entre la vulnérabilité de l’interpréteur (php.exe sous windows) de la vulnérabilité résultant d’une erreur dans le code d’un fichier php. Dans les deux cas, une mise à jour est indispensable mais, si l’interpréteur est vulnérable, tous les programmes basés sur le langage de cet interpréteur peuvent être des vecteurs d’exploitations. Ainsi, si l’on sait qu’une application en ruby utilise une fonction ruby vulnérable, une attaque sera envisageable via cette application.

5.2 Recommandations

Les failles relatives aux interpréteurs de langage sont donc relativement critiques et devront généralement faire l’objet d’une mise à jour dans les plus brefs délais car il est assez délicat de répertorier l’ensemble des applications s’appuyant sur les fonctions vulnérables de ce langage.

Rappel des avis émis

Dans la période du 23 au 29 juin 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 04 juillet 2008
    version initiale.