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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-36

Gestion du document

Référence CERTA-2007-ACT-036
Titre Bulletin d’actualité 2007-36
Date de la première version 07 septembre 2007
Date de la dernière version 07 septembre 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 La tempête ?

1.1 Description

Un ver, connu sous les noms de Storm Worm, Zhelatin, Gang ou Nuwar se propage actuellement sur l’Internet. Ce dernier n’est pas récent et a fait l’objet, dès février, de plusieurs articles dans des publications du CERTA (cf. bulletins d’actualité CERTA-2007-ACT-007, CERTA-2007-ACT-028 et CERTA-2007-ACT-034). Il présente néanmoins quelques caractéristiques originales. Les rapports remontés par les antivirus de plusieurs correspondants motivent cet article.

Un ver se caractérise très souvent par trois caractéristiques :

  • un vecteur d’attaque : comment entre-t-il sur un système ?
  • un vecteur de contamination : que fait-il sur un système compromis ?
  • un vecteur de propagation : comment va-t-il chercher de nouvelles victimes ?

Zhelatin n’utilise pas, dans ses versions actuelles, de vulnérabilités connues pour s’introduire dans un système. Sa propagation résulte en grande partie de techniques « d’ingénierie sociale », incitant l’utilisateur à se rendre sur un site ou à cliquer dans un lien présent dans un courrier électronique, afin de télécharger et installer un fichier exécutable.

Le ver Zhelatin a plusieurs modes de propagation. Les machines compromises peuvent devenir des émetteurs de courriers électroniques. Le code s’appuie sur des listes pré-construites de corps de message, de sujets et de noms de domaines pour créer les expéditeurs. Les machines infectées envoient des courriels combinant ces informations à des adresses victimes, à un rythme soutenu.

Les sujets des méls peuvent être de tout ordre :

  • liés à l’actualité (tempête de décembre 2006, fête nationale, Saint-Valentin, situation en Iran ou en Iraq, etc.) ;
  • liés à des thèmes plus classiques : cartes postales électroniques, vidéo à télécharger, rencontres, argent facile, outils de sécurité ou de dissimulation de traces, etc.

Une autre forme de propagation observée consiste à ajouter des codes Javascript dissimulés dans des pages Web de serveur, ou sur des listes de diffusion / bloc-notes.

La contamination de l’ordinateur se traduit par un envoi de courriers non sollicités ou une participation à une attaque distribuée en déni-de-service. Il peut également y avoir une modification de la configuration DNS de la machine. Des outils de capture de frappe claviers ont également pu être observés sur certaines machines infectées, même si le lien direct avec Zhelatin n’est pas encore avéré. Les machines compromises (ou zombies) font partie d’un réseau, et l’objet de la compromission peut évoluer.

Il s’agit d’une architecture complexe, profitant de plusieurs caractéristiques : des réseaux pair-à-pair pour échanger des données et des instructions, et des enregistrements DNS éphémères (association entre une adresse IP et un nom de machine).

L’architecture n’est pas encore, à la date de rédaction de cet article, complètement connue.

Certains éléments permettent cependant d’identifier les compromissions et de limiter les risques. Ils sont détaillés dans la section suivante.

Les versions à jour de plusieurs anti-virus reconnaissent un grand nombre de variantes du ver.

Le CERTA invite ces correspondants à l’informer de toute découverte de traces à ce sujet.

1.2 Contournement provisoire

Plusieurs mesures standards peuvent être considérées pour éviter d’exposer ces systèmes à un tel ver, aussi bien par l’utilisateur, que par l’administrateur du réseau :

  1. Pour les utilisateurs :
    • ne pas faire confiance au champ FROM: des courriels ;
    • ne pas cliquer de façon inconsidérée sur des liens insérés dans les messages ;
    • désactiver le Javascript par défaut ;
    • rester vigilant et méfiant. Par exemple, les mises à jour de sécurité sont rarement diffusées par mél, et les consignes de mises à jour sont annoncées par l’équipe de soutien informatique ou le responsable de sécurité.
  2. Pour les administrateurs et responsables informatiques :
    • au niveau réseau :
      • vérifier les politiques de filtrage réseau au niveau des pare-feux, et notamment les règles associées aux connexions sortantes. Le trafic pair-à-pair doit être surveillé ou bloqué. Les machines compromises se caractérisent par un trafic souvent plus important en UDP, vers des ports Overnet/eDonkey (valeurs des ports variables).
      • vérifier au niveau des journaux si des connexions ont pu être établies vers des machines associées à certains domaines suspects ;
      • vérifier l’intégrité du contenu des sites Web, et contrôler avec vigilance les données entrées par les utilisateurs sur des forums ou des listes de diffusion ;
      • filtrer au niveau des passerelles de navigation et de messagerie les téléchargements et les pièces jointes (les versions actuelles du ver se limitent pour le moment aux extensions .EXE et .GIF) ;
      • consulter les journaux des serveurs DNS et des serveurs de messagerie pour vérifier aucun comportement anormal : hausse importante du nombre de requêtes de type MX, augmentation du nombre de courriers retournés invalides, volume accru d’envois, etc.
      • modérer les forums et les listes de diffusion sur lesquelles des personnes extérieures peuvent contribuer.
    • au niveau des postes des utilisateurs :
      • vérifier que la politique de sécurité est bien respectée : par exemple, la navigation, ou la lecture d’une messagerie doit se faire d’un compte aux droits limités
      • mettre à jour les systèmes et les logiciels ;
      • sensibiliser les utilisateurs (en s’appuyant par exemple sur les documents disponibles sur le site du CERTA).

1.3 Documentation

2 Traitement des URI par Mozilla Firefox

L’alerte CERTA-2007-ALE-013 du 27 juillet 2007 détaillait une vulnérabilité de Mozilla Firefox permettant à une personne d’exécuter des commandes arbitraires à distance en incitant un utilisateur à suivre un lien spécialement conçu. Mozilla avait rapidement réagi en sortant les versions 2.0.0.6 de Firefox et Thunderbird ; toutefois ces mises à jour n’ont corrigé la vulnérabilité que partiellement.

L’éditeur lui-même avait en effet expliqué dans son bulletin de sécurité MFSA2007-27 que le correctif empêche l’exécution des preuves de faisabilité publiées, mais ne corrige pas le problème sous-jacent. Ainsi, le traitement des URI est encore vulnérable, dans le sens où il reste possible de contourner l’action par défaut liée au protocole et de passer au contraire par le gestionnaire de type de fichier, qui lancera un programme en fonction de l’extension du fichier appelé dans l’URI.

Récemment, les chercheurs qui avaient publié la vulnérabilité ainsi qu’une première preuve de faisabilité ont annoncé avoir trouvé au moins un moyen de contourner le dernier correctif de Mozilla. Aucune preuve de faisabilité n’a cependant été publiée. Le CERTA rappelle un contournement non-intrusif consistant à mettre les options network.protocol-handler.warn-external.XX à « true » dans la fenêtre about:config pour forcer l’affichage d’avertissements par Mozilla Firefox.

Documentation associée

3 Mises à jour de Microsoft pour le mois de septembre

Microsoft a annoncé, par le biais d’un article dans son bloc-notes, les différentes mises à jour qui seront publiées mardi 11 septembre 2007. Cinq bulletins de sécurité sont prévus, dont :

  • un concernant Microsoft Windows, et estimé par la société comme « critique » ;
  • un concernant Microsoft Visual Studio, et estimé par la société comme « important » ;
  • un concernant Microsoft Windows Services pour Unix, et estimé par la société comme « important » ;
  • un concernant Microsoft MSN Messenger, et estimé par la société comme « important » ;
  • un concernant Microsoft Windows et Microsoft SharePoint Server, et estimé par la société comme « important ».

En marge de ces bulletins, Microsoft annonce aussi une mise à jour prioritaire de Microsoft Update, mais qui ne serait pas, selon le document de la société, lié à un problème de sécurité.

Ces informations sont visibles sur le bloc-notes de Microsoft :

http://blogs.technet.com/msrc/archive/2007/09/06/september-2007-bulletin-release-advance-notification.aspx

4 Connaître la boîte, pour mieux déterminer ses vulnérabilités

4.1 Problématique générale

Plusieurs solutions commerciales vendues actuellement, sous une forme logicielle ou matérielle, s’appuient en partie sur des codes ou projets existants, mis à disposition dans le cadre de partenariats ou de logiciels libres. Ceci n’est pas surprenant. Etant donnée la complexité des systèmes actuels, il est quasiment impossible pour une entreprise de développer des solutions dans leur intégralité. La remarque de cet article n’est pas de ce propos, mais concerne plutôt les conséquences que cette intégration implique sur la notion de mise à jour.

Il est important de connaître ces intégrations dans les solutions commerciales. La raison principale est que les vulnérabilités découvertes sur les logiciels intégrés sont très fréquemment rendues publiques, et qu’il est donc possible d’estimer rapidement les vulnérabilités pouvant affecter la solution commerciale. Si les fabriquants n’ont pas une veille attentive sur ces produits, ou se préoccupent peu de celle-ci, il y a alors des risques d’avoir des vulnérabilités permanentes dans la solution commercialisée. Cela doit être pris en compte dans la politique de sécurité globale.

Le CERTA insiste donc bien auprès de sa communauté à considérer ces aspects d’intégration et de transparence par les fabriquants dans leur choix de mise en œuvre.

4.2 Une illustration

Les exemples liés à la remarque précédente sont très nombreux, et couvrent des technologies très diverses. Considérons les outils d’analyse réseau. Qu’ils soient sous forme d’IDS (Intrusion Detection Systems), de renifleurs (sniffers), d’outils d’identification de protocoles ou simplement de statistique du trafic (netflow par exemple), ces outils ont souvent des caractéristiques communes. Ils s’appuient sur des projets libres comme :

  • libpcap et sa variante pour Windows winpcap
  • tcpdump
  • wireshark (anciennement ethereal)

Cette utilisation est soit clairement annoncée, soit dissimulée.

Plusieurs vulnérabilités ont affectées ces logiciels. Pour 2007 :

  • CERTA-2007-AVI-067 : des vulnérabilités de Wireshark dans des modules d’analyse TCP, HTTP, 802.11 ou LLT de Wireshark seraient exploitables par l’envoi de paquets spécialement construits ;
  • CERTA-2007-AVI-278 : des vulnérabilités de Wireshark concernant l’interprétation de paquets HTTP, DCP ETSI, SSL, MMS ou DHCP pourraient, si elles sont exploitées, provoquer la perturbation du service Wireshark ;
  • CERTA-2007-AVI-323 : une vulnérabilité de tcpdump concernant la manipulation de paquets associés au protocole de routage BGP pourrait permettre à une personne distante d’exécuter du code arbitraire sur le système vulnérable, par le biais d’un paquet spécialement construit ;
  • CERTA-2007-AVI-289 : une vulnérabilité dans la gestion du pilote NPF.SYS de winpcap permet à un utilisateur local d’élever ses privilèges à ceux du système pour exécuter des commandes arbitraires.

Certaines des vulnérabilités publiées ne font pas l’objet d’avis du CERTA, car elles concernent des anciennes versions de ces logiciels.

Ainsi, la première semaine de septembre 2007, un code d’exploitation a été diffusé sur l’Internet, et cible le module d’analyse du protocole DNP3. Le Distributed Network Protocol regroupe en réalité plusieurs protocoles de communication et se retrouve dans des systèmes de type SCADA. Une personne distante, par le biais d’un paquet spécialement conçu, peut exploiter la vulnérabilité en question afin de provoquer un déni de service.

Cette vulnérabilité pose des problèmes car, très souvent, la surveillance d’un réseau repose sur des outils tels que ceux mentionnés. Si ceux-ci sont indisponibles, la surveillance est largement réduite.

Quid des mises à jour des solutions commerciales ? Plusieurs boîtiers s’appuient sur les modules d’analyse de Wireshark. L’administrateur doit donc se poser les questions suivantes :

  • Mes systèmes emploient-ils de tels modules ?
  • Sont-ils vulnérables à une telle exploitation ?
  • Dans l’affirmative, ont-ils été mis à jour ?

Ce questionnement implique de connaître certains détails techniques que les boîtiers enveloppent.

Documentation associée

Rappel des avis émis

Dans la période du 27 août au 02 septembre 2007, 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 07 septembre 2007
    version initiale.