fév 24

Aïe, comme une prémonition, le post du 23/02 sur la sécurité se trouve malheureusement très adapté à la situation :
3 failles de sécurité de type XSS, cross site scripting, viennent d’être révélées sur Security Focus ce jour à propos de Magento v1.2.0.

Numéro CVE :
CVE-2009-0541
Numéro Bugtraq : 33872

En effet, trois failles de sécurité de type XSS (voir post du 23/02/2009 sur la sécurité) sont présentes dans Magento 1.2.0 et probablement dans les précédentes versions également. La primauté de cette découverte revient à Loukas Kalenderidis de Sens Of Security. Du coup, je me dis que ca vaudrait le coup de passer un test un peu en profondeur à la chasse d’autres XSS, sait on jamais. De toute façon, le « Web 2.0″ c’est une mine en terme de sécurité, si ca vous intéresse, ici, un article que j’ai publié il y a quelques années dans Hackin9 à ce sujet (il n’y a pas tout, notamment l’anti DNS pinning n’y est pas de mémoire, mais ce sont de bonnes bases).

Pas de panique, la très grande majorité de Magento repose sur Zend qui est un Framework solide donc on ne devrait pas en avoir des tonnes d’autres mais il va falloir être vigilant. De plus Varien a été prévenu par l’auteur de ces 3 failles le 21/01/2009. Yoav (Directeur Technique de Varien) a probablement lancé la chasse dans le reste du code mais Gabriel de Fragento nous indique que sur une 1.2.1.1 il a repéré le même XSS comme fonctionnel (voir commentaire). Le problème ne serait donc pas résolu malgré le fait que Sens Of Security a joué dans les normes visiblement, l’éditeur à été prévenu un mois avant la publication, ce qui semble un délai raisonnable.

Voila ce qui arrive quand on développe en dehors du framework Zend ou que l’on ne contrôle pas assez ses retours d’erreurs… Les risques de ce type, les XSS, principalement sur l’admin du backoffice, sont non négligeables.

Actions à mener rapidement

  1. Upgradez votre Magento ! Dès qu’une version corrigée sera disponible. Pour le moment, la dernière c’est la 1.2.1.1 au moment de la rédaction de ce billet, c’est donc une montée de version mineure si vous êtes déjà en 1.2.x, donc pas ou peu de problème (si vous n’avez pas codé dans le Core). Par contre si vous êtes en pré 1.2, ça risque d’être un peu plus sportif. De toute façon la version actuelle ne semble pas régler tout le problème.
  2. Mettez le bout de conf apache qui est en bas dans le fichier de virtualhost de votre site (ou faite le faire à votre hébergeur). Ça protégera votre backoffice, XSS ou pas.
  3. Sinon, vous pourrez prochainement appliquer le correctif logiciel qui nous sera fournit par Gabriel de Fragento

Les failles en elles mêmes

Vulnérabilité 1, page de login d’administration

Quand vous ratez un login, la valeur que vous allez entrer dans le champ « nom d’utilisateur » va être renvoyé à l’utilisateur sans encodage de la réponse :

  1. Allez sur la page d’administration (http://monmagento/index.php/admin ou quelque chose du genre si il y a un rewriting ou une autre racine du site, bref le /admin quoi)
  2. Entrez dans le champs « nom d’utilisateur » : « ><script>alert(123)</script>
    (attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
  3. Entez n’importe quoi dans le champ « mot de passe »
  4. Cliquez sur « Identifiant » et roohhhhh, une boite javascript qui vous confirme que le code dans le champ a été renvoyé sans encodage et donc exécuté par votre navigateur…

(j’ai également vérifié sur une version 1.0.x et ca marche donc il y a de grande chance que toutes les versions entre 1.0.x et 1.2.0 soient vulnérables)

Vulnérabilité 2, page « J’ai oublié mon mot de passe »

(déjà dans le principe, si tu oublie ton mot de passe admin du nackoffice, on se demande s’il est raisonnable que tu es accès à ce genre de fonction…)

  1. on se rend sur http://monmagento/index.php/admin/index/forgotpassword
  2. Dans la case email on met : « ><script>alert(123)</script>
    (attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
  3. on clique sur « retrieve password » et hop, une boite javascript qui annonce qu’on est vulnérable

Allez, quand on a un filon on le lâche pas,

Vulnérabilité 3, page « Magento Connect Downloader »

Là c’est directement dans l’URL qu’on peut encoder le XSS :
http://monmagento/downloader/?return=%22%3Cscript%3Ealert(123)%3C/script%3E
(attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
et vous connaissez l’histoire de la boite javascript tout ça tout ça…

Bon, allez je vous laisse, j’ai des clients à prévenir qu’il faut upgrader leurs Magento ;)

Conclusion, comme d’habitude : la sécurité à un coût mais elle n’a pas de prix !

Les correctifs ont été déplacés dans un post dédié : ICI

écrit par Philippe Humeau \\ tags: , ,

jan 17

Comme vous le savez, NBS System fait aussi de la sécurité informatique et notamment pas mal de test d’intrusion, externe, interne, web, applicatifs etc…

Dans ce contexte, nous créons régulièrement des petits articles de synthèse pour nos connaissances, pour des journalistes ou des clients. Certains de ces articles sont maintenant un peu vieillots (6 mois à deux ans) mais les principes de fond ne changent pas si vite que cela.

Je me permets donc de vous faire cadeau de trois de nos articles sur la sécurité des technologies Web et plus particulièrement Web 2.0, en espérant que cela servira à vos équipes pour faire baisser le taux de sites vulnérables. (D’après un rapport de notre labo de sécurité, sur 15 applicatifs web testés l’an dernier, 12 étaient très vulnérables, 2 légèrement (par Xss) et 1 seulement sans faille connue)

Une chance cependant pour les aficionados de Zend et Magento, le Framework Zend est bien sécurisé sur le point des XSS et SQL Injections. Les hébergeurs ont un rôle important également à jouer en patchant et sécurisant en continu, les développeurs également, en ne déportant pas de décisionnel ou de code sensible en Ajax/Javascript sur le poste client etc…

D’une manière générale :

  • Pas de code sensible et/ou décisionnel déporté sur le browser du client
  • Pas de version vulnérables des services LAMP (Apache et PHP tout particulièrement)
  • Pas de certificat auto signés
  • Un filtrage DRASTIQUE des entrées utilisateurs (formulaires, champs recherches etc…)
  • Si possible n’accepter que [a-z][A-Z][0-9] et le tiret pour les adresse
  • Un bon Firewall et un bon Reverse Proxy
  • Un DNS en dernière version non vulnérable à la faille de Kaminsky
  • Protéger toute zone d’administration par un .htaccess

Trois maximes guident notre métier :

  • La sécurité est un processus, pas un produit
  • La sécurité est une chaine, le maillon faible est toujours visé
  • La sécurité à un coût mais elle n’a pas de prix

(Ca semble plus commercial au premier abord mais ceux qui se sont déjà fait hacker savent de quoi je parle ;) )

article-dns-pinning
web-20
sécurité & web 2.0

écrit par Philippe Humeau \\ tags: , ,