SecFault.Org

Deux chercheurs viennent de mettre en évidence une faille de sécurité permettant de générer un autorité de certication SSL valide.

Ils ont pour cela utilisé 200 PS3 en réseau pour trouver une collision dans l’algorithme MD5 utilisés pour la signature de certificat.

Concrètement, cela permet de générer des certificats SSL valide pour n’importe quel site Web. Si un attaquant à accès aux flux réseau entre le navigateur Web et le serveur, il pourra usurper l’identité du serveur Web distant.

Il est toutefois important de noter que cela nécessite une puissance de calcul important, et que les détails techniques permettant la reproduction n’ont pas été révélés.

D’autres scénarios d’exploitation plus critique sont envisageables, comme la signature d’applet Java permettant d’exécuter du code coté client.

Il n’existe pas de correctifs pour cette vulnérabilité actuellement.

Un workaround possible serait d’enlever les certificats racines utilisant des signatures MD5, cela aurait comme effet secondaire de casser la chaine de certification SSL.

Lien vers le PPT de la présentation:

http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt

Site de démonstration (volontairement généré avec un certificat expiré):

https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/

Après avoir lu plusieurs blogs et news sur Google Native Client, j’ai voulu en savoir plus. Mais n’ayant pas le courage de me plonger tout de suite dans le code, j’ai préféré d’abord lire le papier de recherche fourni par Google. Au passage, si quelqu’un trouve que ce papier a été publié et où ca m’intéresse mais ca n’a pas l’air d’être le cas.

Les auteurs commencent par rappeller que pour faire des calculs ayant des grosses demandent de ressource comme les scenes 3D ou tout ce qui est physique des objets solide et liquides, les langages comme JavaScript ne sont pas adapté. Que même si ActiveX ou NPAPI permet de faire tourner du code natif, c’est au détriment de la sécurité ou en repoussant la sécurité entre le clavier et la chaise ce qui pose souvent de grave problème. Pour eux, l’idée d’utiliser les ressources allouées au navigateur pour faire tourner du code natif d’applications webs est une mauvaise idée.

Alors comment fonctionne leur idée. Tout d’abord, il faut installer un plugin Native Client qui est en faite une sandbox ayant un accés total au système. Ce plug-in tourne dans un processus propre et n’est donc pas liée au navigateur. Les applications webs tourneront dans le plug-in qui intéragit lui-même via des API avec la navigateur et le système. Il est donc possible de concevoir des interfaces en JavaScript qui utiliseront du code natif dans Native Client pour accélerer certains traitements. Par exemple, ajouter des fonctions avancées de traitement d’image dans picassa.

Au final, Native Client ressemble très fortement à un microkernel. Native Client étant la base et l’interface et qui accepte des nouvelles extensions de confiance étendant ses possibilités. Par exemple, il est possible de créer des extensions de confiance qui permettront après à des applications webs d’utiliser le stockage sur le disque. Ce n’est pas l’application qui le fait directement, tout passe par des API.

Mais tout ça ne me rassure que partiellement sur la sécurité de leur architecture. Dans la suite du papier, ils introduisent la notion de double sandbox (une sandbox dans une sandbox). La première sécurité (la sandbox interne) est une première chose qui a l’air vraiment intéressante car elle utilise de l’analyse statique de code (x86 ici) pour détecter et interdire des instructions non sur. En pratique, ils vérifient que les executables inclues uniquement des instructions qu’ils ont qualifié de legales. La seconde sandbox se trouve à l’extérieur et vérifie que l’ensemble des syscalls de Native Client vers le système sont autorisées en les comparant à une courte liste de syscalls (46 dans leur tests). En résumé, l’architecture est donc composé d’une première sandbox qui vérifié la qualité du code et qui appelle une API interne. Puis une seconde sandbox qui vérifie que ce qui sort de l’API vers le système est également valide. Ils utilisent une double analyse dynamique et statique bien que les 2 soient relativement limité car utilisant uniquement des whitelists.

Après ce premier point, il en ressortque la surface d’attaque est assez vaste: la sandbox interne qui fait de la validation de binaire, la sandbox externe qui joue comme un wrapper et intercepte les appels systèmes envoyés à l’OS, les bibliothéques, les interfaces de communications avec les autres modules, le système et le navigateur.

La sandbox interne a été testé via des outils de fuzzing et grâce à un code de seulement quelques milliers de lignes, ils ont réussi une implémentation rapide et sécurisé. La sandbox externe fonctionne en utilisant ptrace et en interceptant chaque syscalls et en le vérifiant contre une whiteliste. Pour certains syscalls comme open, ils vérifient également les arguements pour vérifier que ceux-ci sont aussi autoriser (par exemple ouverture de la lib ld.so).

Avec ces systèmes de sandboxing + des API, il y a forcement un overhead. Ce dernier est tout de même relativement faible entre 12 et 5% ce qui est tout à fait acceptable. Pour tester les performances, ils se sont amusées à porter en Native Code un ensemble de logiciel comme Quake.

Alors? Au final, je trouve que l’idée est plutôt bonne même si l’utilitée est vraiment à prouver. En effet, pour contourner les problèmes des applications webs, on en fait des applications ce qui est un peu un retour au début de la boucle. Mais pourquoi pas ce principe peut être intéressant pour développer les possibilités des applications et leurs puissances sans en complexifier l’utilisation pour l’utilisateur final.

Après je trouve leur idée allant dans le bon sens mais je ne comprends pas pourquoi ils ne les ont pas pousser un peu plus. Sans être un spécialiste du domaine, je suis sur que des travaux beaucoup plus avancés sur l’analyse de code ont été faite que la comparaison avec une whiteliste. De plus, pourquoi comparer les binaires quand la comparaison de code source est tellement plus efficace. Bref, pourquoi ne pas utiliser des logiciels comme FramaC ou d’autres alternatives pour vérifier la qualité du code. Le temps d’analyse sera surement plus long mais de meilleurs qualités et il est toujours possible de l’externaliser (sur un nuage par exemple).

Deuxième point, le contrôle via ptrace des syscalls, alors la pour le coup, c’est vraiment mon domaine et la whiteliste même si elle est intéressante et très limiter. De plus, leur approche ne peut pas résisté à des attaques d’intégrité et/ou de confidentialité complexes incluant des séquences de syscalls. En effet, ils analysent syscall par syscall sans avoir une vue d’ensemble. Mon idée serait d’étendre leur implémentation de ptrace pour le support de label de sécurité à la SELinux (ou d’autres systèmes comme ceux de RSBAC ou GRSecurity) et de mettre en place un système de contrôle d’accés mandataire complet implémentant des fonctions un peu avancée comme le type enforcement. Pour réussir à contrôler les séquences, il faudra des logiciels de prévention des intrusions comme ce qui est développé dans le cadre de l’ANR SEC&SI pour les bureaux graphiques permettant l’accés à Internet.

Biensur, cela va forcément augmenter l’overhead du à l’utilisation de Native Client mais cela peut être minimiser avec une borne achitecture de pre-calcul de la sécurité du code et des droits d’accés de celui

Finalement, en étendant la structure actuelle de Native Code pour remplacer leur analyse statique par des fonctions plus avancés (pouvant très bien être décentraliser sur une grille ou autres nuages) et en appliquant un contrôle d’accés stricte via des propriétés de sécurité (par exemple, tel module ne doit pas pouvoir modifier l’intégrité de tel fichiers ou la confidentialité de tel autres ou l’intégrité d’un autres processus, etc), il serait possible d’avoir un système beaucoup plus résistant aux attaques surement nombreuses et très avancées qui ne manqueront pas d’être développer si cette plateforme à un jour un succés (regarder flash, le pdf, etc).

Google vient de rendre disponible une version expérimentale d’un plug-in pour navigateur web permettant à des applications webs de tourner de manière sécurisé en utilisant du code natif. Ce nouveau plug-in appellé Native Client est distribué sous GPL et est fait pour fonctionner avec la plupart des plateformes et navigateur.

En pratique, Native Client fournit un bac à sable spécialisé pour le web permettant l’exécution de binaires x86. Il fournit également des outils pour faciliter la communication entre JavaScript et les exécutable Native Client. Le but est clairement de permettre aux applications webs complexes de pouvoir faire tourner les parties de code demandant beaucoup de puissance directement en natif alors que le reste restera une application web classique.

Bien entendu, le problème principal de ce genre de solution est que faire tourner du code natif améne à un niveau de risque de rupture de sécurité beaucoup plus grande. Il suffit de regarder ActiveX et le nombre d’exploit qui existent et qui sortent régulièrement. Il ne faudrait pas ajouter un nouveau vecteur d’attaque sur des systèmes qui en ont clairement pas besoin de ça actuellement.

Bien entendu, Google a annoncé que son modéle de sécurité était beaucoup plus robuste que ActiveX et que les fonctions de signature via un système de confiance était de bien meilleur qualité. En gros, d’après Google, on passe avec ActiveX d’une structure où l’utilisateur prend les décisions (et donc il doit prendre les bonnes) et encore où cela ne suffit pas à un système où il n’est pas possible de telles choses même avec un module corrompu. Alors la clairement, devant le peu de clareté, à part, on fait mieux que les autres, il est légitime de se poser des questions sur la réelle qualité de leur implémentation et de leur modéle.

Mais en faisant plus de recherches (en lisant le papier que les développeurs chez Google ont écrit), il est possible de se faire une meilleur idée du fonctionnement interne de Native Client. En effet, ce framework consiste en un ensemble de module qui sont ou de confiance ou à qui on ne fait pas confiance. Chacun a son propre processus et communique avec les autres via un système de RPC (Remote Procedure Call: Appel de procédure à distance i.e. ce qu’utilise NFS par exemple). Chaque module qui n’est pas de confiance est écrit en utilisant un langage particulier permettant de faciliter les intéractions avec les modules de confiance. Ce sont ces derniers qui vont réellement faire les intéractions avec la plateforme sous jaceante (aussi bien le réseau que les contrôles d’accés pour les systèmes de fichiers). Ce containeur (qui est au final proche d’une jail) permet d’imposer des contraintes quand au comportement du module ne disposant pas de confiance et permet également aux utilisateurs de définir de manière précise les permissions qui sont données à ce containeur.

#include <stdio.h>
#include <string.h>
#include <nacl/nacl_srpc.h>

/* Return a clever string. */
int HelloWorld(NaClAppArg **in_args, NaClAppArg **out_args) {

  /* Strdup must be used because the SRPC layer frees the string passed to it. */
  out_args[0]->u.sval = strdup("hello, world.");
  return RPC_OK;
}

/* Export the method as taking no arguments and returning one integer. */
NACL_SRPC_METHOD("helloworld::s", HelloWorld);

// helloworld is invoked when its button is pressed.
function helloworld() {
  try {
    alert(document.getElementById('pluginobj').helloworld());
  } catch(e) {
    alert(e);
  }
}

I Reference

Title: RSA EnVision Remote Password Disclosure
URL: http://www.secfault.org/?p=78

II. BACKGROUND

RSA EnVision, a product of RSA Security, is a platform allowing gathering and analysis of security events and logs.

RSA Security is a subsdiary company of EMC Corporation.

III. DESCRIPTION

The RSA EnVision platform provides a web console which enables administration of the solution and  analysis of security events.

A vulnerability exists in this web application, allowing a remote anonymous attacker to retrieve the hash of the password used for authentication.

Using a dictionnary or a bruteforce attack against this hash, a remote attacker can gain administration privilege on the EnVision web console.

This vulnerability is due to a lack of access control on the user profile functionnality.

Step to reproduce:

The step to reproduce the vulnerability will be disclosure Novembre 28 2008.

IV. IMPACT

Successful exploitation allows remote attackers to gain access to hash of password used to authenticate users of the web console.

Using a dictionnary or a bruteforce attack against the retrieved hash, a remote attacker can gain administration privilege on the EnVision web console.

V. PRODUCT AFFECTED

The vulnerability was sucessfully exploited on enVision v3.7.0 Build: 0169.

EMC has reported the following versions to be affected:

RSA EnVision 3.5.0, 3.5.1, 3.5.2 and 3.7.0

VI. REMEDIATION

Apply the vendor patch corresponding to your version of RSA EnVision:

https://knowledge.rsasecurity.com/

VII. DISCLOSURE TIMELINE
10/30/2008 Initial vendor notification
10/31/2008 Initial vendor response
11/21/2008 Patch release and coordinated public advisory disclosure
11/28/2008 Detailed vulnerability information disclosure

VIII. VENDOR REFERENCE

EMC Security Alert (ESA) identifier : ESA-08-017

IX. CREDIT

This vulnerability was discovered by Nicolas Viot <nicolas.viot@intrinsec.com>
Intrinsec is a french company specialized in business continuity and security : http://www.intrinsec.com

Un petit boitier produit par TrueCall doit permettre de lutter contre le “cold calling”, par exemple, le téléphone sonne une fois, vous rappellez, c’est un numéro surtaxé. Je pense que tout le monde a eu ce genre de coup de fil ou de sms du même gabari.

Le système est relativement basique et utilise des méthodes déjà bien connu. Tout simplement, il intercepte tous les appels que vous recevez. Puis si il reconnait le numéro comme un ami (i.e. qu’il est dans la whitelist), il les laisse passer normalement. Si le numéro est sur la liste blacklist par exemple des sociétés de télémarketing, le boitié répond à l’appel et tous les autres aussi et leur envoit un message automatique.

Si le numéro n’est pas reconnu dans l’une des deux listes, la personne qui appelle doit laisser son nom. Puis le téléphone de la personne ayant le boitier reçoit le nom et décide ou non de répondre.

Des mises à jour automatique des listes via un serveur centrale est prévu mais pas encore possible pour l’instant du à des problèmes de législation.

Au final, ce boitier pour un prix de 99£ ne fournit qu’une téchnologie très basique et sans réelle innovation. Ce n’est qu’une évolution très mince par rapport à un affichage du numéro et deux secondes de réflexion et tout ça pour 99£, je trouve ça un peu élevé.

Par contre, le spam téléphonique et SMS se développant, des produits de ce type en software sur les nouveaux types de téléphone (iPhone, Android, etc) pourraient devenir de plus en plus courant et développer un nouveau secteur.

Une jolie faille vient de sortir.

Il s’agit d’éxécution de code (PHP) pour un  utilisateur authentifié.

L’advisory (présent ici) nous indique le vecteur d’attaque suivant:
server_databases.php?pos=0&dbstats=0&sort_by="]) OR exec('cp $(pwd)"/config.inc.php" config.txt'); //&sort_order=desc&token=[valid token].

En allant voir dans les sources les modifs effectués (visible ici si vous êtes curieux), on peut y voir les changements suivants:

$sort_function = '
return ' . ($sort_order == 'ASC' ? 1 : -1) . ' * ' . $sorter . '($a["' . $sort_by . '"], $b["' . $sort_by . '"]);
';
usort($databases, create_function('$a, $b', $sort_function));


On voit que la chaine “sort_function” est construite par concaténation de chaine, et ceux avec une entrée utilisateur (le paramètre $sort_by).

La fonction usort est ensuite utilisé pour créer trier le tableau $database. Elle prend en deuxième argument une fonction de comparaison.

Elle est créer à la volée par la fonction “create_function”, elle même utilisant une chaine contaténée utilisant une entrée utilisateur non filtrée depuis une entrée utilisateur …

Le code ainsi créer va donc être éxécuter à chaque comparaison lors du tri.

Morale de l’histoire:

1/ Ne faites pas confiance aux entrées utilisateur

2/ N’utiliser pas de fonction permettant de créer du code à la volée

3/ Patchez !!!!

McAfee Inc. vient d’annoncer McAfee Artemis Technology qui n’est ni plus ni moins qu’un antivirus dans le “cloud”. En effet, c’est un service internet héberger par McAfee et qui permet une protection active à la volée quand un ordinateur est infecté. D’après McAfee, cela permet de réduire considérablement le temps de distribution des signatures d’un nouveau malware mais aussi celui de l’analyse des nouveaux malwares ce qui est essentielle vu le nombre impressionant de nouveaux malwares. Même les fournisseurs et constructeurs d’antivirus l’admettent, ils ne peuvent plus suivre le rythme.

L’un des problèmes (même si pour moi c’est loin d’être le principal) est qu’il faut réussir à mettre à jour la base de donnée de signatures sur l’ensemble des machines disposant de l’antivirus. Et cela, à chaque fois, qu’un nouveau malware est découvert. Ce mécanisme provoque un temps de latence entre le moment de découverte du malware et l’application de la protection chez le client.

Avec leur nouvelle méthode, McAfee analyse comportementalement les processus et si l’un se comporte comme un malware alors une signature est fait du fichier et elle est envoyer dans le nuage de Artemis. Cela permet à McAfee d’analyser plus vite le risque et de proposer plus rapidement une protection et l’envoyer immédiatement à l’ensemble des clients finaux. De plus, de par le rassemblement d’informations dans le “cloud”, il est possible de comparer le malware avec plus d’informations que ce qu’il se trouve sur un ordinateur client classique ou même une entreprise.

D’après McAfee, l’ensemble de ce processus de détection, identification et protection se fait en quelques millisecondes et le malware est comparer avec des bases de connaissances propres de McAfee mais aussi les résultats d’honeypots et les informations provenant de l’ensemble des systèmes protégés par McAfee.

Bien entendu, un des gros problèmes de ce produit est qu’il va envoyer une masse d’informations plus ou moins critiques sur les machines sur lequel il est installé vers le “cloud”.

Sorti de l’effet buzz, il sera intéressant de voir en réalité l’efficacité d’un tel produit. Mais malheuresement, tout ce système se base sur les mêmes “vieilles” habitudes en terme de détection et d’antivirus et n’amène pas de nouvelles méthodes qui permettraient de réellement détecter les nouveaux malwares ou tout du moins de pouvoir s’en protéger. C’est dommage que les éditeurs d’antivirus continuent à s’acharner sur les méthodes de détection par signatures et qu’ils n’explorent pas de nouvelles voies. Mais, il ne faut pas leur en vouloir, c’est tout de même leur buisness model de vendre des mises à jours continues et une dépendance de leur client vis à vis de leurs serveurs.

L’Institut de Recherche en Informatique faisant parti de la fondation de recherche grécques FORTH ainsi que l’institut de recherche sur l’informatique et la communication de Singapoure ont publié un article très intéressant où ils tentent de prouver les nouveaux risques et malwares que pourraient se créer dans les réseaux sociaux.

Les auteurs de l’étude définissent un Antisocial Networks comment étant un système distribué se basant sur les réseaux sociaux et pouvant être exploité par des attquants et diriger pour coordonner des attaques réseaux. Mais ils ne se limitent pas à discuter de ce qu’est un tel type de réseau, ils ont implémenté dans la réalité de tels attaques et montrent comme ces plateformes sociales peuvent être utiliser pour lancer des attaques. Ils se sont limités à Facebook pour développer leur concept d’attaques mais cela peut être étendu à l’ensemble des réseaux sociaux disposant d’une possibilité d’extensions par des tiers personnes.

Mais pourquoi les réseaux sociaux ? Tout simplement parce que de plus en plus de personnes sont inscrites sur ces réseaux, ce qui représentent une base de donnée énorme. De plus, ces réseaux sont découpés en groupe de centre d’intérêt ce qui permet de simplement localisé des cibles. Et finalement, par défaut, les utilisateurs ont tendance à faire confiance à leurs réseaux sociaux ainsi que les applications qui s’y trouvent. L’ensemble de ces raisons montrent la capacité de nouvelles attaques qui peuvent avoir lieu sur de tels sites.

Ce principe d’utilisation du web et des utilisateurs pour lancer des attaques n’est pas nouveau, Puppetnets, proposé en 2006, est également une attaque utilisant les mêmes principes. L’idée est de créer une page avec des milliers de liens pointant vers le serveur cible. Quand un utilisateur va charger cette page, son navigateur va télécharger des milliers de liens et provoquer une sur-charge sur le serveur cible. De plus, si cette page devient virable (un “Slashdot effect” par exemple), le serveur cible va se retrouver sous un DDoS. Bref, une technique simple et efficace pour lancer un DDOS a très faible cout. En ajoutant un peu de Javascript, pour des chargements multiples des liens, la méthode devient encore plus efficace.

Bien que les auteurs aient faire leur expérimentation sur le vrai réseau Facebook, ils n’ont pas développé des fonctions trop invasive (par exemple, l’obligation d’inviter 20 amis a essayé l’application avant de pouvoir l’installer, ce qui semble une méthode classique pour augmenter la popularité d’une nouvelle application) pour éviter de perturber le fonctionnement de Facebook pour les utilisateurs légitimes. Le principe de leur application était d’afficher une nouvelle image tous les jours en provenance du site du National Geographic. Mais également, quatres frames caché qui chargeaient pour 600Kb depuis le serveur de la cible à chaque fois qu’un utilisateur utilisait l’application. Bien sur dans le cadre de leur étude, le serveur était hébergé dans le lab et isolé du reste du réseau.

Bien que la méthode utilisé était relativement simple et pas trop invasive et avec une publicité limitée (i.e. uniquement quelques personnes de la communauté de la sécurité), l’application est rapidement arrivée à plusieurs centaines d’utilisateurs (plus de 1 000 utilisateurs avaient installé l’application en quelques jours) provoquant des pics d’utilisations de bande passante sur le serveur cible allant de 2Mb à 6Mb (entre 100 et 350 requêtes HTTP par second). Ils ont également analyser la provenance des requêtes (i.e. où se trouvent géographiquement l’utilisateur facebook) et on peut voir une répartition mondiale assez propre (ce qui risque de poser des problèmes pour la mise en place de contre mesures).

Ensuite, les auteurs ont voulu évaluer la puissance d’attaque d’une telle application dans la réalité et avec l’ensemble des facteurs qu’ils n’avaient pas voulu utiliser pour éviter de perturber le fonctionnement de Facebook et des utilisateurs. Par exemple, pour des applications ayant 1 millions d’utilisateurs ou plus, il faut s’attendre à des DDoS constants de 23Mbit/s soit 248Gb par jour. Ici, il ne faut pas voir uniquement la quantité de donnée mais le nombre de requêtes HTTP que va devoir résoudre le serveur cible et c’est cela qui risque d’être le point faible (et également celui de rupture).

Maintenant que le risque est prouvé (et pas uniquement limiter à des attaques de type DDoS, ces applications/malware facebook pourrait aussi être utiliser pour scanner des ordinateurs, propager des malwares, etc), les auteurs proposent plusieurs méthodes pour mettre en place des contre-mesures vis-à-vis de telles attaques. Leur première proposition pour se prémunir contre de tels attaques est tout simplement refusé tout traffic entrant ayant comme champ de référée du paquet HTTP facebook.com. Mais cela est relativement simplement contournable. L’une des autres méthodes est “tout simplement” que les créateurs de réseaux sociaux écrivent des API pour les applications qui soient propres et sécurisées et qu’ils vérifient la qualité et le risque des applications qu’ils hébergent.

Pour conclure, il est clair que ce type d’attaque pourrait arriver et que coupler avec une campagne virale, elle pourrait faire beaucoup de mal. Il est également possible d’imaginer une telle attaque ayant pour but de créer une sorte de botnet reposant sur des applications facebooks. Mais je ne trouve pas plus convaincant que ça ce type d’attaque pour des attaques massives car clairement pas assez puissants et temporaires (cela ne marche que le temps que l’utilisateur est sur la page de l’application) mais elle pourrait très bien servir pour de la distribution de malware et/ou de la vol de donnée personnel. Un vecteur d’attaque qu’il faudra surveiller vu l’importance que prennent les réseaux sociaux aussi bien dans la vie privée que dans l’entreprise.

Ce speach fait à la Black Hat USA 2008 par Rafal Wojtczuk (Invisible Things Lab) a pour but de présenter deux attaques sur l’hyperviseur Xen: une dans le code de Xen et une autre dans un domaine caché. La motivation de l’auteur est de dire que dans quelques années tout le monde aura un hyperviseur par défaut sur son ordinateur. Il n’a pas faux car, par exemple, Dell commence à fournir par défaut sur ses serveurs VMWare dans une ROM donc je peux imaginer dans quelques années que dans une puce, un hyperviseur soit disponible par défaut (il faut bien les utiliser tous ces coeurs). De plus, si il est possible d’attaquer ces hyperviseurs alors on se retrouve avec le même cas de figure qu’avec le virus Bluepill.

La première méthode d’attaque est de modifier depuis le système contenant l’hyperviseur (le Linux “maitre”) la mémoire contenant les informations à propos de Xen. Normalement un tel accés est protégé, mais en utilisant une technique similaire à celle présenté à SSTIC et permettant d’éxecuter du code via un iPod, l’auteur propose ici de s’attaquer au DMA et au carte réseau pour récupérer des valeurs en mémoire. La deuxième méthode utilise la possibilité de créer des domaines (et donc des machines virtuelles) qui peuvent espionner les autres et donc modifier leur données mémoires en temps réels.

Ces deux méthodes sont bien décrites et semblent tout à fait réalisable mais Xen n’est que peu utiliser actuellement. Des attaques de ce type sur VMWare seraient intéressante à voir également mais il n’empêche que les méthodes proposées ici utilisent  des concepts généric de la virtualisation est pourrai être utiliser sur d’autres hyperviseur.

Déjà quand on commence à parler de Cloud Computing, je ne peux m’empêcher de penser au soit disant Web 2.0, un nom totalement marketing, alors est-ce le cas ici ? Déjà, on peut en douter, la présentation de cette outil a été faite lors de USENIX Security 2008 par J. Oberheide, E. Cooke, F. Johanian de l’Université du Michigan. Leur but est de combiner une dizaine d’antivirus et deux applications de détection comportementale et de fournir l’ensemble de cette détection comme un service de type Cloud Computing. Le client n’a donc qu’à installer un petit client léger pour le service et le serveur se charge des outils de détection. D’après leurs études, il est possible d’avoir une réelle meilleur détection (35% de plus) en utilisant leur méthode. Cette méthode, ils l’ont expliqué lors de leur présentation.

Pour motiver leur travail, ils sont parti de deux faits: tout d’abord, il y a de plus en plus de virus et il devient presque impossible de tous les détecter dans le meilleur délais, mais aussi, les antivirus deviennent de plus en compliquer et deviennent des vecteurs d’attaques. Leur solution se base sur deux points forts pour éviter ces problèmes: tout d’abord, l’antivirus comme un service, où chaque machine ne fait plus tourner un antivirus mais fournit le fichier à analyser et qu’un serveur ‘dans le cloud’ se charge de l’analyser. De plus, ce serveur ne fait pas tourner une version d’un antivirus mais plusieurs antivirus et outils de détection afin d’atteindre le meilleur niveau de détection. Les quatres avantagesde leur solution sont:

• une meilleur détection
• des capacités de forensic i.e. le serveur peut garder une trace de qui a analysé tel fichiers à tel heure.
• des possibilités de savoir dès l’arrivée d’une nouvelle signature qui avait été infecté et résoudre le problème (en gardant trace des fichiers que chaque client a envoyé).
• facilitation de la mise en place et de la maintenance grâce à un service déporté dans le “cloud”.

Leur architecture se découpe en trois composants majeurs: un client léger, un service web de réception des fichiers et un service d’archive et de forensic qui garde les informations à propos des fichiers analysés. Ils ont implémenté et testé ce système pendant 1 an. Dans leur papier, ils montrent clairement les chiffres de leur étude, et même si leur système est loin d’être parfait, il apporte des idées intéressantes.

Reste à voir le problèmes de la propriété privé, en effet, les fichiers sont envoyés à une entité centrale mais aussi l’importance de l’impartialité et de la sécurite de cette structure centralisée.