Alors, puisque la sécurité semble venir sur le devant de la scène Magento et que, par pur hasard, votre serviteur a fait un peu de sécurité avant de faire de l’hébergement Magento. Puisque de surcroit vous avez des questions sur le sujet, un petit article s’impose. On va faire simple car la sécurité n’est pas le thème de ce blog et donc il ne faut pas lasser le lectorat mais on va réadapter une pensée de Lao Tseu pour l’occasion :
“Montre à un développeur une XSS, il l’a corrigera. Apprends lui comment ça marche, il n’en fera plus !”
Du moment que la pensée de Lao Tseu débattue n’est pas :
“Quand le sage montre une XSS du doigt, l’idiot regarde le doigt”
ca ne sera pas du temps perdu !
Plus sérieusement : une XSS, ça fait peur! C’est un peu comme une maladie honteuse dont on ne saurait pas trop ce qu’elle fait et à quoi ça peut bien mener. Certains diront que l’on crie au loup, d’autres savent la portée et le résultat de ce genre de faille.
Principes généraux
XSS pour Cross Site Scripting. Soit en gros, répandre du code dans un site. Le but (pour le pirate) c’est de faire s’afficher, non pas du html que votre navigateur affichera, mais de renvoyer du langage de script (javascript notamment) que votre navigateur interprétera.
Si on fait simple, imaginons que quelqu’un post dans ce blog un commentaire en Javascript qui soit <script>alert(123)</script> et que mon blog ne soit pas protégé contre ca. Quand vous allez afficher le commentaire dans votre navigateur, il ne va pas mettre le texte <script>alert(123)</script> dans une page HTML et vous montrer le texte mais il va lancer ce code Javascript et ouvrir une boite de dialogue qui contiendra le texte « 123 ».
Pour la démonstration, les experts en sécurité ne se prennent pas la tête à mettre un code complexe, il suffit de prouver que la boite d’alerte s’affiche, si elle le fait, on peut ensuite mettre ce que l’on veut comme script à la place et que la XSS est présente.
L’exemple est bénin, mais…
Si à la place d’une gentille popup box qui affiche 123, mon navigateur se met à faire des choses plus discrète et plus gênante ? Par exemple, créer une Iframe invisible en surimpression de la page que je consulte ? Iframe qui va envoyer les informations vers un autre site contrôlé par un pirate ? Ce n’est pas de la science fiction, c’est même très simple à faire pour un professionnel. Mais le Javascript, surtout couplé à Ajax, c’est encore plus puissant que ca. On peut écouter les frappes clavier, scanner le réseau local de la victime, altérer son affichage de page web, effectuer des opérations sur les sites ou il est authentifié, lui voler ses sessions, bref, ca peut être très dangereux, selon les cas, les circonstances etc…
Le cas des trois XSS de Magento
Ok, vous avez compris, le XSS ce n’est pas du tout anodin. Dans le contexte des 3 failles Magento, on risque quoi plus précisément ? Pour les deux premières présentées dans cet article, pas grand-chose. Disons que le risque est présent mais que l’exploitation est complexe car la méthode utilisée est un POST et non un GET. En gros, à la place de l’administrateur légitime, il faudrait saisir “> <script>alert(123)</script> dans le champ login. Et à la place de (123), mettre le code source Javascript d’un cheval de Troie. (ca existe, ca se trouve sans soucis)
Comme l’administrateur légitime ne le fera pas de lui-même, ça implique, si l’utilisateur est déjà loggé sur son backoffice, de l’amener à se connecter à un site contrôlé par le pirate, qui va faire du scripting dans son dos avec la faille XSS, pour tenter de prendre le contrôle de sa session. (Le POST sera alors « transparent »)
Si l’utilisateur n’est pas loggé, ca implique toujours de l’envoyer vers un site contrôlé par le pirate et à utiliser ce site pour lancer un javascript qui va écouter les frappes clavier, pour obtenir son password de backoffice, en espérant qu’il ne ferme pas l’onglet du site compromis (et ne fasse pas de reload ou de back) pendant qu’il se loggera sur son backoffice. Le taux de réussite est moyen, la patience est de rigueur mais ce n’est pas infaisable. Disons que pendant nos tests d’intrusion, on a un taux d’environ 20% sur ce type d’attaque.
Dans les deux cas, exploiter ces XSS en méthode « POST » c’est un peu complexe et ca s’assimile plus à une exploitation de type CSRF. Ce n’est pas infaisable mais le script kiddie du coin ne maîtrise pas ce genre d’attaque un peu complexe (heureusement). Ca reste mal mais pas catastrophique puisque la barre d’entrée est assez élevée.
Par contre, la troisième, le downloader… Ça c’est très dangereux.
Quand j’appelle :
http://mon_site_magento/ downloader/?return=%22%3Cscript%3Ealert(123)%3C/script%3E
Je fais un GET et non un POST et ca change tout ! En fait ca simplifie tout !
Par exemple, un simple fakemail (usurpation d’identité) permettra à l’attaquant d’envoyer un lien piégé, contenant du Javascript nuisible et adapté, ce qui lui donnera le contrôle des prochaines actions qui seront effectuées. L’idée est simple, le mail affiche un lien normal vers le backoffice, le lien en réalité contient le XSS et donc du Javascript d’écoute du clavier (par exemple) et ensuite vous vous loggé… Perdu.
Ecrire un fakemail, c’est le paragraphe 1 du chapitre 1, du manuel du pirate. Vous pouvez même le faire en changeant votre nom dans outlook, c’est déclaratif… Je peux vous envoyer un mail de la part de neil.amstrong@lune.org en 10 secondes. Alors si un pirate se fait passer pour le patron de la boite et demande par mail à la personne en charge du backoffice de se connecter (lien dans le mail) et de contrôler les ventes, vous pensez qu’elle va faire quoi la personne en question ?
C’est une attaque très simple à mener donc très dangereuse et là, le script kiddie peut prendre le contrôle de votre backoffice.
Où Varien a t’il fait un oubli ?
Well, pour les deux premières, l’explication vient d’un oubli dans le contrôle des sorties d’erreur. Je tape n’importe quoi dans la case « nom d’utilisateur » et le système me réaffiche ce que j’ai tapé pour me dire que ce n’est pas le bon login.
Si l’utilisation du framework Zend avait été uniforme et/ou si les retours d’erreurs avaient été nettoyés avec une fonction PHP du nom de htmlentities(), le problème n’aurait même pas existé. Ce qui est vrai pour Varien l’a été pour un nombre hallucinant de soft et ne riez pas avant d’avoir relu vos propres codes sources.
Cela peut-il se reproduire ?
Ouiiiiii, bien sûr.
Un oubli, une fois, un lendemain de soirée arrosée ou encore un « ballmer peak » d’un développeur et hop…
C’est la XSS. J’exagère un peu dans le sens ou, normalement, on code dans le framework Zend et on applique une revue de code, on test tout, on utilise des vérificateurs statiques ou dynamiques de code source etc… Cela devrait donc se produire très rarement voir pas. Varien a été sensibilisé cette fois ci, ca éveille leur attention sur ce point, la chasse est lancée et les consignes passées je pense. De plus, en un an, c’est la première alerte sécurité.
Mais… Si Varien gagnait un peu plus sa vie ? Si Magento leur rapportait plus d’argent, qu’ils avaient plus de partenaires etc… Ils auraient pu s’acheter les outils d’analyse statiques et dynamique dont je parle. Ma boite fait (aussi) du test de sécurité sur des soft/site Web, donc forcément on a ce genre d’outils, mais ca coûte cher, très cher, or pour le moment, Varien à des moyens limités, une roadmap à respecter et pas des milliers de dollars à lancer par les fenêtres pour acheter ce genre de prestations ou d’outils.
Je vais voir si mon équipe de tests de sécurité aurait le temps de se pencher un peu dessus au prochain creux de production.
Allez, on applique les correctifs maintenant qu’on sait que c’est dangereux !
Celui de Gabriel de Fragento : ICI
ET (OU seulement dans le pire cas)
Celui de Wikigento : ICI
Commentaires récents