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.
Rappel des avis émis
Dans la période du 29 janvier au 04 février 2007, le CERT-FR a émis les publications suivantes :
- CERTA-2007-ALE-004-005 : Vulnérabilité dans Microsoft Office
- CERTA-2007-AVI-061 : Vulnérabilité de Drupal
- CERTA-2007-AVI-062 : Multiples vulnérabilités des produits Oracle
- CERTA-2007-AVI-063 : Vulnérabilité sur Sun Java System Access Manager
- CERTA-2007-AVI-064 : Vulnérabilité de la mise en œuvre ICMP par Sun Solaris
- CERTA-2007-AVI-065 : Multiples vulnérabilités dans Sun Solaris
Durant la même période, les publications suivantes ont été mises à jour :
- CERTA-2007-AVI-001-001 : Vulnérabilités dans Cacti
- CERTA-2007-AVI-002-001 : Vulnérabilité dans VLC media player
- CERTA-2007-AVI-035-001 : Vulnérabilités de Squid
- CERTA-2007-AVI-055-003 : Vulnérabilité de GTK2
