S.G.D.S.N

Agence nationale
de la sécurité des
systèmes d'information

Paris, le 21 décembre 2007
N° CERTA-2007-ACT-051
Affaire suivie par: CERT-FR

Bulletin d'actualité du CERT-FR

Objet: Bulletin d'actualité 2007-51

Gestion du document

Référence CERTA-2007-ACT-051
Titre Bulletin d'actualité 2007-51
Date de la première version21 décembre 2007
Date de la dernière version21 décembre 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 Mise à jour de SquirrelMail

Nous avions évoqué, dans le précédent bulletin d'actualité, la compromission des versions en téléchargement de SquirrelMail. L'éditeur de ce webmail a rectifié son annonce en précisant que cette compromission a introduit une importante faille de sécurité (permettant l'inclusion de fichiers à distance) dans les sources du logiciel.

Afin d'éviter toute confusion, une nouvelle version, 1.4.13, a été publiée. Tous les utilisateurs des versions 1.4.11 et 1.4.12 sont invités à appliquer cette mise à jour. Le CERTA n'a cependant pas publié d'avis de sécurité, car ces versions ne corrigent pas de problèmes de sécurité concernant l'application.

Documentation :

2 Risques liés à l'utilisation d'outils de communication instantanée

Les outils de communication instantanée (on parle souvent de messagerie instantanée même si le terme « messagerie » n'est pas tout-à-fait approprié) tels que MSN, ICQ, IRC et autres, font l'objet des mêmes problèmes de sécurité que la messagerie (voir CERTA-2003-AVI-084) : propagation de vers et de canulars, phishing (hameçonnage), etc. La particularité de ces outils est leur aspect « instantané », c'est-à-dire que les utilisateurs ont tendance à réagir très rapidement aux messages reçus. Cette spontanéité fait de ces outils un très bon terreau pour la propagation de divers codes malveillants.

Nous avons par exemple pu voir récemment des vers se propageant sur MSN. La mécanique de propagation était simple, elle reposait sur le carnet d'adresses (les contacts) de la victime. Cet incident a montré que les bons réflexes pour la messagerie n'étaient pas toujours appliqués sur MSN.

Encore plus récemment, un message proposant des services pour MSN (en l'occurrence, vous informer des contacts qui vous ont bloqués ou supprimer de leur carnet d'adresses) a été largement diffusé par différents canaux (par MSN bien sûr, mais aussi par divers réseaux sociaux, blogs, etc.). Bon nombre de victimes étaient persuadées du bien-fondé de ce service... après avoir transmis à un site tiers leurs identifiants de connexion à MSN ! Dans ce cas précis, qui s'apparente à du phishing, de nombreuses d'adresses MSN ont pu être collectées, ainsi que les mots de passe associés à ces comptes. Les victimes doivent donc changer leur mot de passe ainsi que la question secrète, tout en gardant à l'esprit qu'un certain nombre de données personnelles éventuellement contenues dans les boîtes de messagerie associées ont déjà pu être capturées.

Avec l'approche des fêtes de fin d'année, on peut s'attendre à ce que de nouveaux codes malveillants se propagent par l'intermédiaire de ces outils de communication, par exemple sous la forme de cartes de vœux.

Recommandations :

La vigilance et la méfiance requises pour la messagerie doivent également être de mise pour les outils de communication instantanée. Les problèmes sont ou seront les mêmes, ce sont les habitudes et les populations d'utilisateurs qui pour le moment diffèrent le plus. Certains outils de communication proposent, par leur paramétrage, des mesures de sécurité qui peuvent être mises en place. Il est important de bien examiner la configuration de ces outils.

Documentation :

3 Problème avec Internet Explorer suite à la mise à jour mensuelle Windows de décembre 2007

Cette semaine avant Noël, plusieurs personnes ont signalé des problèmes liés à l'installation de la mise à jour de sécurité KB942615 pour Internet Explorer relative au bulletin de sécurité MS07-069 du 11 décembre 2007. Cette mise à jour permet de protéger le système contre une vulnérabilité permettant l'exécution de code arbitraire à distance ou en local et un contournement de la politique de sécurité. Cette vulnérabilité a été détaillée dans l'avis CERTA-2007-AVI-540 du 12 décembre 2007.

  • Il a tout d'abord été rapporté des difficultés lors du chargement de la page du site Microsoft contenant ce bulletin de sécurité. Ces problèmes sont dûs à la taille du fichier contenant les informations associées aux bulletins de sécurité d'Internet Explorer. Les informations ont été déplacées dans l'article de la base de connaissances Microsoft relatif à ce bulletin afin d'alléger la taille de page et accélérer son chargement.
  • Des problèmes liés à l'installation touchant plus particulièrement les machines ayant Windows XP SP2 et Internet Explorer 6 ont également été signalés. En effet, après installation du correctif, Internet Explorer se révèle instable et peut afficher un message d'erreur informant d'une éventuelle perte de données en cours de traitement par le navigateur et invite à l'envoi d'un rapport d'erreurs. Ce rapport est relatif au dysfonctionnement de la bibliothèque urlmon.dll. Microsoft a publié une nouvelle mise à jour de sécurité KB946627 afin de corriger les problèmes liés à la première.

    Cette nouvelle mise à jour est disponible via les mises à jour automatiques ou directement en se rendant sur le site de Windows Update.

3.0.1 Documentations

4 Problème de mise à jour du logiciel de messagerie Thunderbird

Le logiciel de messagerie libre Thunderbird existe à travers deux branches de développement : la branche 2.0.0.x, recommandée, et la branche plus ancienne 1.5.0.x . Une erreur dans le traitement des URI mailto: a été corrigée le 17 juillet 2007 par la fondation Mozilla, mais le mode de déploiement du correctif dans la branche 1.5.0 était insatisfaisant :

  • l'installation complète de la version 1.5.0.13 offrait la protection ;
  • la mise à jour automatique depuis une version 1.5.0.x (x<13) n'offrait pas cette protection.

Il est donc recommandé :

  • de préférer la branche de développement 2 ;
  • pour ceux qui ne peuvent réaliser cette migration, installer la version 1.5.0.14.

Il faut enfin noter que la branche 1.5 de Mozilla Firefox n'est, elle, plus maintenue depuis la fin du mois d'avril 2007, comme il a été rappelé dans le bulletin CERTA-2007-ACT-016.

Documentation :

5 Ordinateurs préinstallés

Il est fréquent lorsque l'on fait l'acquisition d'un ordinateur dans le commerce ou bien lors d'un renouvellement de parc informatique de recevoir une machine disposant déjà d'un système d'exploitation évitant ainsi la fastidieuse étape de l'installation puis de la configuration du système et des logiciels appropriés. Or, cette étape est pourtant cruciale si l'on veut avoir un niveau de sécurité suffisant sur sa machine. En effet, ces ordinateurs pré-installés sont souvent configurés pour satisfaire les besoins du plus grand nombre. On trouve donc sur ce type de machines des applications parfois totalement inutiles, voire pas à jour et donc vulnérables. Il y a également des logiciels en version d'évaluation et très souvent des adaptations faites avec le système d'exploitation. Par exemple, dans l'avis CERTA-2007-AVI-556 rédigé le 19 décembre 2007, il est détaillé une vulnérabilité liée à une application spécifique à certains modèles de portables : elle concerne d'un contrôle ActiveX installé par défaut.

Il est donc indispensable lors de l'achat tant d'ordinateurs de bureau que de portables de bien vérifier :

  • la pertinence des applications déjà installées ;
  • le niveau de mise à jour du système d'exploitation et des logiciels ;
  • la présence de logiciels comportant des vulnérabilités non-corrigées.
En cas de problème, une première solution consistera à désinstaller les applications inutiles et mettre à jour celles qui seront conservées. Une deuxième solution plus « propre » sera plutôt de réinstaller totalement la machine en sélectionnant les composants et les logiciels à installer, afin d'avoir un système bien mieux maîtrisé.

6 Les canaux cachés DNS

DNS est un protocole largement utilisé pour déterminer la correspondance entre le nom d'une machine et son adresse IP associée.

Un tunnel DNS se caractérise par des échanges illustrés dans la figure 1 ; à première vue, ce sont des échanges sous forme de requêtes et de réponses. La requête correspond à la demande du poste, comme par exemple pour accéder à la page d'accueil du CERTA www.certa.ssi.gouv.fr.

Dans le cas présent, le poste se trouve derrière un pare-feu, et ne peut normalement pas communiquer vers l'extérieur. Le pare-feu n'est cependant pas très regardant pour des protocoles standards comme DNS, NTP ou ICMP et laisse sortir ces flux de manière très laxiste. Ce cas de figure peut se rencontrer dans la mise en œuvre d'un portail captif Wi-Fi. Un autre cas de figure consiste à simplement bloquer les ports HTTP/HTTPS courants (80,443,8080, ...) et à ne pas donner l'accès du relais mandataire web aux utilisateurs qui ne doivent pas naviguer.

La machine interne peut donc néanmoins émettre des requêtes DNS, qui sont soit directement envoyées vers un serveur DNS externe, soit transférées par un serveur DNS interne.

La requête est généralement codée en Base32 (encodage équivalent à Base64, mais chaque caractère est codé sur 5 bits au lieu de 6, et il n'y a plus de distinction entre majuscule et minuscule). Elle concerne un sous-domaine bien particulier, géré par une personne qui en garde le contrôle (sous forme de « délégation » DNS du domaine par exemple).

Le serveur est interrogé pour répondre à cette requête. Il va donc interpréter les données encodées, et les traiter. Il peut s'agir en réalité de données SSH, ou d'URL.

Ce serveur a la possibilité de requérir les services d'un relais mandataire pour répondre, ou effectuer lui-même cette tâche. Sa réponse est ensuite envoyée sous forme d'un enregistrement de type TXT. Cet enregistrement est transmis de bout en bout, et doit en principe parvenir à la machine dans le réseau interne.

L'administrateur de ce même réseau n'a que les trames DNS pour découvrir le contournement de la politique de sécurité mise en place au niveau du pare-feu. Le schéma est volontairement simplifié sur la figure 1 :

  • les données échangées via les requêtes et les réponses DNS ne sont pas toujours lisibles et peuvent être encapsulées par exemple dans un tunnel SSH. Le serveur DNS malveillant peut alors jouer le rôle de relais SSH.
  • tous les moyens pour mettre en œuvre cette architecture, y compris le tunnel SSH mentionné précédemment, sont très accessibles et largement documentés sur l'Internet. D'autres enregistrements comme KEY avec DNSSEC sont également utilisés...

Cet usage est très souvent un contournement de la politique de sécurité et reste mal connu des administrateurs.

Pour toutes ces raisons, le CERTA émet quelques recommandations :

  • cet échange se fait suivant certaines contraintes. Les requêtes DNS ont une taille limite de 253 caractères, dont 63 par « sous-domaine » (entre les "."), mais ces longueurs extrêmes sont très rarement utilisées. De même, les réponses du serveur doivent tenir compte des contraintes de longueur et de fragmentation possible. Ces spécificités peuvent être visibles si l'on procède à une analyse régulière des journaux :
    • surveillance du nombre de requêtes ;
    • surveillance de la variation de l'intervalle de temps entre chaque requête par rapport à une valeur moyenne (écar t-type) ;
    • surveillance du volume des données échangées....
  • une analyse du trafic au niveau du réseau peut apporter une vue supplémentaire : surveillance régulière du trafic, à partir de méthodes statistiques simples pour déterminer par exemple les échanges et les volumes de données émis et reçus (asymétrie ?), la taille moyenne des paquets DNS, les domaines interrogés, etc.
  • dans le cas d'un DNS interne, seul le relais mandataire applicatif doit être en mesure d'interroger des DNS externes ;
  • certains serveurs DNS interprètent les enregistrements et les traduisent à la volée. Cette méthode permet également de filtrer des enregistrements jugés suspects (comme TXT).
Figure 1: Schéma d'un tunnel DNS possible
Image dnstunnel

Documentation

Rappel des publications émises

Dans la période du 10 décembre 2007 au 16 décembre 2007, le CERT-FR a émis les publications suivantes :


Dans la période du 10 décembre 2007 au 16 décembre 2007, le CERT-FR a mis à jour les publications suivantes :

Gestion détaillée du document

    le 21 décembre 2007
    version initiale.