IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Des pirates se servent d'attaques par injection de SQL pour attaquer des sites conçus avec le CMS Drupal
Et y installer de faux ransomware

Le , par Stéphane le calme

218PARTAGES

6  0 
Des attaquants se sont servis d’une vulnérabilité sur Drupal, le système de gestion de contenu libre et open source, vieille de deux ans, pour installer un ransomware qui détourne la page d’accueil du site piraté, mais qui, contrairement à ses confrères, ne chiffre pas les fichiers.

C’est sur un forum Drupal que l’opération a été repérée. L’utilisateur derrière le pseudonyme « reset91 » a indiqué le 23 mars dernier que son site web affiche « site web verrouillé. S’il vous plait veuillez transférer 1,4 Bitcoin à l’adresse 3M6SQh8Q6d2j1B4JRCe2ESRLHT4vTDbSM9 pour en déverrouiller le contenu ». En faisant une recherche sur le moteur de Google avec cette adresse comme requête, il s’est avéré que plusieurs sites ont été affectés du même problème.

Stu Gorton, le PDG et cofondateur de Forkbombus Labs, a fourni des informations indiquant que la première infection a été observée le 11 mars et que le rythme des infections s’est accéléré après le 18 mars.

Comment l’infection se produit-elle ? Forkbombus Labs indique que les bots des pirates commencent par scanner les sites web à la recherche de /CHANGELOG.txt, un fichier spécifique au CMS Drupal, mais également à la recherche des fichiers /joomla.xml. Par la suite, les bots vont extraire la version Drupal du site et se servir de la faille répertoriée comme étant CVE-2014-3704 pour pénétrer les sites web et éventuellement modifier le mot de passe administrateur. Pour rappel, la faille CVE-2014-3704,qui affecte les versions 7.x de Drupal avant la version 7.32, désigne une vulnérabilité dans la fonction expandArguments qui permet à des attaquants de lancer des attaques par injection SQL.

Une fois que les attaquants ont pris le contrôle du site après des injections SQL, des opérations automatisées mettent sur place une nouvelle page sur la version Drupal du site sur laquelle sera affiché un formulaire d’upload. Le bot se sert de cette page pour uploader différents scripts qui vont extraire des informations comme les adresses mails et les rendre disponibles sur le chemin /sites/default/files/ sous forme de fichiers téléchargeables. Le .htaccess sera effacé afin que les pirates puissent avoir accès à la page et y télécharger les fichiers.

Par la suite, un binaire écrit dans le langage de programmation Go sera uploadé : le ransomware. Ce dernier va alors supprimer le formulaire d’upload et le remplacer par le message qu’a reçu l’utilisateur « reset91 ».

« Il doit apparaître qu’il s’agit là d’un faux someware et non d’un véritable ransomware et rien n’est vraiment chiffré ou verrouillé », a expliqué Stu Gorton. Et de continuer en disant « ici, le contenu des nœuds disponibles a été remplacé par le nouveau message. Cependant, il semblerait que le bot ait quelques difficultés à remplacer les informations sur des nodes avec des formats atypiques, étant donné que, parmi les différents sites compromis que nous avons observés, plusieurs avaient une large portion de leurs données qui s’avéraient être intactes ». Il a également expliqué qu’il y avait une infrastructure C&C derrière cette attaque.

Le blockchain utilisé pour la transaction n’enregistre à l’heure actuelle aucun versement. Toutefois, cette campagne met en exergue deux éléments. Le premier est la nécessité des mises à jour, dans la mesure où elles viennent colmater des failles de sécurité qui étaient exploitables par des pirates. Et le second est le fait que les ransomwares deviennent des logiciels malveillants vers lesquels se tournent de plus en plus de pirates, bien qu’il ne s’agisse là que d’une tentative qui a échoué.


Source : blog Drupal, CVE-2014-3704, info sur le blockchain, Softpedia

Voir aussi :

le forum CMS (Drupal)

Panama Papers : des versions vulnérables de WordPress et Drupal auraient-elles contribué à la plus grande fuite de données de l'histoire ?

Drupal 8 est maintenant disponible en version stable, le CMS apporte plusieurs nouveautés avec cette dernière version

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Juda-Priest
Membre actif https://www.developpez.com
Le 25/05/2016 à 8:37
J'aimerais juste ajouter deux petites notes à la chronique :

Ce sujet remonte bien l'importance de l’administrateur système à faire des back-up réguliers. Et celui de l'administrateur du site à faire les Mise à jour de sécurité.

Reset91 aurais pu s’éviter bien des peines.
0  0 
Avatar de GoustiFruit
Membre éclairé https://www.developpez.com
Le 25/05/2016 à 15:52
Drupal est tellement compliqué, je plains le M. Tout Le Monde qui voudrais sécuriser son site sous Drupal ! :-O
0  0 
Avatar de dasdeb
Membre actif https://www.developpez.com
Le 25/05/2016 à 17:14
Ils ne filtrent pas les injections SQL au niveau du serveur (Apache, nginx) ?
Je n'arrive pas à comprendre pourquoi, sur des serveurs dédiés, ce n'est pas le cas.

N'ayant jamais utilisé IIS, je ne sais pas si c'est possible, mais sur mes serveurs, j'ai déporté une bonne partie de la gestion de la sécurité au niveau du logiciel serveur.
0  0 
Avatar de Equilibrius
Nouveau membre du Club https://www.developpez.com
Le 25/05/2016 à 19:48
@dasdeb : si tu filtre le SQL coté apache, a dieux phpmyadmin et tous les autres tools du genre. La sécurité doit commencer niveau php a mon avis, la règle est pourtant simple, never trust user input.

(Dans les sources le lien vers CVE-2014-3704 est erroné)
0  0 
Avatar de zecreator
Membre expert https://www.developpez.com
Le 06/06/2016 à 7:49
Drupal, j'ai jamais trop aimé ce "truc". Mais comme il est utilisé massivement, il est donc indispensable.
0  0 
Avatar de sabotage
Modérateur https://www.developpez.com
Le 06/06/2016 à 9:59
Ils ne filtrent pas les injections SQL au niveau du serveur (Apache, nginx) ?
C'est qui "ils" ?
0  0 
Avatar de Tsilefy
Membre émérite https://www.developpez.com
Le 07/06/2016 à 0:46
Citation Envoyé par GoustiFruit Voir le message
Drupal est tellement compliqué, je plains le M. Tout Le Monde qui voudrais sécuriser son site sous Drupal ! :-O
Drupal n'est pas pour M Tout Le Monde, en règle général. M Tout Le Monde utilise Wordpress qui est, comme on le sait, beaucoup plus sécurisé /s
0  0 
Avatar de Tsilefy
Membre émérite https://www.developpez.com
Le 07/06/2016 à 0:55
Citation Envoyé par dasdeb Voir le message
Ils ne filtrent pas les injections SQL au niveau du serveur (Apache, nginx) ?
Je n'arrive pas à comprendre pourquoi, sur des serveurs dédiés, ce n'est pas le cas.

N'ayant jamais utilisé IIS, je ne sais pas si c'est possible, mais sur mes serveurs, j'ai déporté une bonne partie de la gestion de la sécurité au niveau du logiciel serveur.
Tu peux utiliser un module comme modSecurity pour bloquer les tentatives d'injection SQL au niveau d'Apache, mais il faut savoir le régler sinon le serveur devient inutilisable (trop de faux positifs) ou ouvert aux quatres vents (liste blanche trop ouverte).

Dans tous les cas, in fine c'est de la responsabilité de l'application, pas du serveur, qui est juste là pour bloquer les tentatives connues.
0  0 
Avatar de ABCIWEB
Expert éminent sénior https://www.developpez.com
Le 12/06/2016 à 3:41
Citation Envoyé par Tsilefy Voir le message
Drupal n'est pas pour M Tout Le Monde, en règle général. M Tout Le Monde utilise Wordpress qui est, comme on le sait, beaucoup plus sécurisé /s
Les sites wordpress sont également très vulnérables dès que l'on ne fait pas les mises à jour. Peut-être le moteur lui-même est mieux sécurisé mais il faut compter aussi sur les modules externes. Enfin bref si on devait faire le compte des serveurs piratés faute à un cms, wordpress arriveraient sans problème en tête, non pas qu'il est plus ou moins bien sécurisé mais parce qu'il est tellement employé qu'il est une cible de choix, et il y a tellement de modules complémentaires qu'il est assez facile d'en trouver un qui a des failles de sécurité.

Je dis cela au passage pour tempérer un peu ce que ton message laisse sous-entendre. Utiliser wordpress ne garanti rien du tout, les maj du système et des modules complémentaires sont absolument indispensables. C'est la rançon de l'open source.
0  0 
Avatar de Tsilefy
Membre émérite https://www.developpez.com
Le 14/06/2016 à 1:06
Citation Envoyé par ABCIWEB Voir le message
Les sites wordpress sont également très vulnérables dès que l'on ne fait pas les mises à jour. Peut-être le moteur lui-même est mieux sécurisé mais il faut compter aussi sur les modules externes. Enfin bref si on devait faire le compte des serveurs piratés faute à un cms, wordpress arriveraient sans problème en tête, non pas qu'il est plus ou moins bien sécurisé mais parce qu'il est tellement employé qu'il est une cible de choix, et il y a tellement de modules complémentaires qu'il est assez facile d'en trouver un qui a des failles de sécurité.

Je dis cela au passage pour tempérer un peu ce que ton message laisse sous-entendre. Utiliser wordpress ne garanti rien du tout, les maj du système et des modules complémentaires sont absolument indispensables. C'est la rançon de l'open source.

J'ai mis /s à la fin pour signifier que c'était un sarcasme.

Apparemment, ça n'est pas passé

Bien sûr que Wordpress est infiniment plus vulnérable que Drupal.
0  0