Connexion
Abonnez-vous

Drupal alerte sur une faille SQL comblée… mais pas pour tout le monde

Parfois, ce sont même les pirates qui patchent !

Drupal alerte sur une faille SQL comblée... mais pas pour tout le monde

Le 03 novembre 2014 à 17h10

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.

Commentaires (29)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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 :/

votre avatar



toutes les versions 7.x sont concernées





M’en fous je suis en 5.x <img data-src=" />

votre avatar

1er piratage 7h après la découverte de la faille, ouch.

&nbsp;Amis webmasters et admins, arrêtez de dormir pour être plus réactifs. <img data-src=" />

votre avatar

What year is it ?

Injection SQL en 2014 ?

votre avatar







BabyAzerty a écrit :



What year is it ? Injection SQL en 2014 ?



Pas compris où tu voulais en venir, il n’y a plus de sql en 2014 ?


votre avatar

C’est une exécution de code SQL arbitraire.

votre avatar

Par injection SQL, tu te crées un administrateur du système et tu fais ce que tu veux.

votre avatar







psn00ps a écrit :



Par injection SQL, tu te crées un administrateur du système et tu fais ce que tu veux.





Ça c’est faux.



Il faut bien comprendre que tout le monde n’a pas une installation foireuse où tous les services ont tous les droits. Donc pour résumer, mon drupal :




  • accède à la bdd avec un utilisateur qui n’a que les droits sur cette base en question, et certainement pas les droits root sur le serveur bdd

  • tourne sur un apache qui n’a que les droits de l’utilisateur apache

    &nbsp;

    Donc non, mon système n’est pas corrompu. Mon drupal, peut-être. Mais depuis mon système, je devrais pouvoir faire une analyse de :

  • mes fichiers drupal et vérifier qu’ils ne contiennent pas de fichiers superflus / symptomes d’une attaque

  • ma bdd, et idem.



    Là le problème, c’est que je sais qu’il y a peut-être eu une attaque, mais que je ne sais même pas ce que je dois chercher. Avoir quelques pistes ne serait pas de trop. La seule chose que j’ai pu analyser, ce sont les logs, mais là encore je ne suis pas sûr de ce qu’il faut chercher et en plus, pour le coup c’est un truc qui a pu être corrompu.



    Bref, ça fait vraiment pas sérieux et ça donne vraiment pas confiance dans l’outil.


votre avatar

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…

votre avatar

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)

votre avatar







white_tentacle a écrit :



Ça c’est faux.



Il faut bien comprendre que tout le monde n’a pas une installation foireuse où tous les services ont tous les droits. Donc pour résumer, mon drupal :




  • accède à la bdd avec un utilisateur qui n’a que les droits sur cette base en question, et certainement pas les droits root sur le serveur bdd

  • tourne sur un apache qui n’a que les droits de l’utilisateur apache

    &nbsp;

    Donc non, mon système n’est pas corrompu. Mon drupal, peut-être. Mais depuis mon système, je devrais pouvoir faire une analyse de :

  • mes fichiers drupal et vérifier qu’ils ne contiennent pas de fichiers superflus / symptomes d’une attaque

  • ma bdd, et idem.



    Là le problème, c’est que je sais qu’il y a peut-être eu une attaque, mais que je ne sais même pas ce que je dois chercher. Avoir quelques pistes ne serait pas de trop. La seule chose que j’ai pu analyser, ce sont les logs, mais là encore je ne suis pas sûr de ce qu’il faut chercher et en plus, pour le coup c’est un truc qui a pu être corrompu.



    Bref, ça fait vraiment pas sérieux et ça donne vraiment pas confiance dans l’outil.





    Je te conseille de faire des checksum de tout tes fichiers d’aujourd’hui et de la dernière sauvegarde. Si les checksum sont différents et s’il y a de nouveaux fichiers, tu te les paluches à la mano. Mais si tu trouve certain fichier modifié alors qu’il n’y aurais pas dû, tu fais une restaure complète.&nbsp;



    BabyAzerty a écrit :



    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)



    Utiliser un driver PDO n’empêche pas d’avoir des failles ;-)


votre avatar







5h31k a écrit :



Je te conseille de faire des checksum de tout tes fichiers d’aujourd’hui et de la dernière sauvegarde. Si les checksum sont différents et s’il y a de nouveaux fichiers, tu te les paluches à la mano. Mais si tu trouve certain fichier modifié alors qu’il n’y aurais pas dû, tu fais une restaure complète.&nbsp; Utiliser un driver PDO n’empêche pas d’avoir des failles ;-)





En fait, l’utilisateur web n’a pas les droits pour écrire les sources de drupal (c’est la base en terme de sécurité, mais drupal avec son système de màj web incite à faire le contraire…). Donc côtés fichiers, pas de soucis.



Mon inquiétude concerne plutôt la bdd, et là, je ne sais pas ce que je dois vérifier. Après, j’ai fait la màj une dizaine d’heure après l’heure fatidique, donc le risque est ténu, mais pas totalement inexistant…


votre avatar

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.

votre avatar

Il n’y a aucun moyen également de vérifier que le site a été attaqué ?

votre avatar







Crysalide a écrit :



1er piratage 7h après la découverte de la faille, ouch.

&nbsp;Amis webmasters et admins, arrêtez de dormir pour être plus réactifs. <img data-src=" />





En tant que webmaster amateur, c’est pas évident, je fais ça sur mon temps libre (donc pas pendant le boulot), …


votre avatar

yendis?&nbsp;



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 <img data-src=" />

votre avatar

“La société vient donc de publier une alerte en précisant que, «&nbsp;dans les heures qui ont suivi&nbsp;» l’annonce de la mise à jour, des attaques ont commencé.&nbsp;”&nbsp;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 ?

votre avatar

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.

votre avatar

Merci pour ta lanterne.

votre avatar

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 ?

votre avatar

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.

votre avatar

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 ?

votre avatar

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”…

votre avatar

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).

votre avatar

+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…

votre avatar



une faille liée à une injection SQL





What else ?

votre avatar

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é &gt;_&gt;”

votre avatar

Dans ce cas, rien n’est moins sûr. Les attaques se font souvent automatiquement :




  • Détection de Drupal via les moteurs de recherche

  • Vérification de la présence de la faille

  • Vérolage du site



votre avatar

Ç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.

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

Fermer