Le mercredi 15 octobre 2014, la Drupal Security team a publié un avis de sécurité critique, sous la référence SA-CORE-2014-005 (CVE-2014-3704), concernant une vulnérabilité découverte dans l'API d'abstraction de la base de données qui permet de désinfecter automatiquement les paramètres d'une requête SQL et prévenir ainsi des attaques de type injection SQL.
A l'inverse des avis de sécurité typiques publiés régulièrement pour Drupal, la nature de cette vunérabilité fournit un moyen à un attaquant d'exploiter cette faille sans avoir besoin d'un compte, ou de certains privilèges, ni même que certaines conditions soient réunies sur le même site (utilisation d'un module, configuration typique, etc.).
En bref, cette vulnérabilité permet à un attaquant anonyme de compromettre n'importe quel site Drupal 7 par une attaque de type injection SQL.
C'est la plus sérieuse faille de sécurité publiée depuis très longtemps, au moins depuis 9 ans.
Faisons un petit retour sur la chronologie de l'événement.
Découverte
Cette faille de sécurité a été découverte par Sektion Eins, une société allemande réputée en sécurité informatique, qui a réalisé un audit de Drupal pour le compte d'un de ses clients. Dès la découverte de cette faille vers la fin septembre, la Drupal security team a été contactée et a engagé le processus de résolution. L'auteur de la découverte a bien sûr différé la publication de cette vulnérabilité le temps de la corriger et d'organiser le processus de publication et d'information.
Préparation
Le caractère hautement critique de la faille de sécurité découverte n'a pas bouleversé l'organisation en place. L'équipe n'a pas cédé la panique. Les bulletins de sécurité de la Drupal Security Team sont publiés depuis des fenêtres de tirs bien précises, que tous les professionnels ou passionés de Drupal connaissent bien et suivent (les mercredi en fin d'après-midi). Ces fenêtres permettent à ceux qui maintiennent des sites Drupal de se préparer le cas échéant selon un planning établi à l'avance. Après avoir, avec l'auteur de la découverte, élaboré les correctifs de cette faille (et j'imagine avoir inspecté toute la database API sous ce nouvel angle), un bulletin de sécurité a été préparé pour être publié le mercredi 15 octobre, une semaine après la fin de la conférence internationale DrupalCon Amsterdam. Une publication prématurée n'aura pas permis à ceux présent à cet événement de réagir à la juste mesure.
Dès le 10 octobre, une communication est réalisée afin d'alerter la communauté Drupal sur une prochaine publication d'un bulletin de sécurité.
Les membres de la Drupal Security Team ont pu également collaborer ensemble (ces membres sont tous volontaires pour donner de leur temps en accord avec leur employeur, tous acteurs majeurs offrant des services autour de Drupal, tels que Acquia, GetPantheon, Commerce Guys, Lullabot, etc.) pour élaborer des mesures de protection préventive permettant de mitiger les attaques qui allaient sans aucun doute déferler dès la publication de la faille sur les plateformes d'hébergement spécialisées sur Drupal, voire même les annuler (Shields Up), permettant ainsi à leurs clients de procéder aux mises à jour nécessaires dans le calme et la sérénité.
Chose inhabituelle, le 14 octobre, nous sommes clairement prévenus d'être prêts à mettre à jour nos sites Drupal pour le lendemain.
Publication
Le 15 octobre, le bulletin de sécurité SA-CORE-2014-05 est publié et est largement relayé sur les réseaux sociaux. Tous les membres de Drupal.org recoivent dans le même temps le bulletin de sécurité par courriel (s'ils sont abonnés aux bulletins de sécurité, mais qui ne l'est pas ?).
Au vu du caractère critique de la faille, outre la recommandation (l'injonction) de mettre à jour son site Drupal sur la nouvelle version 7.32 corrigeant la vulnérabilité, un patch est également fourni permettant à ceux qui n'auraient pas le temps, ou les compétences, ou les moyens d'effectuer cette mise à jour dans les plus brefs délais, de se protéger rapidement. L'application de ce patch peut être réalisée en une commande et en quelques secondes seulement.
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
La diffusion de ce patch a permis également de protéger tous les sites Drupal qui ne pouvaient pas migrer tout de suite sur la version 7.32 sans des implications sur les fonctionnalités métier implémentées (une migration d'un site complexe peut nécessiter un certain nombre de vérification avant une mise en production). Ainsi, l'intégralité des versions de Drupal 7 en production (depuis la version 7.0 jusqu'à la version 7.31) disposait d'un moyen simple de se protéger immédiatement sans incidence sur le fonctionnement du site. Même les sites Drupal baclés hackés jusqu'au coeur (et nous savons qu'il en existe un certain nombre, tout le monde ne respectant pas les règles de l'art dans la conception d'un site Drupal, cf trouver un prestataire Drupal) disposaient d'une solution simple et utilisable pour se protéger.
Bien entendu l'information se répand rapidement. Les premières vagues de tentatives d'attaque par injection SQL seront constatées environ 12 heures après la publication du bulletin.
Quelques enseignements
Essayons de dégager quelques enseignements de la découverte et de la gestion de cette alerte de sécurité.
Le mythe de la sécurité
Drupal est-il sécurisé ? C'est une question que beaucoup se sont posés, se posent ou se poseront.
Le risque zéro n'existe pas. Tous les logiciels ont des failles de sécurité (Heartblead, Shellshock, Java, Windows, Wordpress, etc. sont sans doute des mots qui vous évoquent des souvenirs) et Drupal n'est pas une exception. La sécurité n'est pas un dogme, un état binaire oui / non, mais avant tout un processus continue d'amélioration.
Drupal vise à fournir un framework disposant de fonctionnalités sécurisées nativement (lire Comment Drupal est protégé contre les 10 plus importantes failles de sécurité) qui permettent aux développeurs de concevoir plus facilement un site protégé. Au travers des années, la variété des failles de sécurité trouvées dans Drupal a fortement évolué. En founissant une API riche et documentée, Drupal a réduit considérablement le nombre de failles de sécurité relatives aux injections SQL, une des menaces jugées les plus sérieuses par l'OWASP de par sa fréquence et le risque qu'elle représente.
L'utilisation de Drupal par des organisations gouvernementales telles que la Maison blanche, le Gouvernement Français, le site du Premier Ministre, l'Etat Australien, etc, dont on peut difficilement douter de leur sensibilité vis à vis de l'aspect sécurité, démontre juste que Drupal est loin d'être le dernier dans ce domaine.
La gestion de la sécurité
Comme le risque zéro n'existe pas, au final la question la plus importante n'est pas de savoir si Drupal est sécurisé mais comment Drupal gère la sécurité. Vladimir Prelovac, au travers de sa lettre ouverte à la communauté WordPress, confirme qu'il s'agit bien là d'un enjeu majeur pour toute solution open source.
Drupal dispose d'une organisation et d'un processus bien rôdé concernant la gestion de la sécurité, depuis la découverte d'une faille, sa correction puis sa publication et l'information aux utilisateurs Drupal. La gestion de cette faille de sécurité hautement critique, qu'on a pu apercevoir au travers de ce billet, est tout simplement remarquable et démontre la grande maturité de Drupal, et de la Security Team, en ce domaine. Des boucliers préventifs permettant de mitiger, voire d'annuler, les attaques exploitant cette faille ont même pu être mis en place sur les principales plateformes d'hébergement spécialisées.
Une question de sensibilisation
En informatique, toute politique de sécurité comporte toujours deux volets : un volet technique et un volet organisationnel. Il est d’usage de considérer que l’organisation de la sécurité, avec une bonne information et sensibilisation des utilisateurs, permet de résoudre / prévenir 90 % des incidents qui peuvent survenir. Les mesures techniques de protection sont indispensables, certes, mais sans une bonne organisation et information des utilisateurs du système d’information, celles-ci peuvent vite devenir inopérantes.
Drupal ne déroge pas à cette règle fondamentale.
La publication il y a 10 mois d’une issue queue publique soulevant l’existence (possible à l’époque) de cette faille de sécurité en est une bonne illustration. Bien que le lien de déclaration d’une vulnérabilité soit disponible sur toutes les pages des modules de Drupal (dont celui du cœur), la non utilisation des outils fournis et la publication d’une issue (parmi les deux millions et quelques d’articles publiés sur drupal.org) dans une file publique n’a pas permis de détecter cette vulnérabilité plus tôt. En outre, étant publique, elle aurait pu être exploitée avant même qu’une correction puisse être diffusée.
L’organisation et les procédures mises en place par la Security Team pour gérer la sécurité de Drupal ne peuvent être efficaces que si ses utilisateurs sont bien sensibilisés et/ou peuvent rapidement retrouver les informations nécessaires, bref que l’utilisateur final soit le centre de gravité de sa politique de sécurité.
Drupal démontre là encore sa maturité en matière de sécurité à vouloir constamment s'améliorer sur ce sujet. En débattant de toutes les options envisageables à mettre en œuvre pour que cette situation ne puisse plus se reproduire à l’avenir, et permettre même au plus novice des drupaliens de ne plus refaire cette erreur, Drupal ne fait que mettre en oeuvre les trois pierres angulaires d'une politique de sécurité sérieuse : Organisation, Sensibilisation et Amélioration.
Drupal plus fort
De par sa puissance, sa scalabilité, son évolutivité, Drupal confirme sa percée en tant que plateforme professionnelle (CMS/CMF). Acquia (société créée par Dries Buytart le créateur de Drupal) est désormais positionné comme leader dans le célèbre Magic quadrant de Gartner des gestionnaires de contenus, aux côtés de Oracle, IBM, Adobe et de leurs CMS propriétaires. Et nous pourrions presque dire aussi Drupal par extension. Par cette présence de plus en plus prédominante au sein de grands groupes, entreprises ou administrations, Drupal fait de plus en plus l'objet d'audits de sécurité avancés qui ne pourront que lui être bénéfique, ainsi qu'à nous utilisateurs de Drupal. C'est d'ailleurs lors de l'un de ces audits que cette vulnérabilité a pu être détectée.
Même si nous aurions pu nous en passer, la faille de sécurité SA-CORE-2014-005 a permis de montrer comment Drupal, avec sa Sécurity Team et la mobilisation de sa communauté, gère ce type de vulnérabilité : avec compétence, sérénité et responsabilité. Merci.
Et quelques outils si votre site a été compromis
Mais tous les sites Drupal n'ont très certainement pas pu être protégés à temps. Tout le monde n'a pas pu réagir à temps, soit faute de disponibilité soit faute d'information (si vous avez un site Drupal, abonnez-vous à ses bulletins de sécurité). Là encore la communauté se mobilise et plusieurs tutoriels / conseils (Votre site Drupal a été hacké ? Quoi faire maintenant, ou Comment restaurer votre site hacké) et outils sont déjà en ligne pour vous aider à vérifier si votre site a été compromis et à le désinfecter.
- Le module Site audit intègre désormais la détection des principaux vecteurs d'attaque qui ont été utilisés jusque là (il sera régulièrement mis à jour).
- Une commande drush drupalgeddon permet également de détecter plusieurs motifs d'attaques.
Attention, ces outils permettent de détecter SI un site a été compromis. Ils ne peuvent PAS vous assurer que votre site n'a PAS été compromis. En effet ces outils ne recherchent que les motifs des premières vagues d'attaque connues. D'autres vecteurs ont pu être utilisés depuis sans qu'ils aient été remontés dans la FAQ officielle. Pour en avoir la certitude, si vous n'avez pas pu protéger Drupal à temps, il vous faudra effectuer une analyse approfondie des fichiers et de la base de données, ou encore plus simple faire une restauration de vos fichiers et de votre base de données à une date antérieure au 15 octobre, si cela est possible.
En espérant que vous n'en ayez pas besoin. N'hésitez pas à faire appel à un professionnel en cas de doute. Un site compromis peut avoir des conséquences très facheuses (infection de vos visiteurs, utilisation du site comme émetteur de spam, banissement du serveur, etc.)
Pourquoi ce billet ?
Après avoir été sollicité à plusieurs reprises sur la question de la sécurité de Drupal suite à la parution du bulletin de sécurité SA-CORE-2014-005, et formulé en réponse à chaque fois les mêmes éléments, il ne m'a pas paru inutile de mieux les formaliser et les organiser en une réponse factuelle et la plus complète possible. N'hésitez pas à l'améliorer et à la partager si nécessaire.
Ajouter un commentaire