![]() |
CERTA Centre d'Expertise Gouvernemental de |
![]() |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2007-36
Gestion du documentUne gestion de version détaillée se trouve à la fin de ce 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-2007-ACT-036.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-2007-ACT-036/ 1 La tempête ?1.1 DescriptionUn 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 :
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 :
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 provisoirePlusieurs 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.3 Documentation
2 Traitement des URI par Mozilla FirefoxL'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 septembreMicrosoft 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 :
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és4.1 Problématique généralePlusieurs 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 4.2 Une illustrationLes 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 :
Cette utilisation est soit clairement annoncée, soit dissimulée. Plusieurs vulnérabilités ont affectées ces logiciels. Pour 2007 :
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 :
Ce questionnement implique de connaître certains détails techniques que les boîtiers enveloppent. Documentation associée
|
![]() |
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||