«Играем в доктора»: неправильное противодействие целевому взлому сайта

Часто при взломе коммерческого сайта (интернет-магазина), особенно в случаях, когда взлом целевой и хакер начинает шантажировать владельца (требовать денежную компенсацию за восстановление удаленной базы данных или постоянного уничтожения шаблонов сайта), на помощь владельцу сайта приходят программисты и администраторы, которые обслуживают веб-ресурс. Начинается процесс бесконечного восстановления сайта из бэкапов, смены паролей, попыток защиты от хакера, «охоты на ведьм», выгрузки пока еще рабочей версии сайта на локальный компьютер и прочая суета вокруг взломанного ресурса.

Хакеру эта «движуха» обычно нравится и он принимает в ней активное участие. Восстановили сайт из бэкапа? Он снова удаляет базу данных. Удалили вирусный код? Он его снова внедряет в шаблоны. И так по кругу: сайт по-прежнему открывается «белым листом» или продолжает перенаправлять посетителей на опасные сайты.

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

Хорошо, если остались какие-то старые бэкапы, из которых можно восстановить интернет-магазин. Но, как показывает практика, это дело не одного дня.

В чем ошибка владельцев сайтов в подобных случаях? Почему программисты, администраторы и добрые люди с веб-мастерских форумов не помогли сохранить сайт, а скорее навредили, оказывая «медвежью услугу» своими некомпетентными действиями и советами? Причина в том, что все они не знакомы с механикой взломов CMS: какие уязвимости и лазейки различных «движков» используют хакеры, какие ошибки конфигурации сервера позволяют им успешно проводить повторный взлом и заражение ресурсов. Недостаточно хорошо программировать на PHP или уверенно работать в консоли Unix, чтобы обеспечить безопасность веб-ресурса. Даже опытные системные администраторы не смогут защитить интернет-магазин от целенаправленного взлома. Необходимо полное погружение в сферу информационной безопасности сайтов: практиковать разбор инцидентов с анализом логов скомпрометированных ресурсов, следить за анонсами публичных критических уязвимостей и уязвимостей «нулевого дня», лечить сайты от вирусов и хакерских скриптов, анализировать уязвимые CMS и плагины, следить за новыми хакерскими инструментами и т.п. Без этого невозможно оперативно, качественно и гарантированно решить проблему, особенно, если сайт «бомбят» прицельно.

Самолечение сайта недостаточно компетентными специалистами сродни попытке вырезать аппендицит подручными средствами в домашних условиях. Ничего хорошего из этого не получится.

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

Хакер находит жертву через Google, используя Google Dork запрос или через тематические каталоги сайтов. Далее уничтожает базу данных, вставляет в главный шаблон сайта свой email с требованием выкупа за восстановление базы данных.

Смотрите также

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

Первое, что делает владелец интернет-магазина – это восстанавливает базу и файл из бэкапа сам. Сайт работает пару часов, затем снова становится недоступным, а база данных — пустой. Подключает программистов, те предлагают «запретить изменения на сайте, чтобы хакер не смог его взломать». Если перевести это на технический язык, они предлагают всем файлам интернет-магазина установить права «readonly», полагая, что это на 100% защищает сайт от взлома и уничтожения. Владелец сайта соглашается, но через пару часов сайт снова в том же поврежденном состоянии: база данных пустая, а в индексном шаблоне сайта добавлен email хакера. Спустя пару дней программисты сдаются и предлагают владельцу все-таки обратиться к специалистам по безопасности.

Наконец, приходят ИБ специалисты и видят окончательно «доломанный» сайт (причем, доломан он не хакером), отсутствие актуальных логов со следами взлома (зашумленный активными действиями «помогателей»), сбитые настройки хостинга, несколько нерабочих копий сайта с вирусами и хакерскими шеллами, пепел и прочую разруху на сервере. А всего-то нужно было закрыть phpMyAdmin на сервере от внешнего доступа, заблокировать доступ через веб к конфиг-файл WebAsyst (который в старых версиях публично доступен, а в нем лежат доступ к БД) и сменить пароль от базы данных. Но могли ли знать программисты и сам владелец сайта, что сайт ломают через базу данных, компрометируя доступы к БД через xml файл и используя phpMyAdmin? Вряд ли. Иначе они бы сделали это сразу. А сколько можно было сэкономить времени и денег?

Другой пример – с Битриксом. Там тоже программисты, администраторы и хостер несколько дней пытались «победить в схватке» с хакером, но каждый день вирус снова появлялся на страницах интернет-магазина. А в силу высокой посещаемости проекта, распределенной архитектуры на несколько серверов и собственного системного администратора, возможность оперативного анализа инцидента значительно усложнялась. Причину нам все-таки удалось обнаружить: оказалось, что хакер с помощью брутфорса подобрал пароль от админ-панели Битрикса, внедрил хакерский скрипт в базу, дождался создания резервной копии, а далее просто восстанавливал сайт из бэкапа с помощью любезно размещенного в корневом каталоге файла restore.php. Ему не потребовалось ни наличие хакерского веб-шелла, ни root доступа к серверу, чтобы каждое утро восстанавливать вирус на сайте.

Таких примеров можно привести десятки. Любая CMS, конфигурация VPS и share-хостинги имеют свою специфику настроек и работы, известные публично (и не очень) уязвимости, которыми пользуются хакеры.

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

Однако и с вашей стороны можно предпринять ряд полезных действий, которые помогут выйти из сложившейся ситуации с наименьшими потерями:

1) Если хакер вступил в переговоры, продолжайте общаться с ним, интересуйтесь деталями взлома, просите доказать, что нарушитель, действительно имеет доступ к вашему сайту.
2) Сделайте бэкап сайта и сохраните его локально, чтобы иметь у себя рабочую версию (пусть взломанную, но с работающими скриптами и целой Базой Данных).
3) Смените пароли от email и подключите на него двухфакторную аутентификацию, чтобы исключить утечку доступов от почтового ящика, к которому привязан хостинг и административные аккаунты.
4) Поменяйте доступы к хостингу (к панели управления; SSH, FTP) и к панели управления.
5) Будет не лишним проверить компьютеры, с которых выполняется администрирование сайта, коммерческим антивирусом (возможно, произошла утечка паролей с рабочей машины, зараженной троянской программой и пр.).

Ну, и самое главное, защищайте ваши веб-проекты своевременно, не оставляя злоумышленникам шансов на успешную атаку.