Drupal alerte sur une faille SQL comblée… mais pas pour tout le monde
Parfois, ce sont même les pirates qui patchent !
Le 03 novembre 2014 à 17h10
3 min
Internet
Internet
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 à 23 h 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.
Drupal alerte sur une faille SQL comblée… mais pas pour tout le monde
-
Drupal mis à jour à cause d'une faille liée à une injection SQL
-
Si vous n'avez pas été assez rapide, votre site peut être compromis malgré tout
-
Que faire en cas de doute ? Récupérer une ancienne sauvegarde d'avant le 15 octobre
Commentaires (29)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 03/11/2014 à 17h31
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 :/
Le 03/11/2014 à 17h57
toutes les versions 7.x sont concernées
M’en fous je suis en 5.x " />
Le 03/11/2014 à 17h57
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. " />
Le 04/11/2014 à 09h30
What year is it ?
Injection SQL en 2014 ?
Le 04/11/2014 à 09h48
Le 04/11/2014 à 10h43
C’est une exécution de code SQL arbitraire.
Le 04/11/2014 à 10h50
Par injection SQL, tu te crées un administrateur du système et tu fais ce que tu veux.
Le 04/11/2014 à 11h17
Le 04/11/2014 à 11h28
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…
Le 04/11/2014 à 11h44
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)
Le 04/11/2014 à 12h51
Le 04/11/2014 à 13h46
Le 05/11/2014 à 06h49
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.
Le 03/11/2014 à 18h22
Il n’y a aucun moyen également de vérifier que le site a été attaqué ?
Le 03/11/2014 à 18h22
Le 03/11/2014 à 19h44
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 " />
Le 03/11/2014 à 21h01
“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 ?
Le 03/11/2014 à 21h11
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.
Le 03/11/2014 à 21h12
Merci pour ta lanterne.
Le 03/11/2014 à 22h19
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 ?
Le 03/11/2014 à 23h43
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.
Le 04/11/2014 à 08h01
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 ?
Le 04/11/2014 à 08h14
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”…
Le 04/11/2014 à 08h19
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).
Le 04/11/2014 à 08h23
+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…
Le 04/11/2014 à 08h26
une faille liée à une injection SQL
What else ?
Le 04/11/2014 à 08h32
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é >_>”
Le 04/11/2014 à 08h40
Dans ce cas, rien n’est moins sûr. Les attaques se font souvent automatiquement :
Le 04/11/2014 à 08h41
Ç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.