Vallyol's Blog

03/11/2014

Друпал 7, уязвимость SA-CORE-2014-005 — SQL injection

Filed under: Drupal, Web — Метки: , , , — vallyol @ 20:35

Прошу прощения за информацию двухнедельной давности, но развитие событий, как мне кажется, требует упоминания 🙂

Предыстория.

Одна компания (название нигде не упоминается) обратилась в SektionEins (секьюрные консультанты, специализируются на поиске утечек и уязвимостей в вэб- и мобильных приложения) с вопросом анализа безопасности Друпал. В результате проведенных исследований спецы подготовили документ под названием Drupal — pre Auth SQL Injection Vulnerability. Дата публикации — 16 сентября 2014 года. Главный вывод, сделанный специалистами — злоумышленник может получить полный контроль над Друпал-сайтом, не используя каких бы то ни было типов авторизации:

A malicious user can inject arbitrary SQL queries. And thereby control the complete Drupal site. This leads to a code execution as well.
This vulnerability can be exploited by remote attackers without any kind of authentication required.

Поэтому, 15 октября появляется обновление движка, закрывающее эту уязвимость. На тот момент обновлению был присвоен секьюрити риск 20/25, что на обычном языке звучит как «высоко критическое». Главная рекомендация — обновить незамедлительно! Как выяснилось… это было только начало.

Сама история.

25 октября я получаю письмо от хостера:

На вашем аккаунте обнаружены файлы, содержащие вредоносный код.
Используя данное вредоносное программное обеспечение, злоумышленники производят атаки сторонних серверов, рассылку спама и другие вредоносные действия. Файлы, содержащие вредоносный код, были доступны по ссылкам:
название_сайта/modules/node/model.php

Про скомпроментированный сайт… Сайт клиентов, отказавшихся от обслуживания. Друпал там был 7.17, актуальный релиз того времени, когда я его делал.
На самом деле, файл — добавленный, в ядре его быть не может. На всякий случай закинул его на Вирустотал. Затем пролечил сайт, обновил, сменил всевозможные пароли (почта, ssh), закрыл ftp доступ и … отписался хостеру. Типа, всё ОК.

Через 5 дней получаю письмо аналогичного содержания… Ситуация один в один: тот же самый лишний файл в нодах, только Друпал актуальный, версии 7.32. Вместо того, чтобы заморачиваться сменой паролей или сканированием локального компа на предмет вирусов (у меня — Линукс) иду на друпал.орг и на странице обновления обнаруживаю некоторые изменения.
Во-первых, ребята пересчитали риски, теперь 25/25. То есть, хуже некуда…
Во-вторых, сразу бросается в глаза

This vulnerability can be exploited by anonymous users.

Может, оно и раньше было?.. Но чего сейчас делать?

А чего делать — описано на самом друпал.орг. Но звучит это конкретно устрашающе:

You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.

То есть, если Вы не обновили свой Друпал 7 сайт в течении 7 часов после анонсирования выхода версии 7.32 — можете считать свой сайт скомпроментированным! И обновление сейчас — просто не поможет

Если почитать комментарии сообщества, можно найти множество примеров возникших проблем и предложений для их решения. Были описаны случаи, совпадающие с моим. Получается, тот мой клиент попал под общую раздачу 🙂

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

1) перевести сайт в оффлайн (можно удалить файл index.php или переименовать его в index.php.old, в корневой каталог положить пустой index.html)
2) уведомить хостера/администратора (мне этого делать не пришлось, хостер сам уведомил меня)
3) удалить все файлы вэб-сайта и базы данных с сервера
4) найти бэкапы, созданные ДО 15 октября сего года, залить файлы на сервер и импортировать базы данных
5) обновить Друпал до версии 7.32 (можно применить патч)
6) вернуть сайт в онлайн (действия, обратные пункту 1)
7) руками проделать ту работу, что была выполнена на сайте с момента последнего бэкапа
8) провести аудит сайта

В моем примере… Обновленный сайт крутится три дня. Рецидивов пока замечено не было, тьфу-тьфу-тьфу.

Инструменты для аудита…

Каждый может использовать наиболее близкие его сердцу. Я остановился на таких:
— связка модулей Hacked! и Diff (первый модуль показывает, что творится в Вашей «файловой» системе по типу изменено/удалено, а второй позволяет увидеть внесенные в файлы изменения из сравнения с «оригиналом»)
— модуль security review (много чего тестирует нажатием на одну кнопку, например — каталоги с правами на запись, разрешение недоверенным пользователям использовать опасные html тэги и пр., правда у меня есть сомнения относительно тех прав на каталоги, которые этот модуль рекомендует)
— модуль coder (всегда думал, что он нужен только для проверки кода на соответствие стандартам, очень интересный модуль)
— модуль security kit (на данный момент про него ничего не скажу)
Site Audit + Drupalgeddon (это не модули, это drush-команды, первая позволяет вывести отчет о состоянии сайта, включая рекомендации по структуре, содержимому, а также общий отчет, касающийся безопасности сайта, вторая — проводит проверку сайта на предмет наличия бэкдоров и пр. хни)

Про ограничения…

Совсем не обязательно, что всё из ниже перечисленного будет мешать Вам в работе с сайтом. И я не утверждаю, что перечислю абсолютно всё. Я сам многого не знаю…
1. Хостер может не иметь антивирусного сканера или не разрешать использовать его пользователям, или предлагать его как платную услугу. Выход — локальное сканирование.
2. Хостер может запретить пользователю использовать «свой» сканер, мой — просто убивает процесс при определенной нагрузке в течении скольких-то там секунд. Опять же, сканировать локально.
3. Локальное сканирование может просто не дать результата в силу того, что антивирусы «не заточены» под работу с сайтами; в качестве примера — ссылка на вирустотал в начале поста. Файл явно имеет «зловредный» характер, если учесть его внедренность и внутреннее содержимое. Но кто его опознал? Выход — использовать специализированные продукты, например, Ай-Болит.
4. Сканирование онлайн, когда Вы скармливаете ссылку онлайн антивирусу, может не дать результата; я вообще не уверен, проверяют ли онлайн сканеры что-нибудь кроме введенной ссылки.
5. О дополнительных инструментах типа site_audit.
Это команда drush, друпал шела. То есть, необходимое условие — установленный драш (?друш). Вроде не проблема… Его можно поставить руками, если pear или composer не доступны. И пользоваться, прописывая полный путь к исполняемому файлу (сим-линки Вам хостер создать не позволит). Или создав псевдоним в bash_alias на сервере.

P.S. В результате всего случившегося можно сделать два вывода:
— о необходимости своевременных обновлений (как это звучит сейчас, в свете последних событий!!! не успел в течении 7 часов — скомпроментирован!);
— о необходимости создавать резервные копии (мне повезло с клиентским сайтом, повезло дважды: у меня хранилась копия сайта на момент создания — ноябрь 2012-го и сам клиент за все это время не создал ни одного материала)

Реклама

Блог на WordPress.com.

%d такие блоггеры, как: