S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 26 septembre 2008
N° CERTA-2008-ACT-039
Affaire suivie par: CERT-FR
le 26 septembre 2008

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-39

Gestion du document

Référence CERTA-2008-ACT-039
Titre Bulletin d’actualité 2008-39
Date de la première version 26 septembre 2008
Date de la dernière version 26 septembre 2008
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Incidents traités cette semaine

Cette semaine, le CERTA a été informé d’un incident touchant un site Internet de l’administration, hébergé sur plusieurs serveurs pour des raisons de trafic important. Un intrus a pu se connecter à la page d’administration du site car le mot de passe utilisé était faible. La page était normalement accessible uniquement depuis certaines adresses IP via des ACL (Access Control List). Toutefois, l’un des serveurs n’était pas configuré correctement et, contrairement aux autres, ne filtrait donc pas les accès via ces ACL.

Cet incident montre tout d’abord l’intérêt de la défense en profondeur : un moyen de protection ne justifie pas de ne pas en avoir d’autres en aval (dans ce cas précis, l’utilisation d’un mot de passe fort même s’il y a un filtrage sur les adresses IP).

De plus, cet incident met l’accent sur des problèmes de configuration dans des systèmes redondants où il faut bien s’assurer que chacun dispose des mêmes moyens de protection.

La problématique associée à cet incident est relativement courante. Le CERTA avait par exemple traité, il y a quelques semaines, un problème lié à l’existence d’un serveur de secours mal sécurisé qui était accessible depuis l’Internet contrairement à ce qui était préconisé par la politique de sécurité de l’organisme.

D’une manière générale, de nombreux organismes ont recours à la réplication de données et/ou de services (serveurs pour supporter la charge, serveur de secours en cas de panne, etc.). Toutefois, les aspects de sécurité sont parfois absents de ce processus. Lors de la préparation et de la maintenance de tels serveurs, il est donc important de veiller à l’application des règles de sécurité définies par la PSSI, par exemple :

  • règles de filtrage ;
  • mises à jour ;
  • utilisation de mots de passe différents ;
  • changement régulier des mots de passe ;
  • etc.

2 Mise à jour du navigateur Mozilla Firefox

Le CERTA a publié cette semaine l’avis CERTA-2008-AVI-473 signalant l’annonce de plusieurs avis de sécurité pour des produits Mozilla.

Certains d’entre eux concernent les versions du navigateur de la branche 3.0.X :

  • MFSA 2008-40 : une page malveillante peut abuser de l’opération de « clic » sur le bouton d’une souris pour forcer l’utilisateur à télécharger ou déplacer des objets plutôt que de se déplacer à l’adresse du lien. Cette vulnérabilité nécessite l’activation de JavaScript, et en particulier l’option avancée « Autoriser les scripts à : Déplacer ou redimensionner des fenêtres existantes » ;
  • MFSA 2008-41 : certaines vulnérabilités permettent à des scripts JavaScript d’exécuter du code arbitraire avec les droits attribués à chrome et donc au navigateur ;
  • MFSA 2008-42 : le rendu d’images ne serait pas correctement géré, pouvant entraîner, dans certaines conditions, une corruption de la mémoire ;
  • MFSA 2008-43 : la marque d’ordre des octets BOM (Byte Order Mark) n’est pas correctement manipulée avec un code JavaScript, pouvant ainsi permettre de contourner certaines politiques de filtrage de scripts ;
  • MFSA 2008-44 : le protocole resource: n’est pas correctement manipulé. Il pourrait être exploité pour accéder illégitimement à des répertoires. Ce protocole avait déjà fait l’objet de correctifs (cf. section 4, CERTA-2007-ACT-020).

La première remarque consiste à rappeler le bon usage d’un navigateur Internet : il faut bloquer par défaut toute exécution de code dynamique et ne l’autoriser que ponctuellement sur des sites de confiance.

La seconde remarque concerne la mise à jour et le passage du navigateur en version 3.0.2. Ce passage semble poser problème à l’outil de gestion de mots de passe, qui n’arriverait pas à récupérer correctement certains d’entre eux pour des sites dont le nom de domaine associé contiendrait des caractères autres que ceux appartenant au jeu ASCII.

Cette vulnérabilité incite les développeurs Mozilla à publier une nouvelle version, la 3.0.3 dans les prochains jours. Celle-ci fera l’objet d’un nouvel avis du CERTA.

Ce problème permet néanmoins de rappeler qu’il est préférable de ne pas stocker les mots de passe localement sur le poste. Celui-ci peut être compromis et fournir l’accès à toute la liste de mots de passe. Une note d’information abordant la gestion des mots de passe se trouve sur le site du CERTA : CERTA-2005-INF-001.

Pour conclure cet article, le CERTA rappelle également que Mozilla a annoncé ne plus maintenir les correctifs de sécurité et de stabilité de la branche 2.0.0.X du navigateur à partir de mi-décembre 2008. La migration doit d’ores et déjà être préparée.

3 Les publications de sécurité Cisco

Le CERTA a publié cette semaine l’avis CERTA-2008-AVI-474. Ce dernier reprend l’ensemble des avis de correctifs de sécurité des produits Cisco publiés le 24 septembre 2008. Les correctifs sont relativement nombreux.

Comme cela avait été annoncé dans le bulletin d’actualité CERTA-2008-ACT-011 du 14 mars 2008, les mises à jour de sécurité pour Cisco Internetwork Operating System (IOS) s’effectuent maintenant deux fois par an, dont l’une dans le courant du mois de septembre (le quatrième mercredi de mars et de septembre pour être précis).

Ce mois-ci douze avis de sécurité ont ainsi été publiés, corrigeant seize vulnérabilités. L’exploitation de ces vulnérabilités se fait au moyen de paquets spécialement construits puis émis à distance. Il s’agit de vulnérabilités associées à la gestion de protocoles de voix sur IP (Skinny SCCP, SIP) mais aussi de plus courants comme DNS, HTTP ou SSL, ainsi que le mécanisme d’encapsulation et de commutation de données MPLS dans une architecture VPN.

Les conséquences des exploitations sont principalement des dénis de service.

La vulnérabilité CVE-2008-3803 peut quant à elle provoquer une fuite d’information. Certains équipements PE (Provider Edge) configurés pour des VPN MPLS ou VRF Lite (Virtual Routing and Forwarding) ne gèrent pas correctement les communautés étendues BGP. Lorsque celles-ci sont utilisées, le trafic peut être détourné vers une cible de routage (RT ou Route Target) différente.

Le CERTA rappelle à cette occasion que les équipement de réseau dits Intrusion Prevention Systems (IPS) et les filtres des couches applicatives (comme Cisco Application Inspection Control) peuvent être exposés aux trames malveillantes et ne sont pas moins vulnérables que d’autres systèmes. Dans le cas d’un déni de service, c’est non seulement le service de filtrage/détection qui n’est plus rendu, mais c’est potentiellement tout le trafic transitant par l’équipement qui peut être ainsi bloqué.

Il est donc important de considérer ces équipements de sécurité comme des éléments pouvant aussi avoir un impact sur l’accès à plusieurs services en aval.

4 Mandataire transparent et serveurs DNS publics

Figure 1: Fonctionnement classique d’un mandataire avec DNS public
Image Proxy-Normal-sansDNS
Figure 2: Fonctionnement classique d’un mandataire avec DNS cache interne
Image Proxy-avecdnsinterne
Figure 3: Fonctionnement d’un mandataire transparent avec DNS public
Image Proxy-Transparent-sansDNS
Figure 4: Fonctionnement d’un mandataire transparent avec DNS cache interne
Image Proxy-Transparent

Le principal avantage d’un serveur mandataire web (proxy) est de se substituer aux clients réels d’un réseau local pour effectuer des requêtes, généralement HTTP vers des serveurs publics de l’Internet (cf. 1).

L’inconvénient de ce genre de technologie est l’obligation pour le navigateur (ou le client de manière générale) de supporter cette fonctionnalité et l’obligation d’indiquer au navigateur l’adresse de ce mandataire pour communiquer avec l’extérieur plutôt qu’avec l’extérieur directement. Dans le cas des mandataires HTTP, non seulement la requête vers le serveur web sera effectuée par le « proxy », mais aussi ce dernier s’occupera de la résolution de nom (DNS). Les postes clients n’ont pas besoin de connaître un serveur DNS. Ils doivent simplement disposer de l’adresse du serveur mandataire vers lequel seront envoyées les requêtes. L’idéal consiste à avoir un serveur DNS interne qui mettra en cache les requêtes du serveur mandataire (cf. 2).

Ainsi, sur un parc important, il conviendra de prévoir une politique de diffusion de configuration de navigateur pour qu’ils puissent prendre en compte cet aspect de l’architecture réseau.

Un inconvénient est qu’un utilisateur peut éventuellement modifier la configuration et passer outre le serveur proxy. S’il existe une politique de filtrage des flux vers l’Internet, il ne pourra plus surfer mais, en l’absence d’une telle politique, il pourra directement naviguer sur l’Internet sans passer par le mandataire.

Une solution envisageable est d’utiliser un mandataire transparent. Cette technique consiste à rediriger les flux « à mandater » vers le mandataire par le biais d’un pare-feu configuré de façon particulière. Ainsi, un flux (typiquement le HTTP : 80/tcp) sera mandaté, quel que soit la configuration des clients.

Cependant dans ce cas de figure, un cache DNS local devient indispensable pour garantir un bon cloisonnement du réseau. En effet, si les clients utilisent un serveur DNS public pour effectuer la résolution de nom, on aura un double requêtage DNS, l’un fait par le client et l’autre fait par le mandataire (cf. 3). En effet, comme la redirection du flux « mandaté » se fait de façon transparente pour le client, ce dernier devra disposer d’une configuration DNS a priori valide car indispensable à une requête HTTP (on doit connaître l’adresse IP de la machine avant de lui demander une page web).

Il est donc indispensable de disposer d’un serveur cache DNS interne pour garantir un bon cloisonnement lorsque l’on met en œuvre un système de mandataire transparent. Certes, le double de requêtes DNS sera nécessaire à un bon fonctionnement (une du client, une du mandataire), mais aucun flux direct vers l’extérieur ne sera nécessaire (cf. 4).

5 Fausse croyance sur les portées du Bluetooth

Dans la note d’information CERTA-2007-INF-003, publié le 01 août 2007, le chapitre 4.2 faisait mention du savoir-faire disponible sur l’Internet et permettant d’augmenter la portée de réception et/ou d’émission d’un équipement Bluetooth initialement limité à 100m dans sa dernière version.

Un équipementier a récemment commercialisé une interface Bluetooth permettant d’obtenir une portée effective de 100m. Dans sa meilleure configuration, la portée peut atteindre environ 30km (selon le type d’antenne, son gain et l’environnement).

Cette information s’inscrit dans la continuité des risques liés à l’usage des technologies sans-fil et surtout Bluetooth, à savoir que le faux sentiment de sécurité créé par la notion de communication de courte portée n’est pas fondé. Ceci oblige l’utilisateur à rester vigilant lors de l’utilisation de la technologie Bluetooth. Il n’a pas (ou très peu) de maîtrise sur les interactions qu’il peut y avoir entre un élément extérieur et son interface. il doit la désactiver physiquement par défaut.

6 Des en-têtes qui vous desservent

L’année dernière, le CERTA a publié dans son bulletin CERTA-2007-ACT-014 quelques recommandations concernant la réponse automatique aux demandes d’accusés de réception des courriers électroniques. Il était écrit que le renvoi de ces accusés de réception peut participer à de la fuite d’information.

Un exemple concret de fuite d’information par ce biais vient d’apparaître ces dernières semaines. En effet, quelques spam utilisent cette fonctionnalité afin de valider la lecture du courriel par une personne physique. Ceci permet aux auteurs de campagnes de courriels non sollicités de confirmer les adresses destinataires et de créer des statistiques précises sur ces adresses (type de client de messagerie, affichage de code HTML, nom précis de la personne, etc.).

Techniquement, cela repose sur l’insertion d’un champ MIME optionnel dans l’en-tête du message non sollicité : X-Confirm-Reading-To. Ce champ est considéré comme champ optionnel dans les différentes RFC caractérisant les en-têtes mail.

Deux solutions peuvent être appliquées. La première, centrée sur le poste de travail, consiste à configurer les clients de messagerie afin de ne pas répondre automatiquement à ce genre de message. Pour cela :

  • dans Microsoft Outlook : Outils -> Options -> Options de la messagerie -> Option de suivi : vérifier que l’option toujours envoyer une réponse n’est pas cochée ;
  • dans Mozilla Thunderbird : Edition -> Préférences -> Rédaction -> Général -> Accusé de réception : vérifier que l’option toujours envoyer n’est pas cochée.

La deuxième consiste à supprimer de l’en-tête l’option X-Confirm-Reading-To au niveau du serveur de messagerie entrante. Cette disposition spécifique ayant un impact réel sur la production doit cependant être réfléchie et rester en accord avec la politique de sécurité. Il n’est en effet pas anodin de filtrer ou supprimer un champ pourtant prévu dans une RFC, même s’il s’agit d’un champ optionnel.

Rappel des avis émis

Dans la période du 15 au 21 septembre 2008, le CERT-FR a émis les publications suivantes :


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

Gestion détaillée du document

    le 26 septembre 2008
    version initiale.