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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-08

Gestion du document

Référence CERTA-2008-ACT-008
Titre Bulletin d’actualité 2008-08
Date de la première version 22 février 2008
Date de la dernière version 22 février 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 Le filoutage ne cible pas que les banques

Cette semaine, le CERTA a rencontré un grand nombre de sites de filoutage dirigés contre les utilisateurs de MSN et Hotmail. Ces pages frauduleuses ont été déposées à la suite d’une compromission ou simplement téléchargées sur des sites web ouverts spécifiquement. Le but de ces filoutages semblait être de récupérer les informations de connexion des utilisateurs des sites MSN ou Hotmail.

Le CERTA a pris contact avec les hébergeurs pour fermer au plus vite l’accès à ces pages frauduleuses.

Le CERTA rappelle que le filoutage (ou phishing) ne cible pas que les organismes bancaires. Cet incident illustre très bien l’étendue des possibilités de ce type de fraude. Même s’il n’est jamais évident de connaître les motivations des attaquants, elles peuvent être les suivantes :

  • voler des informations personnelles ;
  • usurper l’identité des victimes pour réaliser des méfaits avec le nom de ces dernières ;
  • changer les mots de passe de ces comptes pour réaliser un chantage sur les victimes ;
  • revendre ces comptes à des organisations criminelles ;
  • etc.

Le CERTA rappelle qu’il est préférable de consulter ses courriers au format texte et qu’il ne faut jamais cliquer sur un lien présent dans un courrier électronique. Il est préférable d’écrire soi-même l’adresse de la page désirée dans la barre d’adressage de son navigateur pour éviter les liens masqués ou ambigus, notamment dans les courriels.

Documentation

2 Surveiller le trafic DNS, une nécessité

2.1 Une étude publiée récemment

Le CERTA a mentionné dans certains bulletins d’actualité l’existence de codes malveillants cherchant à modifier la configuration DNS des postes infectés. L’un des codes, nommé DNSChanger a été présenté dans le bulletin CERTA-2007-ACT-052.

La valeur NameServer de la base de registres prime toute valeur qui pourrait être fournie par le serveur DHCP. Sa modification est donc une compromission grave.

La nouvelle configuration fait pointer les requêtes des machines compromises vers des serveurs DNS illégitimes et non maitrisés. Ceux-ci sont normalement configurés en mode « ouvert et récursif ». Ce méfait ne vise donc pas directement les serveurs DNS en exploitation.

L’utilisateur a peu de moyens pour détecter ce changement de comportement et pour douter de la réponse DNS reçue.

Une étude récente a été menée sur presque l’ensemble des adresses IPv4 publiques accessibles, afin d’identifier et de quantifier les serveurs illégitimes ou en mode « ouvert récursif » (configuration déconseillée).

17 millions de serveurs récursifs ouverts distincts ont ainsi été recensés. Il s’agit de serveurs autorisant quiconque sur l’Internet à les interroger. Parmi un échantillon de 600.000 d’entre eux, 2% envoient visiblement des réponses erronées et 0,4% redirigent vers des proxys anormaux. Une extrapolation sommaire de tous ces chiffres amène à environ 300.000 machines dans l’Internet fournissant des réponses incorrectes ou malveillantes. Ces informations sont conformes à d’autres listes noires obtenues par d’autres biais (relais de spam, machines infectées par le ver Storm, etc.).

Les motivations sont diverses : il peut s’agir de redirections pour afficher des publicités dans le navigateur ou une interprétation d’une erreur de nom de domaine (erreur de frappe au clavier). La précédente redirection peut également diriger vers des sites de filoutage ou des sites ayant des codes exploitant des vulnérabilités par l’intermédiaire du navigateur.

Il ne s’agit pas dans cet article de valider, critiquer ou infirmer les chiffres présentés dans l’étude menée. Il faut retenir que ce problème lié au DNS est bien concret et présente un risque.

Documentation

2.2 Surveillance du trafic DNS

Quelles actions peuvent être entreprises par un administrateur de réseau ?

Les flux DNS sortants du réseau interne doivent être correctement contrôlés. Seuls les serveurs DNS légitimes internes peuvent par exemple initier des requêtes vers leurs homologues dans l’Internet. Les machines ne doivent pas faire cette opération directement. L’observation dans les journaux du pare-feu de telles tentatives est un signe d’une potentielle compromission.

Il est également important de surveiller dans le réseau les requêtes DNS qui circulent, et en particulier les serveurs qui sont destinataires de ces requêtes.

3 Le pare-feu de Windows Vista

Avec la sortie de Windows Vista, Microsoft a inclus un nouveau pare-feu dans son système d’exploitation.

La grande nouveauté du pare-feu est la possibilité d’effectuer du filtrage sortant. Cette fonctionnalité n’est toutefois pas activée par défaut, même si la présence de règles prédéfinies peut laisser penser autrement.

3.1 Activation du filtrage sortant

L’activation du filtrage sortant peut se faire à plusieurs endroits.

  • dans les stratégies de groupe : exécuter gpedit.msc. Choisir ensuite Configuration ordinateur, Paramètres windows, Paramètres de sécurité, Pare-feu windows avec fonctions avancées de sécurité.
  • dans la configuration du pare-feu : aller dans Panneau de configuration, Outils d’administration, Pare-feu windows avec options avancées de sécurité.

La stratégie de groupe, même locale, prévaut sur la configuration de l’ordinateur.

On peut voir les options générales du pare-feu, configurables, en suivant le lien Propriétés du Pare-feu Windows.

Dans la nouvelle boîte de dialogue, il est possible de paramétrer le filtrage par défaut du pare-feu pour chaque configuration de réseau : privé, public ou domaine. Ainsi, pour activer le filtrage sortant, il faut y mettre l’option Refuser. De même, pour le filtrage entrant, on peut confirmer la valeur par défaut en y mettant l’option Bloquer. Il est également possible de bloquer complètement toutes les connexions entrantes, ou les autoriser.

Enfin, on peut y choisir d’afficher un message d’avertissement pour indiquer si des applications ont été bloquées (uniquement pour les connexions entrantes), et configurer la journalisation du pare-feu.

3.2 Configuration des règles du pare-feu

Les options Bloquer pour le filtrage entrant et Refuser pour le filtrage sortant refusent toute connexion qui n’est pas explicitement autorisée dans les règles du pare-feu.

Les règles du pare-feu peuvent être configurées aux mêmes endroits que les options générales du pare-feu. Il en existe deux types : les règles de trafic entrant et les règles de trafic sortant. On peut créer quatre types de règles : programme (on choisit l’exécutable autorisé à communiquer), ports, prédéfinie ou personnalisée. Toutes les règles sont en fait configurables à souhait par la suite, sauf pour les règles prédéfinies.

Voici les différents paramètres applicables à une règle :

  • protocole ;
  • ports locaux et distants ;
  • adresses IP distantes et locale ;
  • type d’interface (réseau local, sans-fil…) ;
  • profil (public, privé, domaine) ;
  • chemin de l’exécutable ou nom du service ;
  • nom d’ordinateur ;
  • activer ou désactiver la règle, et bloquer ou autoriser les connexions.

Un exemple de règle est ainsi d’autoriser l’exécutable firefox.exe à communiquer en sortie vers les ports TCP distants 80 et 443.

Il est important de remarquer que la règle ci-dessus suffit et qu’il n’est pas nécessaire de configurer une règle de flux entrant équivalente. Le pare-feu Windows autorise en effet tout flux entrant relatif à une connexion sortante établie (comme l’option established d’iptables sous Linux). Il n’est pas possible de changer cela. Même une règle de filtrage entrant interdisant explicitement à l’exécutable firefox.exe de communiquer ne fonctionne pas si nous autorisons un flux en sortie pour cet exécutable.

Il est recommandé de désactiver toutes les règles par défaut du pare-feu et de les réactiver ou de créer des règles personnalisées par rapport aux besoins voulus. Pour une navigation usuelle en HTTP / HTTPS, il faudra par exemple créer une règle similaire à celle décrite ci-dessus, et activer la règle prédéfinie de filtrage sortant pour le DNS.

Enfin, pour autoriser les mises à jour Windows :

  • créer une règle personnalisée de filtrage sortant ;
  • choisir l’exécutable 
    c:\windows\system32\svchost.exe
    ;
  • dans Personnalisé, choisir Appliquer à ce service et le service Windows Update ;
  • confirmer la boîte de dialogue en choisissant « oui » ;
  • choisir le protocole TCP et les ports distants 80 et 443 ;
  • choisir d’autoriser la connexion et donner un nom à la nouvelle règle.

Documentation

4 Une protection des données privées plutôt paradoxale !

Des sites Internet proposent des outils et méthodes ou une veille attentive afin de limiter la propagation de données personnelles et privées sur l’Internet.

Certains de ces sites sont cependant douteux lorsque l’on examine d’un peu plus leurs modes de fonctionnement. En effet, il arrive que ces sites lancent une quantité impressionnante de JavaScript vers d’autres sites ou installent de nombreux cookies. Ces sites se permettent en fait de récolter des données et de les diffuser à de nombreux sites distants à l’insu du visiteur.

Ces méthodes de récolte d’informations peuvent être rapprochées des données enregistrées et transmises par les outils de statistiques de fréquentation des sites comme le rappelait le bulletin d’actualité CERTA-2007-ACT-041 du 12 octobre 2007.

Le CERTA recommande donc de bien prêter attention à la qualité de ces sites qui, en prétendant offrir un service, des outils ou de l’information afin de limiter l’envoi de données personnelles sur l’Internet, en profitent pour subtiliser un maximum d’informations à ces visiteurs et pour les envoyer vers des sites distants. Il est également important de se poser la question de la confiance et de la crédibilité que l’on peut accorder à de tels sites, même si ceux-ci prétendent traiter de sécurité et se soucier des données personnelles.

Documentation

5 Le partage de connexions sans fil

Un article publié récemment faisait état d’une petite plaisanterie faite par le propriétaire d’un point d’accès Wi-Fi à son voisin s’y étant connecté à son issu. Le propriétaire a en effet entrepris d’inverser toutes les images des pages demandées au cours d’une navigation par la personne connectée sans son accord. Il fournit également gracieusement le code de manipulation des images sur sa page web publique. Malgré l’aspect « bénin » de cette farce, il est possible d’utiliser le même code pour insérer du code malveillant ou du contenu illicite dans les pages visitées par le voisin. Outre le caractère amusant de cette anecdote, le CERTA tient à rebondir sur ce fait divers pour rappeler certaines recommandations et obligations, que l’on soit client d’un accès Wi-Fi ou fournisseur :

  • lors d’une connexion à un point d’accès sans fil ouvert, il est important de garder en tête que l’on ne dispose pas de la maîtrise de ce point d’accès. Le propriétaire peut donc à l’insu des utilisateurs filtrer, enregistrer ou manipuler les données transitant par le réseau. Il suffit d’installer des serveurs proxy ou des passerelles pour rediriger et modifier tout ou partie des requêtes et réponses. Il est donc très important de rester très vigilant quant aux données que l’on va échanger via un réseau ou un point d’accès inconnu ou non maîtrisé ;
  • il existe également des obligations pour les fournisseurs de ces points d’accès. Le code des postes et des communications électroniques stipule que les fournisseurs d’accès à des réseaux de communication électronique ont dans l’obligation de conserver les traces des activités des utilisateurs pendant un an glissant. Les mêmes contraintes pourraient être mises en place pour tous les autres acteurs de l’Internet dans un projet de réactualisation du code ;
  • les actions entreprises par les personnes externes au réseau ne sont pas toujours maîtrisées. Dans le cas où une personne n’ayant pas d’arrière pensée malveillante laisse son point d’accès ouvert, sa connexion peut être exploitée à de mauvaises fins par des tiers. Il est donc important de retenir que c’est la personne propriétaire de la connexion qui sera la première inquiétée en cas de problème.

Le CERTA tient donc à attirer l’attention sur les risques inhérents à l’utilisation d’un tel type de moyen d’accès à l’Internet et les obligations légales à respecter lors de la mise à disposition de ces moyens d’accès au public.

6 La VOIP et le saut de VLAN

6.1 Présentation

Un VLAN (Virtual Local Area Network) est un procédé défini dans la norme Ethernet 802.1q, pour isoler logiquement plusieurs réseaux. Il est utilisé entre autres pour diviser un réseau accueillant le trafic de téléphonie sur IP et celui des données classiques. Il permet la mise en place d’une qualité de service (QoS). Il permet aussi, normalement, de sécuriser le réseau en cloisonnant les services et les appareils y accédant. Un saut de VLAN consiste à accéder illégitimement à un flux, par exemple en faisant passer un ordinateur pour un téléphone.

6.2 Méthode

Dans un déploiement de téléphonie sur IP les combinés sont associés à un VLAN et certains modèles utilisent le protocole CDP (Cisco Discovery Protocol) pour se déclarer automatiquement. En branchant un ordinateur et en analysant les paquets Ethernet multicast il est possible de trouver l’identifiant de VLAN utilisé (VVID).

En configurant une interface réseau avec le bon VVID il est possible de demander une adresse IP via le DHCP du VLAN. Si elle est obtenue, alors le saut est réussi. En effet une requête DHCP sans avoir spécifié de VLAN positionnerait par défaut la machine dans le réseau de données alors que là, elle est identifiée dans le VLAN de la téléphonie. Ensuite, la liste des machines et services atteignables dépendra de la configuration réseau globale. Dans certain cas, l’absence de séparation ou de contrôle entre les réseaux voix et données permet d’accéder à toute l’infrastructure du réseau testé.

6.3 Conclusion

Plusieurs méthodes pour éviter cette technique de saut sont possibles:

  • activer le filtrage par les adresses MAC pour contrôler les appareils se connectant ;
  • utiliser le protocole 802.1x, l’accès aux ports d’un switch nécessitant alors des identifiants ;
  • cloisonner les réseaux, en particulier si des terminaux de téléphonie sont non surveillés et placés dans des locaux publics.

7 Moteurs de recherche : tests de vulnérabilités indirects

Les moteurs de recherche offrent souvent l’occasion d’optimiser les recherches au moyen d’expressions régulières ou de raccourcis. Ces services, forts utiles, peuvent également servir à des fins plus malveillantes, afin de trouver plus rapidement un ensemble de sites indexés et souffrant d’une vulnérabilité commune.

L’expression Google Hack a été attribuée à ces opérations dans le moteur de recherche Google. Des sites et des documents proposent logiquement les « formules » adaptées, ainsi que les trucs et astuces pour optimiser les requêtes. Des vulnérabilités sont par exemple régulièrement publiées sur des composants utilisés pour construire un site. Ces vulnérabilités sont exploitables en commençant par trouver les sites utilisant ces composants. Si l’indexation du site trahit leurs présences, alors ils apparaîtront dans des résultats de moteur de recherche de la forme :

        search: page_caract�ristique_du_module_vuln�rable + site:.fr

La recherche se limite ici aux seuls sites .fr.

Des sites listent ces requêtes. Récemment, l’un d’entre eux propose une interface pour tester à partir de ces requêtes si un domaine ou un site particulier est présent dans les résultats du moteur de recherche. Cette opération peut être vue comme une recherche de vulnérabilités indirecte, où le moteur de recherche sert d’intermédiaire pour identifier les vulnérabilités du site visé.

Comme tout outil lié à la sécurité, ces applications peuvent être considérées comme un danger, ou moyen complémentaire de tester la robustesse de son site. Néanmoins, cette méthode présente différents inconvénients qu’il est important de connaître :

  • l’interface s’installe sur le poste de l’utilisateur. Une fois le nom du site cible entré, l’interface génère un très gros volume de requêtes vers le moteur de recherche pour identifier si le site ressort dans le résultat de certains « hacks ». Le moteur de recherche n’est pas complètement passif, et peut considérer qu’il s’agit d’un abus du service rendu, et donc bloquer l’accès au domaine ou au service pour cette adresse. Si cela est gênant pour un particulier, cela le sera encore davantage dans le cas d’un réseau NATé.
  • les requêtes sont servies à l’utilisateur à partir des « hacks ». Il s’agit de détection de vulnérabilités exprimées sous forme de signatures. Les résultats retournés sont sujets à des faux-positifs et des faux-négatifs, dont la proportion n’est pas estimée a priori.
  • les « hacks » effectués ne sont pas directement visibles. Seule l’interprétation du résultat apparaît. Ils ne sont cependant pas tous pertinents.

Ce genre d’interface est dangereux, mais présente l’avantage de confirmer l’importance de mettre à jour et de surveiller les journaux des sites. Ces activités peuvent parfois être visibles en observant les champs Referer dans les journaux, ou en testant directement les tentatives dans le moteur de recherche, après avoir considéré les effets de bord que cela peut engendrer.

Cette méthode indirecte est assez pernicieuse, car la recherche de vulnérabilités est effectuée par le moteur de recherche. L’administrateur du site ne peut y faire grand chose, le filtrage de domaine ou d’adresse n’y faisant rien. Il peut éventuellement limiter les indexations faites par un fichier robots.txt par exemple.

La meilleure garantie de non compromission de son site réside dans une mise à jour sérieuse des applications utilisées, et une limite raisonnable des modules et autres logiciels atteignables par des requêtes externes (modules des gestionnaires de contenus en particulier).

Rappel des avis émis

Dans la période du 11 au 17 février 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 22 février 2008
    version initiale.