Magazine Internet

comprendre les attaques de "XML Signature Wrapping" contre Amazon et Eucalyptus

Publié le 15 novembre 2011 par Orangebusinessservices

Voir cette vidéo sur YouTube

Vous avez surement lu quelques articles sur les attaques "XML Signature Wrapping" ciblant Amazon EC2 et Eucalyptus. Afin d'aller au delà des versions plus ou moins équivalentes (et souvent  édulcorées) des articles traitant le sujet, je vous propose ici de rentrer un peu dans les détails pour :

  1. en apprécier la portée et les impacts
  2. comprendre les pré-requis techniques
  3. détailler le principe de l'attaque
  4. d'avoir une stratégie de réponse pour faire façe

Bon, la matière première se trouve dans ce document PDF intituté "All Your Clouds are Belong to us - Security Analysis of Cloud Management Interfaces". Le document, bien que dense ; au contraire d'autres reste ; est accessible. Pour plus de détails je vous encourage à vous y plonger, vous en ressortirez plus intelligent(e).

Apprécier la portée et les impacts

Sont concernés les cloud public comme Amazon EC2 ainsi que les cloud privés utilisant le framework opensource Eucalyptus. Ce sont les implémentations du standard WS-Security pour sécuriser les API en mode SOAP qui sont mises à mal.

En fait, la portée du problème va au delà d'Eucalyptus lui-même car celui-ci utilise le module Apache Rampart (composant intégré dans le framework Apache Axis2) pour les fonctions liées à WS-Security. Tout système ou platefome basé sur Apache Axis2 et utilisant le module Apache Rampart est donc virtuellement vulnérable à ce type d'attaque "XML Wrapping Attacks".

Concernant les impacts, ils sont potentiellement très importants car ce sont les interfaçes de contrôle du cloud qui sont concernées. Dans le cas d'Amazon EC2 cette attaque a permis de : démarrer de nouvelles instances de VM, d'arrêter des instances de VM en cours d'execution, de créer de nouvelles images et passerelles de sortie ; ou encore de générer de nouvelles paires de clefs SSH pour accèder à distance à des VMs.

La technique d'attaque "XML Signature Wrapping" n'est pas nouvelle : Elle a été mise en évidence en 2005 dans le papier "XML Signature Element Wrapping Attacks and Countermeasures".

De quoi s'agit-il concrêtement

Les API en SOAP fonctionnent via l'envoi d'un message en XML contenant un ensemble de "noeuds" (ou balises) ayant chacune une signification précise. La structure des messages SOAP est normalisée. Un message SOAP est composé d'une enveloppe contenant 2 sous-parties : un entête (ou "header") et un corps (ou "body").

comprendre attaques

L'entête (le "header") va contenir les données utilisées pour valider la requête : Des codes de hachage, une signature numérique (pour le contrôle d'intégrité et l'authenticité) ainsi que des informations temporelles pour contrer les attaques par rejeux.

Le corps (le "body") va lui contenir les commandes (aka le nom de la méthode ou de l'API appelée) ainsi que les paramêtres nécessaires pour le bon fonctionnement de l'appel. C'est via cette section que l'on va demander l'arrêt ou le démarrage d'un VM. Le contenu de cette section est spécifique au cloud et à l'API.

comprendre attaques

Dans l'entête, on retrouve 3 grandes sections (ou groupes de noeuds)

  1. Le premier bloc  <wsse:Security> contient des informations sur les sections du document XML protégées (elles sont référencées via des balises <ds:Rreference> assorties de hash-codes <ds:DigestValues>) ainsi qu'une signature numérique dans la balise <ds:SignatureValue>.
  2. Le second bloc <wsse:BinarySecurityToken> contient le certificat X.509v3 de l'utilisateur.
  3. Et enfin le troisième et dernier bloc <wsu:Timestamp> contient une date et heure au delà de laquelle la requête n'est plus valide : Cela permet d'éviter le rejeux d'anciennes requêtes.

Les hash-codes (et la signature correspondante, générée par l'utilisateur grâce à sa clef privée) permettent de protéger l'intégrité du bloc <wsu:TimeStamp> ainsi que le corps de la requête (le "'body").

Principes de l'attaque

Toute la subtilité de l'attaque dite de "XML Signature Wrapping Attacks" réside dans la façon que le service web (Amazon EC2 ou le framework Apache Rampart dans le cas d'Eucalyptus) va vérifier le contenu du message et s'assurer qu'il est bien authentique.

Pour comment, il faut avoir à sa disposition un message SOAP avec une signature valide : Celui-ci pourra être capté lors de son transfert sur le réseau ou depuis un forum d'entraide comme celui d'amazon EC2. Rien de fondamentalement compliqué.

comprendre attaques

Une fois ce message SOAP en main, différentes techniques d'attaque sont possibles. Je n'en détaillerai qu'une seule (allez lire le papier pour les autres). Dans cette attaque, le XML du message SOAP est modifié de sorte à insérer un deuxième bloc "body" (body-attaque) juste avant celui d'origine (body)

Déroulement de l'attaque

Lors de la réception et le traitement du message, le service SOAP va 1) verifier que la signature du body est bien exacte (et ce sera le cas, la vérification allant porter sur le bloc original) , puis va passer le document XML pour traitement.

comprendre attaques

A ce moment, le bout de code en charge de réaliser le traitement demandé dans le "body" va sélectionner et exécuter le 1er bloc body (celui qui a été inséré par l'attaquant). BOOM !

Dans ce cas précis, le problème se situe dans les informations transmises lors de la 1ere phase à la 2nde. Pour bien faire, seuls les noeuds/blocs XML dont la signature a été validée auraient du être envoyés à l'étape suivante. En complément, il y aurait du y avoir (lors d'une étape "0") une vérification de la structure du document XML pour détecter les doublons ou autres "malformations", cela pouvant être par exemple mis en oeuvre via un XML-Schema spécifique.

 

comprendre attaques

En conclusion

Ce type d'attaque montre bien l'importance de sécuriser l'ensemble des interfaces d'une application ou d'un service : interfaces web utilisables depuis un navigateur web mais aussi les interfaces moins visibles comme les API SOAP ou REST. Il est essentiel de considérer par défaut toutes données provenant de l'extérieur sont des sources de danger qui doivent être analysées de façon très méticuleuse.

Oui le cloud est concerné mais pas uniquement lui : Comme indiqué ci-dessus, le framework Apache Axis2 est concerné, il y a des chances que ce soit pour d'autres toolkits et peut-être aussi les développements internes. Ce sujet est donc potentiellement plus large que le cloud car ce sont toutes les architectures de type SOA (Service Oriented Architecture - Architecture Orientée Services) qui sont potentiellement impactées.

PS: Un merci à Bruno D. pour son aide lors du tournage de la vidéo !


Retour à La Une de Logo Paperblog

A propos de l’auteur


Orangebusinessservices 590 partages Voir son profil
Voir son blog

l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte

Magazine