Agence nationale
de la sécurité des
systèmes d'information
No CERTA-2007-ACT-037
| S . G . D . S . N Agence nationale de la sécurité des systèmes d'information |
|
Paris, le 14 septembre
2007 No CERTA-2007-ACT-037 |
Affaire suivie par :
CERTA
Objet : Bulletin d'actualité
2007-37
| 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-037 |
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-037.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-037/
Une approche fréquemment choisie par les administrateurs de réseau pour limiter les risques et les abus liés à la connexion à l'Internet consiste à restreindre les sites sur lesquels la navigationest autorisée. Ce principe de « liste blanche » filtre les adresses demandées au niveau d'une passerelle, et ne laisse sortir in fine que celles explicitement mentionnées dans la liste.
Les motivations pour développer de telles listes sont nombreuses. Parmi les plus mentionnées :
C'est le dernier point qui nous intéresse dans cet article.
Par principe, la liste blanche regroupe des sites dits de confiance. Cela peut inclure des sites administrés par les mêmes services, des sites de bonne réputation, ou des sites pratiques.
C'est à ce niveau qu'il faut avoir une extrême vigilance. Avoir une certaine confiance dans les sites autorisés ne garantit aucunement que des informations ne peuvent pas être échangés avec des sites interdits par le biais de sites de confiance. Avoir confiance et empêcher l'échange d'information sont deux considérations différentes.
A valeur d'illustration, un code a été rendu public cette semaine. En voici les détails :
Plusieurs méthodes permettent à une machine au sein d'un réseau de communiquer (envoi/réception) avec une machine arbitraire à distance, malgré une liste blanche. L'hypothèse de départ suppose que la liste blanche contient, dans le document publié, le domaine google.com. Les personnes dans le réseau ne peuvent donc accéder qu'à toute adresse réticulaire (URL) associée à ce domaine.
Pour contourner le principe de la liste blanche, une première solution consiste à appliquer l'outil de traduction Google Translate. La requête sera bien adressée au site de Google, mais ce dernier va accéder au site distant (interdit) pour demander la page à traduire. En d'autres termes, l'outil de traduction sert alors de relais pour accéder à d'autres sites.
Cela peut laisser des traces dans les journaux de la passerelle web, comme la chaîne particulière : via translate.google.com.
Cette technique n'est pas récente, mais suffit à contourner la politique de la liste blanche. Les auteurs ne s'arrêtent pas à cette méthode, et en proposent plusieurs autres :
uvre la liste blanche peut trouver
des indices d'une telle utilisation en cherchant dans les
journaux de la passerelle de connexion à l'Internet la
chaîne de caractères FeedFetcher-Google
ou l'adresse
http://www.google.com/feedfetcher.html.http://spreadsheets.google.com.
Il y a bien entendu plusieurs autres scénarios possibles, qui peuvent utiliser d'autres sites que ceux précédemment listés. Cette méthode n'est évidemment pas propre aux sites de Google. Il s'agit de la démonstration de faisabilité du code publié cette semaine.
La liste blanche posée en hypothèse semble restrictive, car limitée au seul domaine google.com. Toutefois, elle n'empêche pas, comme le code le démontre, les communications entre une machine interne et tout autre machine distante.
Affiner la liste blanche par des sous-domaines ne résoud pas nécessairement le problème, puisque certains services sont accessibles par des sous-répertoires (exemple : www.google.com/calendar).
Cet article a pour objectif principal de sensibiliser les utilisateurs de listes blanches. Il est important de comprendre ce qu'elles permettent de bloquer, et les moyens possibles de la contourner.
Une liste blanche ne suffit pas pour garantir que des informations ne sont pas échangées entre une machine interne et un site arbitraire distant.
L'élément clé reste l'analyse en profondeur des journaux des serveurs et des passerelles, en quête de ces contournements possibles.
Pour éviter les fuites de données vers l'Internet, la meilleure solution reste de ne pas se connecter à l'Internet. C'est la recommandation lorsqu'on manipule des données sensibles.
Cette semaine, le CERTA a émis l'alerte CERTA-2007-ALE-014 qui détaille une vulnérabilité non corrigée concernant Apple QuickTime et Mozilla Firefox.
La vulnérabilité exploite une option appelée QTNEXT du format multimédia QuickTime, qui permet de spécifier un fichier ou URL à lire après la fin du média en cours de lecture. Si l'option est spécifiée, l'application QuickTime appelle directement le navigateur par défaut de l'utilisateur. Dans le cas où le navigateur par défaut est Mozilla Firefox, celui-ci permet l'exécution de code Javascript sur le poste de l'utilisateur. Il est à noter que l'ouverture d'un fichier QuickTime via un navigateur alternatif n'empêche pas l'exploitation car cette application appellera tout de même le navigateur par défaut.
La désactivation du Javascript dans Mozilla Firefox (recommandation du CERTA) n'empêche pas l'exécution de ce type de code QuickTime, puisque Firefox n'est pas lancé avec les options de l'utilisateur. Les tests du CERTA ont montré que la dernière version du navigateur Netscape (9.0.b3) est également affectée ; en revanche les tests d'exploitation sur Seamonkey 1.1.4 n'ont pas fonctionné, mais il convient de rester prudent.
Quelques contournements provisoires sont possibles en attendant des correctifs :
Quelques options des modules (plugins) installés avec Firefox sont visibles par la commande about:plugins dans la barre d'adressage. Ces modules se trouvent sous forme de fichiers .dll dans
C:\Program Files\Mozilla\Firefox\plugins. Le simple fait de supprimer ceux associés à QuickTime n'empêche pas Firefox d'interpréter des documents multimédia par QuickTime.
Enfin, la désinstallation de l'application QuickTime reste le meilleur contournement jusqu'à la publication d'un correctif.
L'éditeur Mozilla a confirmé la vulnérabilité le jour-même de la publication de celle-ci, et annoncé qu'elle semble ne toucher que les postes sous Microsoft Windows. Un rapport de bogue a été créé pour tenter de résoudre le problème du côté de Firefox. L'éditeur a également annoncé qu'il travaille avec Apple, et il est donc probable que ce dernier publie également une mise à jour prochainement.
http:///www.certa.ssi.gouv.fr/site/CERTA-2007-ALE-014/index.html
http://blog.mozilla.com/security/2007/09/12/quicktime-to-firefox-issue/
https://bugzilla.mozilla.org/show_bug.cgi?id=395942
Il est possible avec Mozilla Firefox de ne pas utiliser les caches relatifs aux pages visitées ainsi que l'historique de navigation. Cependant, une rapide expérience avec la version 2 de Firefox montre que, même en mettant la taille de cache à 0 Mo et en désactivant l'historique, et après un arrêt de Firefox, celui-ci est tout de même capable de restaurer la session précédant l'arrêt. Les options proposées dans l'interface classique de configuration ne sont donc pas suffisantes pour garantir que Firefox ne stocke pas des informations sur la navigation. Il est cependant tout à fait possible de configurer Firefox de façon sûre : Il convient alors d'utiliser l'interface about:config et de régler des options comme :
La technologie Web est souvent utilisée pour administrer des services à distance. Par exemple :
Une personne malintentionnée qui accéderait par le biais d'une interface Web au compte d'un utilisateur chez un fournisseur d'accès, ou à la configuration d'un serveur Web, aurait accès à des informations sensibles, comme les différents mots de passes (mail, espace web, voix sur IP, accès au serveur, ...).
Il convient donc de faire très attention lors de l'utilisation de ce genre d'interface :
L'interface Web peut être une sur-couche destinée à apporter du confort à l'utilisateur, comme la présentation graphique d'un fichier de configuration ou d'options de commandes.
Ce confort apporte des risques, car il peut être lui-même source de vulnérabilités. Par exemple, le CERTA observe fréquemment dans ses analyses de journaux de serveurs web compromis des tentatives de connexions sur des URL propres à des versions vulnérables de l'interface Web phpmyadmin. Celle-ci gère des bases de données.
Ces interfaces d'administration via l'Internet doivent donc être traitées comme des services critiques en terme de sécurité.
Lors d'une opération de migration globale du serveur Web, un service a changé d'hébergeur et de nom de domaine. La rupture du contrat d'hébergement n'a pas déclenché un nettoyage par l'hébergeur. Il restait sur une de ses machines un site Web, avec des pages HTML, qui répondait aux requêtes HTTP. Il n'était toutefois plus maintenu.
L'abandon du nom de domaine ne s'est pas accompagné d'un nettoyage particulier dans le système DNS. Les tables DNS dirigent donc toujours les requêtes vers le site abandonné.
Deux inconvénients apparaissent alors :
Avant de quitter un hébergeur, le plus salutaire est de nettoyer soi-même son site. Il faut :
Il faut modifier le DNS pour que les requêtes soient dirigées sur la nouvelle adresse (le nouveau site). L'incident prouve l'importance de cette modification, même quand le nom de domaine doit bientôt être abandonné.
Le changement de nom de domaine doit s'accompagner de précautions décrites dans la note d'information du CERTA :
http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-001/index.html
Dans la période du 07 au 13 septembre 2007, le CERTA a émis l'alerte et les avis suivants :