S’attaquer au cloud : possible, mais pas si simple

Stéphane Bellec

01net.

le 18/09/2009 à 13h36

3 réactions

envoyer
par mail

imprimer
l'article

Afin d'explorer les vulnérabilités qui gravitent autour des plates-formes tierces du cloud computing, quatre chercheurs de l'université de Californie et du MIT se sont associés. A partir d'expérimentations sur la plate-forme EC2 d'Amazon, ils publient dans un rapport d'une quinzaine de pages la modélisation d'une menace permettant de cartographier un réseau et d'en remonter des informations.

Une menace toutefois relative puisque acrobatique dans sa mise en place, et ardue dans sa réalisation. Les chercheurs ont en effet emprunté les voies du Side Channel Attack, une méthode très complexe qui consiste à récupérer des informations par voies détournées, matérielles ou logicielles. S'en prendre au nuage n'est donc pas encore à la portée de tout le monde, Thomas Roche, chercheur à l'Inria au sein de l'équipe MOAIS (1), nous explique. 

01Net : Pouvez-nous nous repréciser le contexte de ce rapport ?
Thomas Roche : L'étude porte sur la sécurité des third-party compute clouds, qui sont des plates-formes de calcul constituées de machines hétérogènes en réseau, et possédées par une entité qui les met à disposition de n'importe qui, moyennant finance. Les auteurs s'appuient sur une attaque de la plate-forme d'Amazon EC2, mais précisent que les résultats peuvent être étendus à la plupart des plates-formes de ce type 
(Microsoft Azure, par exemple). Pour chaque nouvel utilisateur d'EC2, une machine virtuelle individuelle est créée. Il en existe différents types, répartis selon les besoins de mémoire vive, d'espace disque, ou de puissance de calcul (nombre de coeurs virtuels utilisés, etc.).

Figure 1

Cartographie Adresses IP internes

agrandir la photo

Comment fonctionne cette attaque ?
Considérons un pirate,
dont le but est de récupérer les informations confidentielles, à partir de calculs réalisés par un utilisateur de la plate-forme. Pour parvenir à ses fins, il devra réaliser trois opérations : cartographier le réseau, localiser l'application cible pour se retrouver sur la même machine physique et partager les mêmes ressources, afin de, en dernier lieu, lancer l'attaque. Sur la Figure 1 (voir ci-dessous) sont représentées les adresses IP internes du nuage EC2 obtenues grâce à des requêtes DNS effectuées sur des sous-domaines du nuage (exemple m1.small), et dont les noms désignent en plus une catégorie de serveur (small, medium ou large). La régularité d'affectation permet d'identifier rapidement le type de ressource physique utilisée par une application cible. Une faille très simple à réparer.

Figure 2

Repésentation des chances de co-résidences

agrandir la photo

L'attaquant doit réussir à localiser l'application cible, c'est-à-dire trouver la machine physique hébergeant la machine virtuelle sur laquelle elle tourne, pour réaliser ce que les chercheurs appellent une corésidence.  Pour ce faire, deux méthodes : La première, appelée brute force, consiste à créer des dizaines d'instances, en partant du principe qu'un pourcentage d'entre elles se retrouvera au bon endroit. La seconde se base sur le fait que deux instances démarrées en simultané ont de fortes chances de se retrouver sur la même machine physique.
Regardons maintenant la Figure 2 (voir ci-dessous). Sur l'histogramme de gauche est représenté le nombre d'instances malicieuses lancées. Si 20 instances sont envoyées quasi simultanément, on peut se retrouver avec 8 corésidences. Plus on s'éloigne dans le temps, plus les chances se réduisent, jusqu'à disparaître dès la dixième heure. Sur l'histogramme de droite, on illustre le pourcentage de possibilités de voir l'adresse du manager changer augmenter au fil du temps, et donc de ne pas être hébergé par le même hôte.

Comment l’attaquant peut-il savoir s'il est bien en corésidence ?
Les chercheurs parlent de coresidence checks. Il y en a trois. Les adresses IP qui sont plus proches les unes des autres, dès lors qu'elles sont sur le même hôte. Ensuite des envois de ping, tout simplement, qui attesteront de la distance entre la machine interrogée et l'attaquant : plus le temps de réponse est faible, plus les chances d'être sur le même hôte sont grandes.
Enfin, il faut savoir que pour chaque machine physique, l'ensemble des machines virtuelles hébergé, est géré par l'une d'entre elles appelée manager. De fait, via un simple traceroute, l'attaquant pourra vérifier qu'il est géré ou non par le même manager, et donc sur le même hôte.  

C’est à ce stade seulement que l’attaque peut avoir lieu ?
Exactement. L'attaquant partage désormais les ressources processeurs de sa victime. Il va facilement récupérer des informations telles que l'utilisation CPU et l'utilisation du cache. Il pourra en déduire des informations confidentielles, comme le nombre de requêtes HTTP pour un site web, ou la 
récupération d'un mot de passe tapé dans un terminal SSH. Dans ce dernier cas chaque touche frappée crée un paquet IP envoyé à la machine distante. L'attaquant va pouvoir évaluer le temps entre deux frappes de clavier, et utiliser la méthode Timing SSH pour trouver quelle chaîne de caractères a été envoyée (par exemple lors de la saisie d'un mot de passe). 

Que penser d’une telle vulnérabilité ?
Il est évident que ce type d'attaque ouvre une brèche dans la sécurité du nuage et permet de constater que de telles plates-formes ne sont aujourd'hui absolument pas sécurisées. Mais les contre-mesures restent très simples. Les chercheurs en proposent d'ailleurs un certain nombre dans leur rapport. Au final, pour une si grosse attaque, la difficulté de remédiation est très faible. 

(1) Equipe Projet MOAIS - Multi-programmation et Ordonnancement pour les Applications Interactives de Simulation, dirigée par Jean-Louis ROCH