NBS System travaillant dans les domaines de  la sécurité et dans celui de l’hébergement de sites de E-commerce, forcément parfois ces deux domaines se rejoignent.

En l’occurrence, avant la mise en production de sites de E-commerce, de nombreux clients nous demandent d’auditer le code source de leur site. Nous avons donc procédé ces derniers mois à de nombreux audits de codes et de performances de Magento et deux failles de sécurité nous sont apparues.

Faille XSS (cross site scripting) sur la gestion des 404 de Magento

Celui-ci est gênant car c’est une faille de Cross Site Scripting, non authentifiée, en GET. Les pires.

Une faille de cross site scripting, aussi appelé XSS, (voir ici) c’est dangereux. Le principe de fond c’est de renvoyer du langage de script (en général du javascript) à un navigateur dont l’utilisateur s’est fait piéger. Partant de là, on peut contaminer le navigateur et s’en servir pour scanner un réseau local, voler les pass mémorisés, sniffer les frappes claviers, falsifier des pages par des iframes invisibles etc…

Contexte  de la faille

Alors où est-elle, celle-ci ?
Eh bien à un endroit insolite, dans les 404…

Toutes les versions de magento ne sont pas touchées, la vulnérabilité a été remontée par NBS System à l’éditeur en avril 2010 et les versions qui ont vu le jour depuis semble avoir été corrigées. Vous pouvez aisément vérifier par vous même de toute façon si vous êtes vulnérable ou non :

http://www.MONSITE.com/404/index.php/aaaaa/aa%22%3E%3Cscript%3Ealert(%22XSS%20me!%22)%3C/script%3Eaaa/bbbbb/cccccc

Remplacer www.MONSITE.com par votre URL de site.

 

Si ca affiche une boite de dialogue qui raconte :

 

<www.MONSITE.com>
XSS me!

Vous êtes vulnérable.

Exploitation possible

Si votre site est vulnérable, cela veut dire que quelqu’un qui enverrait une URL anodine en apparence mais contenant en réalité un lien beaucoup plus complexe, comme ceci dans un mai l:

Valérie,

Pourrais tu te connecter au backoffice et mettre à jour les tarifs :
www.monsite.com <- qui est en fait : http://www.MONSITE.com/404/index.php/aaaaa/aa%22%3E%3Cscript%3Ealert(%22XSS%20me!%22)%3C/script%3Eaaa/bbbbb/cccccc

peut vous compromettre votre backoffice si il met autre chose que juste un bête « XSS me ».

Origine de la faille

Dans magento/404/index.php, la variable $_SERVER[‘PHP_SELF’] est utilisée avec deux appels à la fonction dirname() pour créer la variable $baseUrl :

 

$baseUrl = dirname(dirname($_SERVER[‘PHP_SELF’]));

 

Ensuite, cette variable est affichée en sortie par la page 404 (magento/404/skin/default/index.phtml), line 313:

 

<h1><a href= »<?php echo $baseUrl?> »><img src= »skin/<?php echo $store ?>/images/logo.gif » alt= »Magento Commerce »/></a></h1>

Correctif à la faille XSS des 404

Comme on aime pas poser les problèmes sans apporter de solutions chez NBS System, j’ai appelé mon ami Gabriel à la rescousse pour lui demander son avis et un correctif.

Voici son avis :
« Cette vulnérabilité n’affecte pas la page 404 de Magento au sens que l’on entend usuellement. Il ne s’agit pas de la page « page non trouvée ». En fait 404/index.php est une page sur laquelle on arrive quand Magento ne comprend pas un élément quand on lui demande de se démarrer. Par exemple si je demande à Magento « lance moi le site A » et que le site A n’existe pas dans sa base de données, il nous redirigera dessus. »

Gabriel nous propose de patcher le fichier /404/skin/default/index.html

Index: index.phtml
===================================================================
--- index.phtml    (revision 3)
+++ index.phtml    (revision 1063)
@@ -310,7 +310,7 @@
 <div>
 <div>
 <div>
-    <h1 id="logo"><a href="<?php echo $baseUrl?>"><img src="skin/<?php echo $store ?>/images/logo.gif" alt="Magento Commerce"/></a></h1>
+   <h1 id="logo"><a href="<?php echo htmlspecialchars($baseUrl) ?>"><img src="skin/<?php echo $store ?>/images/logo.gif" alt="Magento Commerce"/></a></h1>
 </div>
 </div>
 </div>

Voici aussi l’attachement

Versions vulnérables

Il semble que les versions pré 1.4 soient vulnérables à cette faille, l’étendue précise est difficile à vérifier, faire le test proposé ci-dessus reste le meilleur moyen.

Crédit

La faille a été découverte par Thibault Koechlin de l’équipe sécurité informatique de NBS System.

Faille D.O.S sur Magento

Allez, on est en forme pour la rentrée, une deuxième…

Cette attaque n’est pas réellement spécifique à Magento et pas si « originale » mais l’équipe sécurité n’a pas vu, pour le moment, de publication de cette attaque D.O.S ou D.D.O.S. Ayant vécu cette attaque sur deux clients hébergés, il nous a paru pertinent de diffuser l’information afin que chacun puisse se protéger. C’est le principe de fond d’association Cookie/Session qui est problématique.

Contexte de la faille

Chaque session nécessite de stocker des informations sur le serveur puis c’est via le cookie que renverra le client que le serveur récupérera les informations associées dans la session. Dès qu’un client arrive sur le site concerné, il se voit attribuer une nouvelle session dès sa requête effectuée sur le serveur.

Magento permet de stocker les sessions en mémoire (via un memcache par exemple, ou sur une zone mémoire partagée en système de fichier tmpfs ou shm), ou, par défaut, sur le disque. Bien que le nettoyage de ces sessions ne soit pas forcément optimal, le système fonctionne correctement et il est possible de faire le nettoyage « à la main » avec un script en Cron.

La mémoire est l’espace disque sont des espaces de stockages limités. Leur saturation est donc possible à terme, en fonction de la rapidité à laquelle on pose des informations, de la taille des inodes du filesystem et de la taille de l’espace alloué. D’une manière général, on essaye de stocker ces informations sur un support le plus rapide possible, RAM ou disque SAS (voir SSD), qui sont souvent plus rapide mais plus petit qu’un support plus lent comme le disque SATA.

Les stockages basés sur les filesystems (disque, tmpfs, shm), qui stockent les sessions, ont un soucis de plus a régler : les sessions sont plus petites que les inode des filesystem. Un fichier de session de 1ko en prend réellement 4, 8, 16, 32, voir 64 sur disque selon la taille des inodes de la partition. Une solution type memcache est plus économe en ressource quelque part.Une fois que l’on a créé de très nombreux fichiers de sessions, il devient possible de saturer l’espace disque (Ram ou physique) et il est même parfois possible de saturer le nombre d’inodes du filesystem (l’index).

L’attaque D.O.S

C’est d’une simplicité très troublante.

Il suffit de requêter des pages du site (home ou autre) sans accepter les cookies, un très grand nombre de fois. A chaque requête, un fichier de session va être créé sur le serveur car aucune association cookie/session ne pourra être trouvé. En répétant la manipulation à l’extrême, en la scriptant. Chaque session va prendre, disons par défaut 4 Ko sur le disque.Sur un RAMdisk de 256 Mo, on va donc pouvoir stocker 64 000 fichiers de session.

A 5 requête par seconde (tout à fait faisable avec une ADSL classique), vous pouvez atteindre cette limite en 3 heures et demi. Les scripts de nettoyage des sessions passent rarement plus souvent que toutes les 12 heures donc il est facile d’atteindre la limite. Évidemment, en cas de D.D.O.S (distributed denial of service), cela va plus vite, beaucoup plus vite.

Résultats

Quand le serveur a saturé son espace disque (ou ram) alloué aux sessions, le serveur ne répond plus :

  • Si l’espace de stockage mémoire alloué est saturé nous assistons à une perte de données (que ce soit des sessions anciennes, ou de nouvelles non créées) , il peut s’agir d’un moindre mal dans certains cas, dans d’autres la saturation mémoire entrainera une utilisation des mécanismes de Swap (écriture de mémoire « non utilisée » sur disque) et ses accès disques supprimeront tous les avantages de l’utilisation de la mémoire jusqu’à ce que celui-ci aussi soit également saturé.
  • S’il s’agit de l’espace disque, des lenteurs d’accès conséquentes vont être constaté lors des accès sur le dossier comportant une liste trop importante de fichiers de sessions. Dans le pire cas, nous obtiendrons une saturation de l’espace disque – ce qui amenuisera et bloquera forcément le serveur.
  • Si le ramdisk grossit tout seul (ou la partition) comme dans le cas de certains système de fichiers, on peut également saturer le reste du serveur et pas seulement les partitions du site. A l’extrême, il devient parfois impossible de se logger car SSH ne pourra pas écrire ses fichiers, pas plus que syslogd les logs.

PS : Pour accélérer les traitements de Magento et diminuer les I/O sur disque, j’ai beaucoup conseillé de mettre le cache et les sessions dans des Ramdisk. Le principe de fond est toujours bon mais cette optimisation peut aussi poser problème du coup car en général les ramdisk sont plus petits que les partitions des disques dur, ce qui permet de saturer plus vite l’espace.

Solutions & leurs limites

  • Patcher Magento pour ne créer la session qu’à partir d’un second lien présentant un « referrer » interne au site, le champs referrer est fourni par le navigateur… il est donc possible d’y mettre ce que l’on veut, et pour vérifier qu’un referrer est légitime, il faudrait appuyer sur une session !
  • Prévenir en amont, sur le reverse proxy, un nombre de requêtes trop importante à partir d’une IP source (mais ca ne fonctionne pas contre une D.D.O.S)
  • Nettoyer les sessions toutes les n minutes par une cron tab, surtout si elles font une taille « de base » et n’ont pas évolué dans le temps.

Crédit

La faille a été initialement découverte par Adrien Urban du service infogérance & hébergement E-commerce de NBS system.

Le fichier local.xml de Magento sur le Web ?

Si vous ne connaissez pas le principe d’un Google Dork, vous allez vite en apprécier sa portée.

Un Google Dork est une requête auprès de Google qui permet de trouver une chaine typique de caractère. En l’occurrence on s’en est souvent servit pour repérer un type de technologie. Typiquement si vous voulez trouver les sites Magento, vous pouvez recherche cela dans Google :

allinurl:skin/frontend

Typiquement, les sites Magento on des chemins dans la home vers les ressources contenant le nécessaire :

<link rel="stylesheet" type="text/css" href="http://www.monsite.fr/skin/frontend/default/huiles/css/styles.css" media="all" />
<link rel="stylesheet" type="text/css" href="http://www.monsite.fr/skin/frontend/default/default/css/easytabs.css" media="all" />
<link rel="stylesheet" type="text/css" href="http://www.monsite.fr/skin/frontend/default/home/css/monslid.css" media="all" />
<link rel="stylesheet" type="text/css" href="http://www.monsite.fr/skin/frontend/default/huiles/css/print.css" media="print" />

donc quand on cherche allinur:skin/frontend, toutes les pages contenant skin/frontend remontent et comme c’est une signature distinctive de Magento, on a que des sites Magento dans les résultats, c’est le principe d’un Google dork. Ici, c’est le fingerprinting d’une technologie Web.

Faille

Maintenant si on tape cela dans Google :
allinurl:app/etc/local.xml

Que trouvons nous ? Eh bien quelque chose qu’on ne devrait jamais trouver. Des fichiers local.xml de Magento, qui contiennent des authentifiants de bases de données, qui sont parfois aussi utilisés pour le ssh ou autre…

Là encore, c’est vrai pour Magento mais pas que pour cette techno. De plus, ce n’est pas la faute de l’équipe de Magento si les personnes n’ont pas protégé leurs fichiers sensibles (et donc pas suivi le document de mise en place) et qu’en plus ils ont laissé les robots indexer ces fichiers. Cherchez pour d’autres technos d’autres fichiers de configuration et vous verrez que c’est assez fréquent.

Par défaut, ce fichier est protégé dans Magento mais là, les auteurs/développeurs/propriétaires/infogérant (il est difficile de savoir qui) ont eux même modifié les droits de ces fichiers à la main, en outrepassant les droits par défaut mis par Magento…

Solution

Actuellement il est assez communément considéré qu’une partie non négligeable des intrusions sur des sites ou des defacing sont liés à ces imprudences. Une pratique assez commune aussi est de ne pas vérifier le type de fichier déposé sur un serveur par un formulaire. Pour peu que vous puissiez déposer un fichier PHP, il devient très simple de mettre une backdoor comme C99 et prendre, à terme, le contrôle du serveur.

  • Vérification des entrées utilisateurs
  • Vérification des permissions des fichiers
  • Vérification des contenus transférés / manipulés

Ces trois règles simples auraient épargnés à tellement de sites des compromissions.

Appliquez donc les droits les plus restrictifs possible au fichier local.xml. Vous pouvez aussi exclure ces fichiers dans le robot.txt pour plus de sécurité encore, cela aurait sauver les sites victimes de cette faille en l’occurrence.

Crédit

Ce Google Dork est connu depuis un moment, je n’en connais pas les auteurs/découvreurs initiaux.

WordPress changement du mot de passe administrateur

Contexte de la faille

Alors celle-ci m’a tellement amusé que franchement, j’ai voulu la publier avec le reste. Nous n’en sommes pas les auteurs, mais elle est très drôle.

Si vous entrez l’url suivante sur n’importe quel domaine contenant un WordPress,

http://VOTRE-DOMAINE.COM/wp-login.php?action=rp&key[]=

Celui-ci va réinitialiser le mot de passe de l’admin et l’envoyer par mail à l’administrateur désigné…
Si on vous fait le coup toutes les 3 minutes, ca devient un poil pénible.

Solution

Ce blog donne la solution la plus propre, qui permet de ne pas toucher aux fichiers du core.

Crédit

Pour la faille je ne sais pas, par contre la solution vient du blog de pioupiouM.

Philippe Humeau
Philippe a co-fondé NBS System en 1999. Après s’être concentré sur la sécurité, qu’il n’a jamais abandonnée, il se découvre une passion pour le ecommerce à partir de 2008. Tour à tour pentester, CTO, CCO puis CEO, son profil touche-à-tout l’a conduit à devenir directeur marketing et stratégie d’OT Group après notre intégration dans celui-ci.