Drupal vient de publier un message d'alerte afin d'attirer l'attention de ses utilisateurs sur une faille importante (injection SQL). En effet, si elle a été comblée dès le 15 octobre, il existe un risque si vous n'avez pas appliqué la mise à jour dans les heures qui ont suivi. En effet, des pirates se sont rapidement engouffrés dans la brèche et, une fois votre base de données compromise, appliquer le patch n'est malheureusement d'aucun secours.
Drupal mis à jour à cause d'une faille liée à une injection SQL
Le 15 octobre, Drupal publiait une mise à jour de son CMS (Content Management System) en raison d'une importante faille de sécurité identifiée sous la référence CVE-2014-3704. Les conséquences peuvent être relativement importantes, d'autant plus que toutes les versions 7.x sont concernées.
En effet, à cause d'une vulnérabilité de l'API prenant en charge les requêtes SQL, « un pirate peut envoyer des requêtes spécialement conçues afin d'exécuter du code SQL arbitraire. Selon les cas, cela peut conduire à une escalade des privilèges, à l'exécution de code PHP arbitraire ou à d'autres attaques ». Bien évidemment, une mise à jour 7.32 avait été publiée dans la foulée afin de combler cette faille, mais ce n'est pas toujours suffisant, notamment si des pirates se sont introduits dans votre base de données entre temps.
Si vous n'avez pas été assez rapide, votre site peut être compromis malgré tout
La société vient donc de publier une alerte en précisant que, « dans les heures qui ont suivi » l'annonce de la mise à jour, des attaques ont commencé. Afin de bien faire passer le message, Drupal ajoute que, « vous devez agir en partant de l'hypothèse que chaque site Drupal 7 a été compromis à moins qu'il n'ait été mis à jour ou patché avant le 15 octobre à 23h UTC, soit 7 heures après l'annonce ».
L'éditeur explique en effet que « se mettre simplement à jour vers Drupal 7.32 ne supprimera pas les portes dérobées ». En clair, se mettre à jour alors qu'un pirate a déjà exploité la faille ne sert pas à grand-chose puisqu'il pourra toujours continuer d'agir de l'intérieur. L'équipe de développeurs ajoute que « si vous trouvez votre site mis à jour, mais que vous ne l'avez pas fait, c'est un symptôme indiquant qu'il a probablement été compromis. Certains pirates ont appliqué le patch afin de s'assurer qu'ils sont les seuls attaquants à prendre le contrôle d'un site ».
Que faire en cas de doute ? Récupérer une ancienne sauvegarde d'avant le 15 octobre
De fait, il n'existe pas de solution miracle si vous n'avez pas appliqué le patch dès qu'il a été mis en ligne : « l'équipe de sécurité de Drupal recommande que vous consultiez votre hébergeur. S'il n'a pas patché Drupal ou bloqué les attaques par injection SQL dans les heures qui ont suivi l'annonce du 15 octobre à 16:00 UTC, restaurez votre site à une sauvegarde antérieur au 15 octobre 2014 ». La restauration doit être complète, c'est-à-dire inclure les fichiers Drupal, ceux uploadés ainsi que la base de données.
Commentaires (29)
#1
Je sens qu’une avalanche de troll anti-CMS/anti-framework va s’abattre sur ce post xD
Franchement c’est ballot mais tous les outils populaires ont un jour ou l’autre ce genre de problèmes qui sont dévoilés :/
#2
toutes les versions 7.x sont concernées
M’en fous je suis en 5.x
#3
1er piratage 7h après la découverte de la faille, ouch.
" />
Amis webmasters et admins, arrêtez de dormir pour être plus réactifs.
#4
Il n’y a aucun moyen également de vérifier que le site a été attaqué ?
#5
#6
yendis?
" />
allez va t’inquietes pas, ton site risque pas grand chose, c’est plutot les gros sites qui sont visé par les attaques.
si c’est un site amateur ayant une 100aine de visites/jours, tu risque pas grand chose.
bon apres si tu as 20 000 de visiteurs, là… je commencerais a flipper
#7
“La société vient donc de publier une alerte en précisant que, « dans les heures qui ont suivi » l’annonce de la mise à jour, des attaques ont commencé. ” Ils ne pouvaient pas déployer le patch en donnant le minimum d’information sur le type de faille afin de ne pas la rendre facilement exploitable ?
#8
Drupal est open source. Un simple diff du patch fournit aux pirates plus d’infos que le bulletin de sécurité :
Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.
A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.
This vulnerability can be exploited by anonymous users.
#9
Merci pour ta lanterne.
#10
Je me demande bien comment une injection SQL peut mener à une exécution de code arbitraire… Drupal ne stocke quand même pas du code PHP dans la base ?
#11
Par injection SQL on peut modifier le mot de passe du compte admin et a partir de là … y a plus de limites ma bonne dame.
#12
Le truc que je comprend pas c’est que Drupal annonce qu’on peut même avoir prit de contrôle du serveur entier à cause de cette faille… C’est étonnant, même un admin drupal, il peut quand même pas installer des services et compagnie, seulement des plugins à la portée extremement limité, non ?
#13
Déjà s’il y avait un système de mise à jour automatique je pense que les admins mettraient plus rapidement à jour leurs sites… Devoir à chaque fois retélécharger la totalité des fichiers, écraser les anciens fichiers et lancer le script de mise à jour, c’est quand même super archaïque… A côté de ça WordPress se met automatiquement à jour maintenant, sans même qu’on ait à cliquer sur le bouton “mettre à jour”…
#14
Sérieusement, le coup de « vous devez faire une restauration complète d’une sauvegarde d’il y a plus de quinze jours », c’est une gosse blague. Comment peut-on sérieusement oser proposer ça ?
D’accord, il faut se couvrir, et c’est un moyen radical d’éliminer le problème. Mais ne pas proposer de solution alternative, comment dire… Ça fait vraiment pas sérieux pour le coup (et pas rassurant sur l’outil).
#15
+1
Je pensais drupal plus sérieux que ça.
“« se mettre simplement à jour vers Drupal 7.32 ne supprimera pas les portes dérobées »”
De même que ne pas pouvoir fournir un outil de diag à minima…
#16
une faille liée à une injection SQL
What else ?
#17
En même temps n’importe qui peut absolument faire n’importe quoi avec ton site. Je ne vois pas comment ils pourraient fournir un outil pour analyser ça.
Comme dit par certains plus haut, c’est les outils les plus utilisés qui attirent le gros des attaques. Je suis sûr que ce genre de faille (corruption total du site) est trouvable dans n’importe quel CMS, il faut juste s’en donner les moyens pour les trouver.
Bref chez nous on a adopté la technique de l’autruche “il ne s’est rien passé >_>”
#18
Dans ce cas, rien n’est moins sûr. Les attaques se font souvent automatiquement :
#19
Ça n’empêche ils pourraient fournir la liste des enchainements courrants à une injection sql ds leur cms.
est-ce que le hash du mdp est facilement reversible etc…
Et peut être en profiter pour donner quelques conseils, ça mange pas de pain.
Dire euh bah z’avez été piratés, remonter dans le temps, 15jours après le drame moi j’ai plutôt envie de leur mettre leur manque de professionnalisme dans les dents.
#20
What year is it ?
Injection SQL en 2014 ?
#21
#22
C’est une exécution de code SQL arbitraire.
#23
Par injection SQL, tu te crées un administrateur du système et tu fais ce que tu veux.
#24
#25
Une fois que t’as accès à la base de données tu peux utiliser des callbacks comme menu_access qui te permettent d’executer du PHP pour créer des fichiers. J’ai retrouvé un site patché, un fichier php sur le serveur qui n’avait rien à faire là (vive git, je l’aurais jamais vu sinon) avec dedans du code permettant d’exécuter le contenu d’un cookie…
Soit dit en passant, au niveau de la sécurité sur Drupal, la faille était connue depuis mi-septembre, mais étant donné qu’il y avait la DrupalCon (une grosse conférence Drupal), beaucoup de développeurs n’étaient pas vraiment aptes à faire cette mise à jour de sécurité. Ils ont donc préféré attendre le 15 septembre pour faire l’annonce, parce qu’il fallait bien la faire un jour, au risque d’avoir des kiddiescripts qui se retrouvent sur le web…
#26
Et bien en 2014, l’utilisation des drivers PDO (ou MySQLi) est une généralité.
Donc pour avoir une faille de 1ère ordre, il faut vraiment y mettre de la mauvaise volonté. (Le “never trust user input” peut être oublié pour l’occasion)
Ensuite pour une faille de 2ème ordre, “never trust database data” ce n’est pas nouveau. C’est juste du mauvais database design si il y a cette faille (ou alors du mauvais filtering d’input)
#27
#28
#29
Pour approfondir un petit peu la question de cette faille de sécurité en particulier, et la sécurité de
drupal en général, je vous invite à lire cet article :
http://flocondetoile.fr/blog/drupal-sa-core-2014-005-mise-en-perspective-et-ense…
Concernant les outils, un certain nombre ont déjà été mis à disposition par la communauté. L’article en cite quelques uns.