1 Activité en cours

1.1 Captures de frappes au clavier

Cette semaine, le CERTA a été informé d’un incident de sécurité informatique dû au déploiement d’un outil de capture de données au clavier (keylogger) sur les postes des utilisateurs.

Les données sont recueillies par cet outil malveillant lorsque l’internaute remplit des formulaires sur un site Web. À titre d’illustration, voici un aperçu de la nature des captures de consultation de sites Web portées à notre connaissance :

  • des données concernant la consultation de plus de 200 sites Web (dans le domaine .fr) ;
  • depuis plus de 2500 adresses IP différentes.

Parmi les informations collectées, on trouve :

  • des informations de connexion sur des webmails ;
  • des numéros de sécurité sociale utilisés comme identifiants ;
  • des identifiants de connexion pour des sites publics ou commerciaux ;
  • des demandes d’acte d’état civil ;
  • des informations bancaires (RIB, numéros de cartes).

On notera que le fait que les sites soient sécurisés (https) n’a pas empêché la capture dans la mesure où celle-ci s’effectue sur le poste de l’internaute.

Le CERTA dans le cadre de sa démarche de traitement d’incidents informe les responsables sécurité des serveurs.

Recommandations

Le CERTA attire l’attention des internautes sur l’importance de choisir un poste de travail sain pour procéder à la saisie de données sensibles. Si le poste n’est pas sain, alors la transaction ne peut pas être sûre quelle que soit la solidité des mesures de sécurité mises en place sur le serveur ou entre celui-ci et le poste utilisateur.

Seule l’application rigoureuse des consignes habituelles permet de maintenir un poste sain :

  • applications systématiques des mises à jour de sécurité ;
  • mise en œuvre d’un pare-feu ;
  • suppression des services inutiles ;
  • utilisation d’un antivirus à jour ;
  • vigilance de l’utilisateur sur les anomalies de fonctionnement ;
  • etc.

1.2 Filtrage des flux sortants

Le CERTA a traité un incident suite au signalement d’une machine compromise. Cette dernière envoyait des requêtes à destination d’une machine distante, via le port TCP 6667, associé au service IRC. Ce protocole de messagerie sert également de canal de contrôle dans le cadre de réseaux de machines zombi (botnet).

Outre la compromission de la machine, certaines mesures préventives auraient dû être prises, afin d’éviter qu’une machine interne puisse établir des connexions vers n’importe quel port. De manière générale, le CERTA rappelle qu’il est capital de filtrer les tentatives de connexion depuis le réseau interne. Avoir une politique sortante du type

N_importe_quelle_adresse -> N_importe_quelle_adresse

peut être dangereuse. Il faut, notamment, considérer les points suivants :

  • la politique de filtrage par défaut peut être de tout interdire, puis d’ajouter des règles (ports, adresses) en fonction des besoins ; en l’occurrence, le port destination TCP 6667 n’a pas forcément de raison d’être autorisé, sauf dans un contexte bien particulier.
  • les règles utilisées doivent vérifier que les adresses source sortant du domaine interne sont cohérentes avec le plan d’adressage ;
  • la journalisation (log) doit permettre de récupérer le trafic bloqué. L’administrateur peut ainsi voir plus facilement, à partir de cette source d’informations, quelles machines commencent à s’adresser à des ports non légitimes de machines extérieures.

Ces démarches ne protègent pas des codes ouvrant des connexions sur des ports supposés légitimes (cas des tunnels), mais limitent les risques de rebond d’une machine compromise, et offrent une source intéressante de surveillance du réseau pour l’administrateur.

Il est possible d’utiliser les différents types de proxies pour affiner le filtrage sortant et limiter les effets des tunnels.

Le CERTA recommande la lecture de la note d’information CERTA-2006-INF-001 relative au filtrage et aux pare-feux :

http://www.certa.ssi.gouv.fr/site/CERTA-2006-INF-001/

2 Avis Microsoft du mois de décembre 2006

2.1 Les faits

Plusieurs vulnérabilités présentes au moins dans les applications Microsoft Word, Microsoft Works, Microsoft Visionneuse et OpenOffice.org permettent d’exécuter du code arbitraire à distance au moyen d’un fichier au format Word (.doc) spécialement conçu.

Le savoir-faire permettant d’exploiter cette vulnérabilité est largement publié sur l’Internet ainsi que des codes d’exploitation qui sont d’ores et déjà diffusés.

Le CERTA a été informé par l’un de ses correspondants de l’apparition sur ses passerelles de messagerie de documents exploitant cette vulnérabilité. Ces documents ont été détectés et identifiés par les passerelles anti-virales déployées sur ce même réseau. Selon les premières analyses des éditeurs anti-virus ce code d’exploitation tenterait de télécharger et/ou d’exécuter du code malveillant depuis l’Internet.

Le CERTA recommande de porter une attention toute particulière aux journaux d’événements des équipements réseaux (passerelles, parfeux, serveurs mandataires) qui permettraient de déceler toutes anomalies liées à cette vulnérabilité.

Informer le CERTA de tout incident relatif à l’exploitation de cette vulnérabilité.

2.2 Contournement provisoire

  • Utiliser un format de document alternatif tel que le format rtf (Rich Text File).
  • Utiliser un outil alternatif de visualisation et/ou d’édition des documents au format Word (Wordpad sous Microsoft Windows et Abiword sous GNU/Linux).
  • Mettre les bases de signatures d’anti-virus à jour.
  • Filtrer les documents au format Word au niveau des passerelles de périphériques (messagerie, HTTP).
  • Ouvrir uniquement les documents au format Word provenant de sources de confiance.
  • Utiliser un compte n’ayant pas de droit d’administration permet de limiter l’infection au contexte de l’utilisateur.
  • Sensibiliser les utilisateurs à informer leur RSSI (Responsable en Sécurité des Systèmes d’Informations) lorsque une erreur survient à l’ouverture d’un document au format Word.

3 Concernant le filtrage associé au trafic UDP

Il existe plusieurs procédés pour effectuer des traductions d’adresses (ou NAT pour Network Address Translation) permettant à des machines à l’intérieur d’un réseau d’accéder à l’Internet par le biais d’un ensemble d’adresses IP publiques. Les plus courantes font également une traduction au niveau des ports.

Il existe un protocole, décrit dans le RFC 3489, détaillant une méthode pour que deux machines, chacune dans un réseau différent, puissent communiquer entre elles en UDP malgré le NAT. Il s’appelle STUN (Simple Traversal of UDP through NAT), et s’utilise avec des applications comme Google Talk ou Skype.

Cette méthode peut permettre, sous certaines conditions, de contacter directement une machine se trouvant derrière un NAT, et peut donc être une violation à la politique de sécurité. Il est important de vérifier que les règles de filtrage, notamment celles liées à UDP, empêche ce scénario si celui-ci n’est pas autorisé.

En relation avec l’article précédent sur le filtrage, une solution pour contourner ce problème serait, indépendemment du NAT, de filtrer de manière restrictive et rigoureuse les connexions sortantes en UDP.

Rappel des avis émis

Dans la période du 11 au 17 décembre 2006, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :