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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-34

Gestion du document

Référence CERTA-2007-ACT-034
Titre Bulletin d’actualité 2007-34
Date de la première version 24 août 2007
Date de la dernière version 24 août 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 Des incidents traités cette semaine

1.1 Développement de scripts PHP et incidents

Le CERTA a traité cette semaine un incident de compromission de site Web faisant suite à l’exploitation d’une vulnérabilité de type PHP Include. Ces attaques sont assez courantes et affectent généralement des applications Web très populaires et très répandues. La compromission traitée se démarque des autres car le script attaqué ne correspondait à aucune application Web connue. Il s’agissait d’un développement « maison ».

Des administrateurs considèrent -à tort- que les scripts développés pour un besoin propre ne présentent pas de risque de sécurité puisque personne n’a accès à leurs sources. C’est une forme de « sécurité par l’obscurité ». Cette approche est mauvaise car il n’est pas nécessaire d’avoir accès aux sources de ces programmes pour découvrir des vulnérabilités. C’est notamment le cas pour les attaques de type cross site scripting et SQL injection qui sont toujours de la même forme et peuvent être testées sur tout script PHP. Quant aux cibles d’attaques de type PHP Include, elles peuvent être repérées à l’aide d’un simple moteur de recherche, comme c’était le cas pour notre incident traité.

Il est recommandé de soumettre les scripts PHP à des tests de sécurité avant de les mettre en ligne.

1.2 Un bon reflexe concernant la messagerie

Cette semaine le CERTA, après avoir découvert une compromission d’un site web, a prévenu la victime par courrier électronique. Celle-ci, ne connaissant pas le CERTA, s’est rendue sur le site Web et a appelé le numéro de téléphone y figurant afin de confirmer l’authenticité du courriel qu’elle venait de recevoir.

Ceci est un exemple parmi d’autres du principe de précaution qu’il convient d’appliquer à la messagerie electronique : n’accorder qu’une relative confiance à l’émetteur affiché dans un courrier. Cela est d’autant plus vrai quand le message demande explicitement de retourner des informations ou d’exécuter une action.

Il est bon de rappeler à cette occasion qu’il faut éviter de cliquer sur des liens présents dans les courriers (préférer recopier l’adresse à la main dans le navigateur) ; en aucun cas, même si le courriel le demande, transférer érer un mail reçu à tous ses contacts. L’information est souvent fausse (canulars, hoax), risque de saturer les systèmes de messagerie, et peut servir de vecteur de propagation.

1.3 Jamais plus jamais

1.3.1 Les faits

Au début du mois de juillet le CERTA avait informé une administration française que son serveur web avait été compromis. L’analyse des journaux des connexions avait révélée de multiples compromissions, le serveur hébergeant aussi des outils d’attaque. La préconisation du CERTA était alors de ne plus accorder aucune confiance au serveur ainsi qu’aux données présentes dessus. Malgré ce conseil, le serveur a fait l’objet d’un nettoyage superficiel des pages vulnérables et d’une simple suppression des outils malveillants détectés par le CERTA.

1.3.2 Nouvelle compromission ?

Cette semaine, en analysant les propres fichiers journaux de son serveur web, le CERTA a constaté des tentatives d’attaques de type PHP Include. Elles sont visiblement émises de la machine précédemment citée.

Après avoir repris contact avec le responsable du serveur, le CERTA a pu vérifier que ce serveur n’avait été que sommairement nettoyé. Plusieurs portes dérobées étaient de nouveau actives. Les connexions sortantes de cette machine ne sont pas filtrées, ce qui laisse à tout code malveillant tous moyens de communication et d’échange avec l’extérieur.

Le CERTA insiste donc sur le fait que, lors d’un compromission, il ne faut plus accorder la moindre confiance au système compromis et aux données présentes sur celui-ci ou accessible depuis celui-ci. Dans le cas ou l’intégrité du système est mise en doute, il convient de repartir sur des bases saines :

  • installer un système d’exploitation sain à partir de sources de confiance, sans le connecter au réseau ;
  • désactiver les services non-nécessaires ;
  • mettre à jour le système d’exploitation tout en restant déconnecté du réseau ;
  • installer les applications devant être présentes sur le serveur, et seulement celles-ci ;
  • mettre à jour ces applications ;
  • identifier une sauvegarde de confiance (antérieure à toutes compromissions) ;
  • restaurer les données à partir de cette sauvegarde ;
  • connecter sur le réseau le serveur.

Cette compromission a été découverte par l’analyse de journaux. Le CERTA rappelle donc à cette occasion que l’analyse des journaux doit être effectuée régulièrement afin de pouvoir mettre en évidence une éventuelle compromission ou des tentatives d’attaques.

1.3.3 Documentation

2 MS07-044, et la conversion des fichiers Microsoft Office

2.1 Microsoft Office Isolated Conversion Environment

Le CERTA a publié l’avis CERTA-2007-AVI-354 correspondant au bulletin Microsoft MS07-044 du mois d’août 2007. Il concerne une vulnérabilité dans Excel et Excel Viewer.

Cette vulnérabilité est donc officiellement corrigée par l’éditeur, qui présente aussi quelques solutions de contournement afin de limiter les possibilités d’exploitation de cette dernière.

Le CERTA avait mentionné dans le précédent bulletin CERTA-2007-ACT-021 un outil proposé par Microsoft pour convertir des documents Office 2003 et 2007 : MOICE (pour Microsoft Office Isolated Conversion Environment). L’idée sous-jacente consiste à utiliser une conversion des documents binaires 2003 ou 2007 vers le format Office OpenXML. Cette étape, faite dans un environnement propre, doit en principe produire un document dans un nouveau format et détruire les codes malveillants abusant d’une vulnérabilité concernant uniquement le format initial.

Il est donc légitime de penser que cet outil est également un contournement pour atténuer les risques liés à la vulnérabilité MS07-044. C’est par exemple le cas pour les trois vulnérabilités corrigées dans le bulletin de juillet MS07-036 (CERTA-2007-AVI-291).

Cependant, ce contournement n’est pas valable avec la vulnérabilité décrite dans le bulletin MS07-044. Le bloc-notes de Microsoft en fournit la raison : la vulnérabilité associée au MS07-044 concerne les fichiers d’espace de travail au format XLW. Or l’outil MOICE ne sait manipuler, en l’état actuel, que les formats suivants : XLS, XLT et XLA (pour eXcel Additive et utilisé par les fonctions VBA par exemple).

MOICE se limite également à Microsoft Office 2003 et 2007 dans sa version actuelle.

De tels outils de conversion sont importants pour améliorer la sécurité globale. Ils agissent de manière à prévenir d’éventuels risques (ici associés à certains formats). Ils ne peuvent cependant pas se substituer à la vigilance de l’utilisateur, aux bonnes pratiques comportementales (mise à jour des applications, sessions aux droits limités, etc.) et aux solutions antivirales.

2.2 Autre contournement envisageable : FileBlock

FileBlock de Microsoft Office 2003 et 2007 permet aux administrateurs de restreindre les manipulations des types de fichiers Excel, Word ou PowerPoint à certains types. Chaque type est associé à une « politique de groupe » dans la base de registres.

Cette fonctionnalité permet un contournement provisoire face à la vulnérabilité définie dans le bulletin MS07-044. Cette solution a plusieurs limitations :

  • elle implique intrinséquement que la politique d’accès est précise, avec des utilisateurs et des droits dédiés. Ce n’est malheureusement pas toujours le cas.
  • elle permet uniquement à certains utilisateurs de ne pas ouvrir des types de fichiers, mais ne prévient pas du danger ni de l’ouverture par d’autres utilisateurs aux privilèges plus élevés ;
  • elle repose sur une nouvelle fonction (FileBlock) pour identifier le format de tous les fichiers Office avant leur ouverture complète. Dès qu’il sera possible de leurrer cette fonction, le contournement ne sera plus utilisable.

Une bonne pratique consiste néanmoins à n’autoriser que le nécessaire. Si des formats ne sont jamais utilisés, il est préférable de les filtrer. Cela peut se faire à différents niveaux, sur la machine hôte, par une solution comme FileBlock, mais aussi au niveau des différentes passerelles (messagerie, web, etc.) ou par des sondes de détection, etc.

2.3 Documentation associée

3 Ver Storm : le bon sens reste la meilleure défense

Le ver Storm (« tempête » en anglais) ou Zhelatin tente de se répandre à large échelle. Plusieurs journaux ont largement repris l’information cette semaine.

L’offensive comprend plusieurs étapes et les bonnes pratiques peuvent le contrer.

Les pourriels

Une vague très importante de pourriels a lieu. Le sujet est rédigé actuellement en anglais. Il change sans cesse, en cohérence avec le corps du message : de la proposition de voir des photos ou de charger des musiques en MP3 à la demande de confirmation d’information utilisateur, en passant par les cartes postales électroniques (ecard), le spectre est très large.

Des points communs à ces pourriels doivent éveiller la vigilance :

  • le message est en texte brut, pour tromper les filtres antispam qui pénalisent les courriers en HTML ;
  • dans certaines variantes, un numéro de compte, un identifiant (login) , un mot de passe temporaire et un avertissement veulent laisser croire que l’expéditeur prend en compte la sécurité ;
  • le lien sur lequel le destinataire crédule est invité à cliquer est numérique. Il n’a pas une forme textuelle http://Domaine-douteux/, mais contient l’adresse IP d’une machine sous la forme http://W.X.Y.Z/

    L’internaute responsable ne clique pas sur ce lien.

L’infection

Le destinataire très imprudent qui, malgré le caractère étrange du pourriel, a cliqué sur le lien est connecté sur un serveur web. La page d’accueil du site l’invite à télécharger une applette, par exemple pour sécuriser la connexion. C’est cette applette qui va infecter le poste de l’utilisateur.

Cette infection ne réussit, dans les versions actuelles du ver, que si les logiciels présents sur le poste de l’utilisateur ne sont pas à jour.

Le comportement, défense non coûteuse

Un comportement raisonnable suffit pour prévenir l’infection par ce ver :

  • maintenir son système d’exploitation et ses applications à jour ;
  • ne pas ouvrir les courriels inattendus (expéditeurs, langue, sujet…) ;
  • ne pas cliquer sur les liens dans les pourriels, en particulier si le lien contient une adresse numérique ou des caractères obscurs ;
  • ne pas télécharger de programmes exécutables (.exe, . msi, .scr, etc.) ou d’applettes à partir de sources inconnues ;
  • naviguer sur l’Internet en utilisant un compte qui n’a pas les droits d’administration, et auquel le droit d’installer un logiciel sera retiré.

4 Les événements sous Windows Vista, suite

L’article « Les événements sous Microsoft Windows Vista » du bulletin d’actualité CERTA-2007-ACT-017 présentait les événements sur Vista.

On peut y lire l’apport de nombreuses nouveautés :

  • le nouveau format XML binaire ;
  • l’exportation des événements aux formats XML, evtx et texte ;
  • le filtrage et la création de vues personalisées ;
  • la nouvelle numérotation et pour la majorité une correspondance des numéros par rapport à Windows XP (EventIdVista = 4096 + EventIdXP).

Sur Windows Vista, l’emplacement des fichiers d’événements a également changé : ils se trouvent maintenant dans le répertoire :

 C:\Windows\system32\Winevt\Logs

On y trouve plus de 50 fichiers, correspondant chacun à une catégorie d’événement, par exemple : applications, sécurité, système, mises à jour windows, etc.

Le nouveau service « Event Collector Service » également disponible sur Windows 2003 Server, permet à des ordinateurs distants de déporter des événements d’un type prédéfini vers un poste pour centraliser les informations.

Enfin, il est également possible d’attacher une action à un événement. Par exemple, l’on peut décider d’envoyer un courrier électronique, lancer une application, ou afficher un message lorsqu’un utilisateur se connecte sur le poste, lorsque des mises à jour sont disponibles, etc. Ces actions peuvent être ensuite supprimées dans le planificateur de tâches, qui regroupe également les actions par défaut de Windows. On y remarque d’ailleurs, que certaines tâches utilisent déjà le système d’événements (conflit d’adresses IP, par exemple). D’autres tâches basées sur des critères différents peuvent évidemment y être ajoutées ; et on peut notamment y changer des actions par défaut (lancement du défragmenteur de disque tous les mercredis, création automatique de points de restauration tous les jours, par exemple).

4.1 Références

Rappel des avis émis

Dans la période du 13 au 19 août 2007, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 24 août 2007
    version initiale.