Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTA-2007-ACT-006

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 09 février 2007
No CERTA-2007-ACT-006

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2007-06


Conditions d'utilisation de ce document : http://www.certa.ssi.gouv.fr/certa/apropos.html
Dernière version de ce document : http://www.certa.ssi.gouv.fr/site/CERTA-2007-ACT-006

Gestion du document

Une 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-006.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-006/

1 Activités en cours

1.1 Compromission par filoutage

Les bonnes pratiques en cas de compromission par filoutage de votre site Internet :

Cette semaine le CERTA a été informé de nombreux cas de filoutage (ou phishing). Une machine compromise héberge, à l'insu de son propriétaire, la copie des pages Web d'un site légitime. Des victimes potentielles sont ensuite incitées à se rediriger vers cette machine (par courrier électronique par exemple) pour leur dérober des informations personnelles.

Le CERTA peut être amené à contacter le propriétaire de la machine qui héberge les pages malveillantes, afin de l'informer du problème.

Á de trop nombreuses reprises, la réponse trouvée est la suppression des fichiers douteux, soit directement, soit par le biais de l'hébergeur du site.

Le CERTA rappelle que, dans le cas d'une compromission, les fichiers présents sur le serveur Web sont des traces qui pourront être exigés par les autorités judiciaires dans le cas d'une plainte déposée par les responsables du site légitime qui a été copié.

Il est donc fortement recommandé de contacter son hébergeur afin de l'informer de la compromission du site Internet et de lui demander de prendre les mesures nécessaires à la préservation des données. La note d'information du CERTA (CERTA-2002-INF-002) sur les bons réflexes en cas d'intrusion peut vous aider dans vos démarches.

Documentation

http://www.certa.ssi.gouv.fr/site/CERTA-2002-INF-002
http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-005

1.2 Les changements de statuts, ou noms

Le CERTA a traité cette semaine la compromission d'un site Web. La cause en était la suivante : l'organisme détenteur a changé de nom et de statut. L'ancien site pointait donc vers le nouveau, hébergé sur une autre machine. Dans le même temps, la maintenance de la machine accueillant l'ancien site a été arrêtée. En d'autres termes, cette machine présente toutes les conditions favorables à une compromission, d'autant plus que celle-ci peut être abandonnée de la sorte pendant plusieurs mois, voire quelques années.

Dans ces conditions, il est important de prendre les précautions suivantes :

  • fixer une période pendant laquelle l'ancienne machine doit rester active ;
  • identifier une personne responsable de sa maintenance ;
  • limiter les services sur la machine à de simples pages Web redirigeant vers le nouveau site. Dans le cas de l'incident traité, la machine continuait à héberger un forum inactif par exemple. Celui-ci n'est pas indispensable, mais accroît les risques de compromission ;
  • modifier éventuellement le DNS pour faire pointer vers le nouveau site.

Très souvent, une simple page statique en HTML avec une redirection vers le nouveau site reste bien suffisante. Elle permet de limiter les installations et la maintenance de la machine (pas besoin d'installer PHP, la configuration du serveur Web peut être minimale, etc.).

Le CERTA invite les personnes ayant connaissance de tels sites à vérifier que ceux-ci répondent bien aux points mentionnés ci-dessus.

1.2.1 Recommandations concernant les sites orphelins

La situation précédente peut être vue comme un cas particulier de site orphelin.

De manière générale, comme il a été mentionné dans un précédent bulletin (CERTA-2006-ACT-052), les recommandations concernant les sites orphelins sont les suivantes :

  • maintenir la liste des responsables des sites, techniques (exploitation, administration, développement) et éditoriaux ;
  • assurer la redondance des personnes et les relais ;
  • documenter et maintenir le développement et les configurations ;
  • réviser périodiquement la configuration pour l'adapter aux utilisations et à la menace.

1.3 La gestion de l'affichage des messages d'erreur

Le CERTA a traité cette semaines deux cas d'incidents sur des serveurs Web. Ceux-ci présentaient aux personnes naviguant sur le site des messages d'erreurs, notamment PHP.

Les messages d'erreurs affichés sont dangereux, car ils fournissent beaucoup d'informations à une personne malveillante qui chercherait à s'introduire par le biais du site. Cela peut inclure les versions des applications ou bibliothèques, les fonctions mises en œuvre dans le code, la structure de la base de données contactée par le site, etc.

Il est donc fortement recommandé de vérifier que la configuration du site ne permet pas de tels affichages. Cela ne doit évidemment pas remplacer une surveillance fréquente des journaux.

A valeur d'illustration, il est possible dans le fichier de configuration php.ini (pour les versions supérieures à 4.0.3) de spécifier la variable suivante : display_errors (affichage des erreurs). Celle-ci est par défaut à "1", mais doit être positionnée à "0" quand le site devient opérationnel.

1.4 Cas d'un déni de service

Le CERTA a récemment traité un cas de déni de service qui a consommé toutes les ressources mémoire d'un routeur, suite à l'envoi massif de paquets TCP à destination d'une machine d'un réseau local.

On peut distinguer deux catégories de machines ciblées par les dénis de service :

  • les machines offrant un service sur l'Internet, par exemple les serveurs web ;
  • les machines déjà compromises utilisées à des fins malveillantes, par exemple des postes client sur lesquels tourne un bot irc et pouvant subir une contre-mesure dangereuse.

Lorsqu'un tel déni de service est constaté, il est suggéré d'isoler la machine ciblée et de procéder à son analyse pour vérifier si celle-ci est compromise. Le filtrage en sortie et l'examen du trafic réseau précédant l'attaque aident grandement pour vérifier la compromission de la cible du déni de service.

Dans le cas traité par le CERTA, aucun filtrage en sortie n'était mis en place et la machine ciblée a été réinstallée avant d'être examinée, ce qui ne permet pas d'analyser correctement l'incident.

1.4.1 Recommandations

  • filtrer correctement le trafic sortant suivant une politique restrictive par défaut. Il est vivement déconseillé de laisser par défaut tous les paquets provenant de machines internes sortir vers l'Internet ;
  • journaliser le trafic sortant, afin de constater les tentatives internes anormales de connexion vers l'extérieur : celles-ci peuvent indiquer la compromission de l'une des machines du réseau ;
  • débrancher la machine suspecte du réseau, pour bloquer ses agressions avec l'extérieur et préserver les traces ;
  • contacter son responsable de sécurité ou le CERTA.

2 La Saint-Valentin approche

La Saint-Valentin approche. Gare aux amoureux des... courriers électroniques malveillants ! Les courriels qui contiennent des fichiers malveillants, ou qui redirigent vers des sites malveillants (filoutage) doivent motiver les personnes à ouvrir la pièce jointe, ou cliquer sur un lien. Ils profitent donc généralement des thèmes de l'actualité, et de la sensibilité des personnes.

La fête de la Saint-Valentin se prête donc parfaitement à ce genre d'activité. Le CERTA recommande la plus grande prudence vis-à-vis des courriers électroniques reçus sur le sujet.

Ils peuvent être un vecteur de propagation de virus, chevaux de Troie, ou autres contenus malveillants. Il et donc nécessaire de maintenir la vigilance et de sensibiliser les utilisateurs. La note CERTA-2000-REC-002 rappelle quelques précautions à prendre lors de la réception de tels messages.

3 Bluetooth et le mode "découverte"

De plus en plus d'équipements, tels que les téléphones portables, les assistants personnels numériques et les ordinateurs (clavier, souris, haut-parleurs), sont équipés d'une interface Bluetooth afin d'interconnecter facilement et sans fil des appareils hétérogènes. La majorité des équipements dotés d'une connexion Bluetooth offrent une option appelée mode "découverte" qui permet de dissimuler ou non sa présence aux autres dispositifs Bluetooth à portée. Le fait de désactiver le mode découverte permet de se prémunir d'attaques opportunistes ou non ciblées, cependant cette action ne permet pas de se protéger contre un attaquant plus motivé. En voici les raisons :

Chaque interface Bluetooth dispose d'une adresse physique, ces adresses sont distribuées par plages aux industriels qui eux-même affectent des sous plages d'adresses à leurs différents équipements. Ainsi, un utilisateur malintentionné peut réaliser une attaque de type force brute et découvrir un appareil Bluetooth avec le mode découverte désactivé. Ce dernier répondra malgré tout à une requête lui étant explicitement adressée. Par conséquent, le fait de désactiver physiquement l'interface Bluetooth permet de se protéger des attaques déjà existantes et ciblant ces dispositifs.

De manière générale, l'interface de ces appareils communicants ne doit être solicitée que ponctuellement, et elle doit rester par défaut éteinte.

4 Problèmes liés aux protections contre le filoutage et contre les fenêtres intempestives

4.1 Protection contre le filoutage

Un problème concernant la protection contre le filoutage a été identifié sur toutes les versions de Firefox le supportant, y compris la version actuelle (2.0.0.1), ainsi que sur Opera 9.10. En effet, ces navigateurs ne reconnaissent pas des adresses répertoriées comme étant des sites de filoutage si des caractères « / » supplémentaires sont insérés comme séparateurs de répertoire.

Ainsi, si l'adresse http://www.site_filoutage.com/filoutage est répertoriée comme site de filoutage, l'adresse http://www.site_filoutage.com///filoutage n'avertira pas l'utilisateur qu'il est en train de naviguer sur un site apparemment malveillant (selon la liste noire maintenue).

Des mises à jour ne sont pas encore disponibles pour corriger cette vulnérabilité.

4.2 Protection contre les fenêtres intempestives, ou pop-ups

Une vulnérabilité été identifiée concernant le système de blocage des fenêtres intempestives de Firefox 1.5.0.9.

En temps normal, Firefox empêche un site Internet d'accéder à l'espace de nommage file://, qui correspond aux fichiers de l'ordinateur du client qui se connecte. Cependant, lorsqu'un utilisateur choisit consciemment d'ouvrir une fenêtre intempestive qui a été bloquée, le code source de cette fenêtre peut appartenir à cet espace de nommage. La pop-up a ensuite accès à l'espace file:// puisqu'elle est dans la même « zone ».

Ainsi, si un attaquant peut prédire le nom d'un fichier téléchargé pour l'appeler par la suite dans une pop-up, cela lui permettrait, via ce fichier qui a des droits sur la machine locale, d'accéder en lecture aux autres fichiers de l'ordinateur du client.

Cette vulnérabilité concernerait la branche 2.0 de Firefox.

5 Rappel des avis émis

Durant la période du 02 au 09 février 2007, le CERTA a émis les avis suivants :

  • CERTA-2007-AVI-065 : Multiples vulnérabilités dans Sun Solaris
  • CERTA-2007-AVI-066 : Vulnérabilité de Sun Solaris
  • CERTA-2007-AVI-067 : Multiples vulnérabilités de Wireshark (Ethereal)
  • CERTA-2007-AVI-068 : Multiples vulnérabilités de Samba
  • CERTA-2007-AVI-069 : Multiples vulnérabilités sous PostgreSQL
  • CERTA-2007-AVI-070 : Vulnérabilité dans Mambo
  • CERTA-2007-AVI-071 : Vulnérabilité de BlueCoat WinProxy
  • CERTA-2007-AVI-072 : Vulnérabilité dans WinRAR et RAR
  • CERTA-2007-AVI-073 : Vulnérabilités des produits Trend Micro
  • CERTA-2007-AVI-074 : Vulnérabilité dans Avast Server

Pendant la même période, les avis suivants ont été mis à jour :

  • CERTA-2007-AVI-020-002 : Multiples vulnérabilités dans Fetchmail

    (ajout de la référence au bulletin de sécurité RedHat)

  • CERTA-2007-AVI-055-003 : Vulnérabilité de GTK2

    (ajout de la référence au bulletin de sécurité Ubuntu)


Liste des tableaux

Gestion détaillée du document

09 février 2007
version initiale.


CERTA
2014-01-17
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2014-07-25