Pour regarder cette vidéo, vous devez consentir aux Cookies de notre partenaire Youtube Ces cookies permettent de partager ou réagir directement sur les réseaux sociaux auxquels vous êtes connectés ou d'intégrer du contenu initialement posté sur ces réseaux sociaux. Ils permettent aussi aux réseaux sociaux d'utiliser vos visites sur nos sites et applications à des fins de personnalisation et de ciblage publicitaire.
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 :
- en apprécier la portée et les impacts
- comprendre les pré-requis techniques
- détailler le principe de l'attaque
- 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
L
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.
- 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>.
- Le second bloc <wsse:BinarySecurityToken> contient le certificat X.509v3 de l'utilisateur.
- 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é.
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
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 !
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 !
Au sein de la direction sécurité du Groupe Orange, je suis en charge de la veille sécurité et de la sensibilisation à la sécurité. Franchise, optimisme et bonne-humeur sont mes moteurs quotidiens