1 Les incidents traités cette semaine

1.1 Vulnérabilités dans Dokeos

Des vulnérabilités affectant les versions 1.6.5 et 1.8.0 de Dokeos ont récemment été rendues publiques. L’une de ces vulnérabilités est activement exploitée, comme nous l’avons mentionné dans le bulletin d’actualité CERTA-2007-ACT-021.

Les éditeurs de Dokeos n’envisagent pas de publier un correctif pour la version 1.6.5. En effet, la branche 1.6.x devrait, faute de moyens, ne plus être maintenue (hormis sur demande contractuelle). En revanche, une version 1.8.1, corrigeant la faille exploitée, est prévue pour la mi-juin 2007. Toutefois, les éditeurs de Dokeos ont mis à disposition du CERTA un correctif temporaire pour la version 1.8.0 permettant d’empêcher les récentes attaques. Ce correctif peut être obtenu sur demande auprès du CERTA. Il s’agit d’un correctif temporaire car toutes les vulnérabilités n’ont pas encore été identifiées.

Recommandations :

Nous recommandons aux utilisateurs de Dokeos 1.6.x de migrer vers la branche 1.8.x (cette dernière nécessite l’utilisation de PHP 5), d’entrer en contact avec leur responsable de sécurité pour l’obtention du correctif temporaire et de suivre la sortie d’un correctif définitif.

1.2 Validation des paramètres d’une fonction, précaution indispensable

Les bonnes pratiques du génie logiciel comprennent, entre autres, la vérification des valeurs des paramètres d’entrées dans une fonction ou dans une procédure. Cette règle est trop souvent oubliée. L’absence de la vérification et de la validation crée des faiblesses dans les programmes, exploitées par les agresseurs des systèmes d’information. Le CERTA traite des incidents qui résultent de cette exploitation délictueuse. A valeur d’illustration, les derniers bulletins d’actualité traitent :

  • de failles de type PHP include ;
  • de possibilités d’injection de code (cross site scripting).

Cette liste n’est hélas pas close. L’utilisation d’une redirection par un servlet doit respecter les bonnes pratiques de développement. C’est particulièrement vrai lorsque la page vers laquelle l’internaute sera redirigée ou lorsque le cadre (frame) qui sera chargé figure en argument dans l’URL. Sur le navigateur de l’internaute, la barre d’adresse contient :
http://www.site-imparfait.fr/chemin/redirect.jsp?page=la-page-a-charger.html
Si le contenu de la variable page n’est pas vérifié, alors cette variable peut être détournée. Des actions de filoutage (phishing) peuvent utiliser le site pour diriger l’internaute victime vers un site frauduleux. Comme pour les vulnérabilitées déjà mentionnées dans son bulletin d’actualité, le CERTA recommande plusieurs niveaux de filtrage et de vérification des valeurs entrées :

  • gestion de la longueur de l’entrée, prévention des débordements ;
  • prise en compte des différents codages admis dans les URL, plus généralement dans les entrées ;
  • jeu de caractères utilisé (aseptisation si les caractères spéciaux n’ont pas lieu d’être présents) ;
  • syntaxe ;
  • sémantique, appartenance à un ensemble de valeurs permises ;
  • restriction au strict nécessaire des flux sortants (exemple : HTTP) provenant d’un serveur.
Cette liste de précaution n’est pas exhaustive. Elle s’applique aussi bien au niveau du serveur, qu’à celui des éventuelles passerelles (proxy).

Documentation

2 Virus embarqués dans des fichiers RTF

Les nombreuses vulnérabilités touchant Microsoft Office incitent les personnes à utiliser des formats plus sûrs tels que RTF (Rich Text Format). Toutefois ce format, lisible par de nombreux éditeurs de texte, est utilisé depuis peu comme conteneur de certains virus. Ces virus utilisent une propriété permettant à chacun d’insérer des objets dans les documents RTF ; dans ce cas précis, l’objet est un fichier exécutable.

L’infection sous Microsoft Word se fait de la manière suivante :

  • les victimes reçoivent un courriel avec le fichier RTF en pièce jointe, qui semble inoffensif ;
  • l’ouverture de ce document provoque un faux message d’erreur dans l’éditeur de texte : l’utilisateur est invité à double-cliquer sur l’icône apparue dans Word pour rouvrir le fichier (cette icône représente en fait l’exécutable contenu dans le document) ;
  • le lancement de l’exécutable provoque l’infection de l’ordinateur.

Cette technique n’utilise aucune faille de Microsoft Word mais seulement un peu d’ingénierie sociale. Il est à noter que le fait de double-cliquer sur l’objet contenu dans le document RTF ouvert provoque un avertissement sous Microsoft Windows qui demande une confirmation.

A la date de rédaction de ce bulletin, trois variantes de ce virus ont été clairement identifiées. L’utilisation de fichiers au format RTF n’est évidemment pas à proscrire, toutefois le CERTA rappelle à chacun la nécessité d’être très vigilant vis-à-vis de tout type de fichier qui n’est pas d’une provenance sûre, quelque soit son format.

3 Les événements Windows

Microsoft Windows identifie dans les journaux les événements par leurs identifiants. Parmi ceux intéressants et nouveaux, il y a l’identifiant 4907. Il notifie tout changement de SACL d’un objet, par l’administrateur ou un programme. L’objet peut aussi bien être une clé de registre, qu’un fichier ou un répertoire. Le SACL (pour System Access Control List) sert à Windows pour définir quels utilisateurs ou groupes d’utilisateurs peuvent surveiller (« auditer») l’objet.

En prenant un exemple, voici à quoi ressemble un tel événement :

Sujet:
      ID de s�curit�:               SYSTEM
      Nom du compte:                TEST$
      Domaine du compte:            WORKGROUP
      ID d’ouverture de session:    0x3e7
Objet:
      Serveur de l’objet:   Security
      Type d’objet:         File
      Nom de l’objet:       C:\Program Files\Windows Defender\MpSoftEx.dll
      ID du handle:         0x1d4
Informations sur le processus:
      ID du processus:      0x6e0
      Nom du processus:     C:\Windows\servicing\TrustedInstaller.exe
Param�tres d’audit:
      Descripteur de s�curit� d’origine:
      Nouveau descripteur de s�curit�: S:ARAI(AU;SAFA;DCLCRPCRSDWDWO;;;WD)

Cela indique notamment :

  1. qui a changé le SACL (SYSTEM TEST)
  2. quel programme a été utilisé pour changer le SACL (TrustedInstaller.exe)
  3. le nom et le type d’objet qui a eu ses attributs modifiés (file)

Le dernier champ, correspondant au Descripteur de sécurité est une chaîne de caractères particulière, dont l’interprétation est expliquée à l’adresse :

http://www.washington.edu/computing/support/windows/UWdomains/SDDL.html
On peut constater dans l’exemple que cette chaîne a étécréée, et ne contenait aucune valeur à l’origine.

Suivre ces événements permet donc de vérifier rapidement si les caractéristiques de surveillance des objets ont été modifiées, ainsi que de déterminer quels changements ont été effectués.

4 Les risques des jeux en ligne

Certains jeux en ligne populaires, comme actuellement World of Warcraft font l’objet de convoitise de la part de codes malveillants. En effet, plusieurs vers et chevaux de Troie ont été observés de part le monde, et notamment en France, avec pour principal objectif de dérober les identifiants de connexion de ces jeux.

Il est alors légitime de se demander pourquoi un tel « attrait » envers ceux-ci plutôt que d’autres. En voici quelques raisons :

  • ces jeux en ligne sont payants. Il existe un trafic permettant d’acheter des comptes ayant obtenu des niveaux avancés dans le jeu, et ainsi progresser plus vite de manière frauduleuse ;
  • certains joueurs peuvent être victimes de chantage. Etant à un stage avancé du jeu, leurs identifiants, récupérés et modifiés par la personne malintentionnée, peuvent leur être restitués en échange de crédits, d’aides, ou d’argent.
  • une fois les identifiants entrés dans le jeu, cela donne accès aux données personnelles de l’utilisateur, incluant son adresse, et parfois ses coordonnées bancaires. Ces informations sont intéressantes pour plusieurs raisons, que ce soit pour mieux cibler des attaques de type filoutage, ou d’escroqueries financières par exemple.
  • une fâcheuse habitude est de conserver les mêmes identifiants pour plusieurs accès à des sites ou services différents. La personne malveillante peut donc les tester, et les ajouter à un dictionnaire pour faire des attaques en force brute sur les mots de passe.

La plus grande difficulté est ici de sensibiliser les utilisateurs aux motivations précédemment citées. Ceux-ci doivent prendre les précautions adaptées pour se connecter depuis une machine et un réseau de confiance (pas une borne publique ou partagée par exemple). Ils doivent également se limiter à fournir l’information explicitement et strictement nécessaire à l’inscription. Les administrateurs doivent, eux, vérifier que la politique de sécurité est bien adaptée, et que l’usage de tels divertissements n’en soit pas un contournement.

5 Des problèmes avec Mozilla Firefox

5.1 La récupération d’informations

Le CERTA a publié dans le précédent bulletin d’actualité CERTA-2007-ACT-021 les détails d’une vulnérabilité concernant l’accès illégitime à des fichiers par le biais de code Javascript et du protocole resource://. Cette dernière devait être corrigée dans la version 2.0.0.4 du navigateur. Cependant, les modifications publiées le 30 mai pour cette version ne font pas état de telles corrections. Les tests effectués semblent également indiqués que la vulnérabilité existe toujours. Dans ces conditions, le CERTA rappelle qu’il est vivement recommandé de désactiver Javascript par défaut, et de ne l’employer que sur certains sites de confiance, quand cela s’avère nécessaire.

Si des passerelles filtrant le contenu sont utilisées, il faut également vérifier que des adresses de type resource:// soient correctement filtrées.

Documentation

5.2 La gestion des mises à jour d’extensions

5.2.1 Présentation du problème

Une vulnérabilité existe actuellement sous Firefox : elle concerne la mise à jour des extensions qui ne sont pas hébergées sur le site https://addons.mozilla.org.

Ces extensions incluent la liste suivante :

  • Google Toolbar
  • Yahoo Tolbar
  • AOL Toolbar
  • PhishTank SiteChecker
  • etc.
La liste est bien entendu non exhaustive.

La mise à jour de ces extensions se fait sans authentification du serveur. Il est donc possible, par une attaque de type « empoisonnement de DNS » ou « homme-au-milieu » de pretexter une mise à jour pour charger un code malveillant et d’exécuter du code arbitraire sur la machine à l’ouverture du navigateur.

Le problème vient donc à la fois :

  • des développeurs d’extensions, qui n’utilisent pas SSL (HTTPS) pour les mises à jour automatiques,
  • de la configuration par défaut de Firefox.
A l’installation d’une extension, Firefox ne prévient pas des risques que les mises à jour peuvent faire courir. De plus, le comportement standard est d’ajouter, lors de cette installation, le site de mise à jour d’une extension à la liste des sites autorisé à faire des mises à jour sans prévenir. Cette liste est accessible :
  1. en se rendant dans l’onglet « Sécurité » de la configuration Firefox
  2. en cliquant sur « exceptions » à côté de la ligne « prévenir lorsque les sites essaient d’installer des modules complémentaires »
Les sites utilisant SSL ne sont pas différenciés de ceux ne l’employant pas.

Dans l’attente de correctifs, de la part de Firefox et des développeurs de ses extensions, le CERTA recommande de :

  • désinstaller autant que possible de telles extensions ;
  • vérifier qu’elles n’ont pas été ajoutées au cours de l’installation d’un logiciel tiers ;
  • vérifier que la liste des ‘sites autorisés’ ne contient que ceux utilisant SSL. Cette liste peut très bien se limiter à ‘addons.mozilla.org’ par exemple, voire être vide.

5.2.2 Les aspects plus techniques

Plus techniquement, voici les détails de cette vulnérabilité : le fichier Manifest associé à l’extension définit les sites pour les mises à jour. Le gestionnaire de mise à jour de Firefox inspecte alors régulièrement ce fichier pour déterminer si de nouvelles versions sont disponibles. Le lien des mises à jour, qui peut aussi être joint à un fichier update.rdf se caractérise par le mot-clé updateURL.

Voici un exemple fourni sur le site de Mozilla :

<_em:updateURL>http://www.XXX/update.cgi?id=%ID%&amp;version=%VER%</em:updateURL>
<_em:updateURL>http://www.XXX/extension/windows.rdf</em:updateURL>

Il faut cependant noter que la branche 1.5.0.X, en fin de maintenance, n’offre aucun accès simple à la gestion des mises à jour, exceptée le choix pour « les modules installés et les thèmes », sans distinction.

Mozilla a annoncé dans un article récent daté du 30 mai 2007 avoir l’intention, dans la version 3 du navigateur Firefox, d’empêcher les développeurs de modules d’utiliser des canaux non sécurisés et d’améliorer l’écriture de ces derniers. Ceci est encore en phase de discussion.

6 Les mises à jour de Microsoft Office sous Vista

Dans son dernier système d’exploitation Windows Vista, Microsoft propose une interface locale à la machine pour procéder aux mises à jour des différents produits Microsoft installés. Ainsi, si Microsoft Office 2007 est présent sur la machine, cette interface proposera les mises à jour pour le système d’exploitation mais également pour la suite Office. Cependant, ceci ne fonctionne qu’avec la dernière version Office 2007. Il n’en va pas de même pour Office XP par exemple. Avec cette version, Windows Update ne prendra pas en charge par défaut les mises à jour. De plus en se rendant sur le site http://update.microsoft.com, l’utilisateur sera redirigé vers l’interface locale l’empêchant de consulter ce site. Il convient dans ce cas de figure :

  • de se rendre sur http://office.microsoft.com/ et de télécharger et appliquer les mises à jour « à la main » ;
  • de se rendre sur http://udpdate.microsoft.com/microsoftupdate et, si vous acceptez les conditions d’utilisation, d’installer le contrôle ActiveX de Microsoft Update. Une fois cet ActiveX installé, l’interface de Windows Update de Vista proposera les mises à jour adéquates pour la suite Office.

Rappel des avis émis

Dans la période du 21 au 27 mai 2007, le CERT-FR a émis les publications suivantes :