Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

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

Comprendre les attaques de "XML Signature Wrapping" contre Amazon et Eucalyptus
2011-11-152013-04-11cloud computingfr
XML Signature Wrapping Attacks : Passage en revue du concept de ce type d'attaque visant les API SOAP. Une vidéo et quelques schémas pour mieux comprendre de quoi il s'agit vraiment. Ne concerne pas que le cloud mais potentiellement toutes les architectures en...
Publié le 15 Novembre 2011 par Jean-François Audenard dans cloud computing
XML Signature Wrapping Attacks

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

LXML Signature Wrapping Attackses 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").

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.

XML Signature Wrapping AttacksDans l'entête, on retrouve 3 grandes sections (ou groupes de noeuds)

  1. Le premier bloc  contient des informations sur les sections du document XML protégées (elles sont référencées via des balises assorties de hash-codes ) ainsi qu'une signature numérique dans la balise .
  2. Le second bloc contient le certificat X.509v3 de l'utilisateur.
  3. Et enfin le troisième et dernier bloc 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 ainsi que le corps de la requête (le "'body").

XML Signature Wrapping Attacksprincipes 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é.

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

XML Signature Wrapping AttacksLors 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.

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 !

XML Signature Wrapping AttacksDans 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.

 

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 !

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage