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-2008-ACT-027

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 04 juillet 2008
No CERTA-2008-ACT-027

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2008-27


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-2008-ACT-027

Gestion du 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-2008-ACT-027.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-2008-ACT-027/

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.


6 Rappel des avis émis

Dans la période du 27 juin au 03 juillet 2008, le CERTA a émis les avis suivants :

  • CERTA-2008-AVI-341 : Vulnérabilités dans Mambo
  • CERTA-2008-AVI-342 : Multiples vulnérabilités dans Ruby
  • CERTA-2008-AVI-343 : Multiples vulnérabilités dans Apple Mac OS X
  • CERTA-2008-AVI-344 : Vulnérabilité dans D-Bus
  • CERTA-2008-AVI-345 : Vulnérabilités dans Python
  • CERTA-2008-AVI-346 : Vulnérabilité dans Novell Client

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

  • CERTA-2008-AVI-277-001 : Vulnérabilités dans OpenSSL (ajout des références aux bulletins de sécurité Nortel)
  • CERTA-2008-AVI-323-001 : Vulnérabilités dans Horde (ajout des références aux bulletins de sécurité Fedora)
  • CERTA-2008-AVI-334-001 : Vulnérabilité dans phpMyAdmin (ajout des références aux bulletins de sécurité Fedora )


Liste des tableaux

Gestion détaillée du document

04 juillet 2008
version initiale.



Notes

... HTTP1
Cette visibilité est cependant plus ou moins évidente selon les navigateurs

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-05-24