Aug 31 2009

Le gouvernement suédois interdit le mot banque (Bank) dans les noms de domaines n’appartenant pas à des banques

Tag: newsArrouan @ 12:06 pm

Il est courant que les gouvernements de part le monde insiste sur le faite qu’une compagnie ne peut pas se nommer une banque si c’en n’est pas une officielle et controlée. Malgré cela, il n’est pas rare de voir des sociétés utilisant le mot “banc” au lieu de banque (bank) pour éviter de telles législations.

La Suéde a décidé d’aller plus loin en interdisant aux registrars (i.e. les organismes fournissant les noms de domaine) fournissant les .SE qu’ils ne peuvent pas vendre de noms de domaine contenant le mot “banque” sauf si c’est une banque officielle. Bien sur, il y a des raisons légitimes de vouloir le mot “banque” dans son nom de domaine même si on est pas une banque. Par exemple, une association de clients d’une banque ou autre.

Mais, il ne faut pas oublier que la vaste majorité des utilisations de mot banque dans un nom de domaine quand la société derrière n’est pas une banque est pour des utilisations frauduleuses et particulièrement du fishing. Est-ce que cela aura une incidence sur le phishing ? Il y a peu de chances puisque ce n’est qu’une législation local. Appliquer à un niveau international, cela pourrait peut être ralentir le phishing même si j’ai de fort doute dessus. En effet, il suffirait de prendre un nom de domaine comme oftheamerica.com puis de créer le sous domaine bank.oftheamerica.com pour passer outre la législation qui prend en compte uniquement les noms de domaines et pas les sous domaines de ces derniers.

Inspiré par Techdirt


Aug 20 2009

Brower as a OS: La proposition Gazelle de Microsoft

Tag: conference, news, rechercheArrouan @ 12:30 pm

The multi-principal OS construction of the Gazelle Web Browser est un papier publié à USENIX Security par une équipe commune Microsoft Research, University of Illinois et University of Washington. Leur papier décrive l’architecture qu’ils proposent pour un navigateur plus sécurisé et plus résistant aux nombreuses attaques qui existent actuellement quand vous surfez sur des simples pages Internet.

On peut dire que Gazelle est la réponse de Microsoft à plusieurs technologies de Google qui sont rassemblée dans Google Chrome (et Google Native Code). Le but dans les deux cas n’est plus de voir le navigateur comme un gros programme d’affichage de pages mais comme un OS dédié à la navigation. Dans ce cas, le navigateur est séparé en plusieurs processus qui sont controlés par un noyau.

Le noyau comme le noyau d’un OS se charge de la communication entre les différents composants et processus mais aussi gére l’interface avec les ressources systèmes. En compartimentant les différents pages vu simultanéement i.e. avec un processus par tab, si une page plante ou est corrompu, le problème sera limité à une page et pas la totalité de celle actuellement affichée.

Cette méthode a été rendu grand public par Chrome mais d’autres browsers expérimentaux comme OP ou Tahoma proposaient déjà des structures similaires.

La différence entre Gazelle et Chrome est au niveau de la finesse de séparation entre les différents domaines Internet. Le but est toujours d’éviter au maximum que des données d’un site soit lu par un autre et la séparation jusqu’au rendu de la page est essentielle. La même chose doit être appliquée pour les plugins qui sont de plus en plus source de problèmes.

Pour conclure, Gazelle est un très beau principe qui  promet une meilleur sécurité au niveau du navigateur. Des inconnues restent comme le principe de sandboxing pour éviter qu’un processus corrompu perturbe le système ou la gestion des plugins mais leur idée est très intéressante.  Avec la montée des applications web et des données de plus en plus sensibles qu’elles traitent la sécurité du navigateur est un point essentiel et l’un des plus attaqués actuellement. Il est probable que de telles architectures tentent à se démocratiser dans les années à venir pour ce genre de logiciel.


Aug 19 2009

Une nouvelle méthode de détection de malware

Tag: conference, news, rechercheArrouan @ 5:34 pm

Les auteurs de “Effective and Efficient Malware Detection at the End Host” publié à USENIX Security 2009 sont partis du faite qu’il y a de plus en plus de malwares et qu’ils collaborent de plus en plus entre eux. De plus, les antivirus actuelles se basent essentiellement sur les signatures qui sont facilement contournées en utilisant du polymorphisme  ou de l’obfuscation. D’autres méthodes, plus marginales, se reposent sur l’analyse des séquences d’appels systèmes générés par un programme mais sont contournable en changeant de manière légére la séquence de ces appels. Finalement, des méthodes ont été proposées afin d’extraire des comportants globaux à une famille de malware pour les bloquer d’une manière plus efficace, mais ces méthodes ne sont pas assez rapide pour fonctionner en temps réel. Le but des auteurs est donc de proposer un système qui va réellement pouvoir détecter les derniers malwares actuelles et tout cela en temps réel.

Leur système permet tout d’abord de générer automatiquement un modèle du malware ou de la famille de malware. Ce modèle se base sur des informations très compléte du comportement du malware. Contrairement à la détection par signature, où souvent seulement un hash du malware est utilisée pour la détection ou de la détection par séquence d’appels systèmes où cette dernière doit être respecté pour que la détection fonctionne, le modèle conserve l’intégralité des informations relatives au comportement du malware et pas uniquement une partie. D’après les auteurs, cela permet d’éviter les risques de non détection quand les malwares utilisent l’obfucation ou le polymorphisme. Ils ont ensuite développer un scanneur qui permet de faire correspondre un modèle à un programme inconnu. Pour cela, il se base sur la dépendance entre des appels systèmes.

L’une des nécessités que se sont imposée les auteurs dès le début, c’est que leur système ne devait pas incorporer de connaissances au début mais plutôt les développer au fur et à mesure. En effet, il devient tellement simple de générer des nouveaux malwares que toute connaissance preliminaire est caduc très rapidement. Bien entendu, les auteurs ne peuvent qu’admettre que dans ce cas, il faut qu’un malware soit analysé au moins une fois pour que son modèle soit généré et détecté par la suite. Il faut donc que le malware soit détecté par un tier, puis analyser par le système de génération de modèle pour pouvoir servir à la détection. Les auteurs précisent que ce n’est pas nécessaire pour chaque malware et chaque déclinaison de celui-ci grâce à leur modèle qui permet d’avoir des informations précises.

Afin d’améliorer leur système, leur analyse se base sur l’analyse d’un sous ensemble qualifié d’intéressant de syscall qui pourraient réellement aider à la détection de malware. Une fois les syscall collectés, ils les utilisent pour créer un graphe orienté qui va lié deux noeuds i.e. deux syscalls si les données générées par le premier sont utilisées en entrée par le second.

Leur système fonctionne plutôt bien quand il s’agit de détecter des malwares et des variantes de ces derniers qu’il a déjà analysé. D’après les tests fournis par les auteurs, le taux de détection est de 90% avec un taux nul de faux positif. Mais dès qu’il s’agit d’analyser des variantes inconnus le taux de détection chute à seulement 25%. Leur système se basant sur des modifications du système pour pouvoir monitorer, analyser et bloquer des programmes au niveau noyau, un driver ainsi qu’un certain nombre de programme ont été développé. L’overhead est relativement faible 10% pour ce qui est du CPU mais il monte rapidement pour les entrées/sorties et 40% pour des tâches complexes comme une compilation.

Pour conclure, leur système est intéressant car il permet effectivement une bonne détection de comportement des malwares en se basant sur l’observation des liens entre syscalls. La méthode permet donc d’éviter les problèmes d’obfuscation, de polymorphisme mais aussi de changement d’ordre des syscalls. Par contre, leur méthode ne détecte que péniblement les variantes d’un malware déjà connu et ne détecte pas à l’avance des inconnus. Le système est donc en effet une progression par rapport aux systèmes existants mais a encore de grave lacune pour qu’ils soient utilisables.


Aug 19 2009

Génération automatique de tests de détection de la virtualisation

Tag: conference, news, rechercheArrouan @ 4:13 pm

Pouvoir détecter si un système est virtualisé ou non est utilisé pour deux raisons majeurs: tout d’abord pour détecter si un malware accéléré hardware de type BluePill est installé sur la machine mais aussi pour les programmeurs de malware de vérifier que leur programme ne tournent pas dans un environnement virtualisé. Mais pourquoi ce deuxième point est important ? Parce que la plupart des personnes analysant les malwares pour générer des signatures qui vont permettre aux antivirus de détecter le malware utilisent des outils d’analyse comportementale qui sont inclus dans des logiciels de virtualisation. En pouvant détecter la virtualisation, les malwares peuvent donc rester plus longtemps sans être détecter.

La proposition des auteurs (R. Paleari, L. Martignoni, G. F. Roglia et D. Bruschi) du papier “A fistful of red-pills: How to automatically generate procedures to detect CPU emulators” publié à USENIX Security 2009 est de lancer une série d’instructions dans l’environement virtualisé et les mêmes dans un environement normal. En analysant la différence, ils sont capable de générer automatiquement des outils de détection de la virtualisation (i.e. les fameux redpill). Ils ont réussi à générer automatiquement près de 21 000 redpils pour QEMU et 3000 pour BOCHS.

La découverte automatique d’instructions n’ayant pas les même retour entre un CPU réel et un CPU virtualisé est fait en se basant sur le programme EmuFuzzer.