Drupal/WordPress, les nouveaux frameworks et leurs failles
Signature : , | Mis en ligne le : 21/05/2013
Catégorie(s) :
  • Misc HS
  • Commentez
    Article publié dans :
    Achetez
    Misc HS 4 :
    Version Papier
    Version PDF
    Page 1/6
    Page suivante »

    51 millions de sites déployés sur WordPress, 15 000 plugins associés, 540 vulnérabilités publiées entre 2006 et 2010 pour WordPress et Drupal ; comme dirait Bernard, « Bienvenue sur le territoire des CMS, voyage au cœur d’une nébuleuse ».

    1. Introduction

    Les systèmes de gestion de contenu présentent une alternative séduisante aux développements spécifiques pour la création de plate-forme web, y compris à vocations très spécifiques et éloignées du simple site institutionnel ou de la plate-forme de blogging. Ces solutions, qu'elles soient commerciales ou plus ou moins libres d'usage, présentent des caractéristiques communes à prendre en compte en matière de sécurité.

    Nous nous attachons ici à présenter, au travers d'exemples autour de Drupal et WordPress, deux thématiques générales : l'évaluation de la sécurité de ce type d'infrastructures applicatives et un ensemble de bonnes pratiques liées à leur intégration, leur configuration et les développements.

    2. Évaluation de la sécurité

    2.1. Modèle d'évaluation de la sécurité

    Le modèle d'évaluation proposé correspond, sur le concept, au niveau de 2 de l'ASVS [1]https://www.owasp.org/index.php/ASVS de l'OWASP. Nous cherchons à avoir une approche globale, tenant compte de moyens d'évaluation complémentaires : un test d'intrusion manuel, une revue de code manuelle, et enfin, une revue de configuration des éléments principaux.

    Sur le fond, nous nous intéressons à des vulnérabilités web classiques (cf. les références [2]https://www.owasp.org/index.php/Category:Vulnerability [3]http://projects.webappsec.org/w/page/13246978/Threat%20Classification de l'OWASP ou du WASC) et à des éléments plus spécifiques aux frameworks de publication de contenu :

    • en premier lieu, au CMS lui-même, d'un point de vue cœur – il peut s'agir d'un logiciel public, libre, gratuit ou commercial, ayant déjà pu faire l'objet de recherches en matière de vulnérabilités (on ne peut pour autant pas en faire une généralité) ;
    • à des briques caractéristiques de ces frameworks :
      • extensions (plugins chez WordPress, modules chez Drupal, Add-ons chez d'autres, ...) ;
      • thèmes.
    • aux développements spécifiques qui ont pu être menés autour du CMS (modification du cœur, modules de SSO, extensions spécifiques, etc.) ;
    • à des fonctions un peu moins visibles que le front-end de publication (web services notamment) ;
    • à l'administration du CMS et aux incidences que cela peut avoir en matière de sécurité (au travers des fonctions utilisées pour l'administration fonctionnelle ou technique de la plate-forme).

    Sur la forme, les contraintes de temps, de disponibilité ou du budget ne permettront pas nécessairement de déployer toutes les approches, c'est pourquoi certains sujets sont traités par plusieurs approches.

    2.2. Test d'intrusion

    Nous partons de l’hypothèse que la démarche de test d’intrusion est réalisée en boîte noire et nous concentrons uniquement sur les aspects applicatifs avec des vecteurs d’attaques uniquement dirigés vers l’applicatif (en laissant de côté l’étude préalable des scénarios d’utilisation particuliers).

    L’identification des CMS se fera naturellement durant une phase de cartographie applicative ; les éléments suivants représentent de bonnes sources d’informations techniques :

    • footer HTML (ex: “Powered By”) ;
    • tags HTML précisant le moteur utilisé (ex: generator) ;
    • présence de fichiers par défaut :
      • dans le cas de WordPress, le fichier readme.html, présent par défaut à la racine, précise la version ;
      • dans le cas de Drupal, le fichier CHANGELOG.txt remplit le même rôle.

    Il sera aisé d’identifier si des vulnérabilités sont déjà connues sur les versions identifiées.

    De manière plus spécifique, il est possible de pousser la cartographie aux extensions et à leurs versions. Ce sujet est en général plus intéressant, ces dernières sont moins auditées et représentent souvent un point d’entrée moins surveillé.

    Une méthode d’identification simple consiste à construire un catalogue d’extension, puis à en tester l’existence au sein du CMS.

    Dans le cas particulier de WordPress, aucune protection n’a été mise en place pour limiter l’accès à cette information. Les extensions sont stockées dans le répertoire /wp-content/plugins, chacune dans un répertoire portant le nom de l’archive téléchargeable sur le site des extensions de WordPress. Le serveur nous indiquera la présence de l’extension en renvoyant un code HTTP 200 ou 403. Ensuite, le contenu du fichier readme.txt permet d’identifier de manière quasi systématique la version précise de l’extension en cherchant le pattern "Stable Tag" (si le serveur n’a pas été renforcé le listing de répertoire permettra d'identifier directement les plugins installées sans avoir à les tester à l'aveugle).

    À noter que dans le cas particulier des extensions, nous avons régulièrement constaté que l'information n’est pas toujours de bonne qualité (information du readme.txt incohérente avec le numéro de version déclaré sur le repository) et qu’il vaut mieux considérer comme un numéro de version " a minima " (quand ce n’est pas " trunk "...). Ici aussi, ce catalogue permettra facilement de faire une recherche dans les bases de vulnérabilités publiques ou de concentrer du temps à la recherche de vulnérabilités en disposant du code.

    Classiquement, on portera également une attention particulière à l’accessibilité des fichiers sensibles et à ce qui aurait pu être oublié dans l’arborescence.

    WordPress /wp-config.php{.old,.bak,~}, /xmlrpc.log, ...
    Drupal /sites/default/settings.php{.old,.bak,~}, ...

    Cette liste est à compléter dynamiquement après l’identification des extensions installées (nous en donnerons un exemple plus loin, certaines extensions réalisant des sauvegardes applicatives stockent souvent leurs fichiers sur un schéma prévisible).

    L'exploration pourra être poursuivie par la recherche d'autres contenus ou répertoires accessibles librement. Dans le cas présent, WordPress et Drupal ne sont pas logés à la même enseigne. Si le dernier embarque une configuration par défaut protégeant plutôt correctement les répertoires mais expose des fichiers sources par l'utilisation de l'extension .inc, le second ne protège que très peu les répertoires par défaut, laissant le soin à l'administrateur de renforcer le serveur web.

    Plus précisément, WordPress embarque des fichiers visant à masquer le contenu de certains répertoires, y compris dans le cas où le serveur web n'aurait pas été reconfiguré pour désactiver le listing des répertoires :

    Il est également configuré, par défaut, pour stocker les fichiers uploadés (thèmes, archives de plugins, médias, etc.) dans le répertoire /wp-content/uploads/. Il génère ensuite une arborescence fondée sur l'année puis le mois (ex : http:///wp-content/uploads/2011/06). Mais contrairement aux autres répertoires standards de l'installation, WordPress ne génère pas de fichier d'index silencieux. Dans le cas où le serveur web n'a pas été reconfiguré pour désactiver le listing automatique de répertoire, ça peut être une source d'information à prendre en compte.

    En dehors de la recherche de vulnérabilités techniques, l’obtention d’un compte utilisateur privilégié ou non représente un scénario à prendre en compte. De nombreux CMS n’ont pas à proprement parler d’interface d’administration, mais des fonctions nécessitant une authentification et un ensemble de rôles, dont celui d’administrateur (dans bien des cas, le rôle de contributeur sera déjà intéressant). Il y a donc tout intérêt à :

    • connaître le(s) point(s) d’entrée(s) pour l’authentification ;
    • identifier des moyens d’énumération des utilisateurs ;
    • identifier les méthodes potentielles pour la réalisation d’attaque par bruteforce ;
    • vérifier s'il n'est pas possible de s'inscrire directement sur l'application.

    Si l'inscription sur le site est libre, il faudra s'assurer que cette possibilité correspond bien aux besoins prévus initialement ou s'il s'agit d'une erreur de configuration. Dans tous les cas, il est utile de vérifier que les droits par défaut d'un utilisateur qui se serait inscrit de lui-même ne sont pas trop importants (possibilité de publier directement, ou d'accéder à des fonctions d'administration, par exemple). De nombreuses vulnérabilités reposent en partie sur l'accès à des fonctions nécessitant une authentification préalable et parfois un certain niveau de privilèges.

    Vous souhaitez commenter cet article ?
    Brèves Flux RSS
    Édito : GNU/Linux Magazine Hors-Série N°72
    Édito : Linux Pratique N°84
    Édito : MISC N°74
    Édito : GNU/Linux Magazine N°173
    Édito : MISC Hors-Série N°9
    Communication RSS Com. RSS Presse
    HACKITO ERGO SUM
    GNU/Linux Magazine, partenaire du SymfonyLive Paris
    Opensilicium, partenaire de RTS EMBEDDED
    Linux Pratique et Linux Essentiel, Partenaire de l’Open World Forum
    Gnu/Linux Magazine, Partenaire des JDEV 2013
    Rechercher un article dans notre base documentaire :
    Désolé, aucun article ne correspond à vos critères.