CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2008-08
Gestion du documentLe bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-008.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-2008-ACT-008/ 1 Le filoutage ne cible pas que les banquesCette 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 :
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écemmentLe 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 DNSQuelles 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 VistaAvec 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 sortantL'activation du filtrage sortant peut se faire à plusieurs endroits.
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-feuLes 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 :
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 :
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 filUn 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 :
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 VLAN6.1 PrésentationUn 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éthodeDans 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 ConclusionPlusieurs méthodes pour éviter cette technique de saut sont possibles:
7 Moteurs de recherche : tests de vulnérabilités indirectsLes 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 :
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). 8 Rappel des avis émisDans la période du 15 au 21 février 2008, le CERTA a émis les avis suivants :
Pendant la même période, les avis suivants ont été mis à jour :
Gestion détaillée du document
CERTA 2012-01-04 |
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
