Если сайт взломан, мало удалить с него вирус и загруженный PHP Shell. Нужно еще найти причину, по которой произошел взлом, иначе через день-два на сайте снова будет под бодрую музыку развеваться красивый турецкий иностранный флаг. Чаще всего причина — украденный пароль от FTP, устаревшая версия CMS или плагина к ней, но как найти, что именно было использовано для проникновения?
Имея некоторый опыт в этой сфере (в среднем наша техподдержка занимается поиском причины взлома сайта раз в неделю), мы систематизировали накопившуюся информацию.
Итак, зачем вообще взламывают сайты? И что делать, если сайт взломан, как найти причину и защититься от последующих атак?
Зачем взламывают сайты
Процесс взлома сайтов сейчас поставлен на поток. Ботнеты используют известные эксплойты к распространенным CMS, взламывают сайты, устанавливают на них свои скрипты и дальше могут использовать взломанный сайт в любых целях. Вирусы крадут пароли от FTP, подключаются к сайтам и заражают их вирусами, которые в свою очередь заражают посетителей сайтов, после чего круг повторяется. Чаще всего после взлома сайта происходит следующее:
Дефейс сайта. Это можно назвать, скорее, озорством, дальше дефейса дело часто не идет.
Заражение страниц сайта вирусом. Вирусы могут как просто добавляться в конец каждой страницы сайта, так и быть довольно изощренными. Например, нам встречался вирус, заражавший конкретный класс Joomla, отвечающий за вывод данных в браузер.
Поиск других сайтов в соседних папках и их заражение.
Рассылка спама.
Загрузка PHP Shell и выполнение произвольных действий — например, попытка взлома сервера с помощью существующих эксплойтов к операционным системам.
Установка ботов, которые подключаются к серверу IRC и могут выполнять произвольные команды «хозяина» — например, производить DDoS других сайтов.
То есть, действия взломщиков направлены на дальнейшее распространение ботов, создание сети (ботнета) и дальнейшее ее использование в своих целях.
Алгоритм поиска причины взлома
Алгоритм сам по себе очень простой:
Найти следы взлома.
Определить точное время взлома.
По логам найти, как именно поломали сайт.
Сложность составляет реализация пунктов 1 и 3. На них мы остановимся подробнее.
Как искать следы взлома
При взломе практически всегда остаются следы: файлы, которые злоумышленник использовал для работы, например, PHP Shell. Классический способ взлома CMS:
Через какую-либо уязвимость загрузить PHP Shell (или получить через уязвимость доступ администратора CMS и загрузить PHP Shell через менеджер файлов).
Через PHP Shell сделать все остальное.
Поэтому в первую очередь необходимо искать такие файлы — файлы, очевидно не принадлежащие сайту. Как правило, загруженные скрипты называются довольно необычно и сильно выделяются среди собственных скриптов CMS:
wzxp.php
gwd.php
a10881d.php.2046
Результат работы эксплойта, запущенного для взлома сервера, может выглядеть так:
./w.sh
./env
./env.c
./program.c
./program.o
./w00t.so.1.0
/tmp/sh
/tmp/sh2
Эти файлы могут быть расположены как в корне сайта, так и в папке tmp/ или cache/. Поискать их стоит также в папках вроде images/, upload/, user_files/ и т. д. — часто через уязвимости в редакторах или библиотеках фотографий скрипты загружаются именно в то место, куда обычно загружаются фотографии или хранятся временные файлы.
Помимо файлов сайта стоит также проверить общий /tmp сервера — в нем могут находиться временные файлы, использованные для взлома или для запуска ботов.
Обязательно загляните в файл .htaccess — в нем могут быть добавлены перенаправления на другие сайты, распространяющие вирус. При этом файл .htaccess может быть размещен как в корне сайта, так и выше, поэтому не поленитесь посмотреть все директории вашего аккаунта.
Иными словами, необходимо искать все необычное/непонятное и заглядывать внутрь всех подозрительных файлов. PHP Shell может выглядеть, например, так:
<?php #v2.3 //Version
$auth_pass = ""; //75b43eac8d215582f6bcab4532eb854e
$color = "#00FF66"; //Colour
$default_action = "FilesMan";
$default_charset = "Windows-1251";
preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65
\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7b1tVxs50jD8OXvO9R9Er3fanhhjm2Q2Y7ADIZCQSSAD5
GUC3N623bZ7aLs93W0Mk+W/31Wll5b6xZhkdq/7OedhJtDdKpVKUkkqlapK3rDM1tzJLL4tl7qn+ycf90/
// ... много кода в base64
Ключевые моменты, на которые стоит обращать внимание в скриптах PHP:
Co0lHaZZkeR'ский стиль написания текста.
Наличие слов Exploit и Shell.
Наличие большого количества кода в base64.
Наличие eval() или функции preg_replace() с ключом /e в первом аргументе.
В конце концов, можно просто зайти браузером и посмотреть, что делает этот скрипт.
Файлы можно искать и вручную, но быстрее, если взлом произошел недавно, воспользоваться командой find:
# find ./public_html -mtime -3d
# find ./public_html -mtime -10h
(синтаксис find указан для FreeBSD). Эти команды покажут файлы, изменявшиеся за последние три дня и последние 10 часов, соответственно.
Если ничего не помогает, можно просто поискать все файлы, содержащие закодированное в base64 содержимое, например, так:
# find ./ -name '*.php' | xargs grep -E '[0-9a-zA-Z/]{80}'
Эта команда найдет все скрипты PHP, в которых есть строки, похожие на base64 длиной не менее 80 символов.
Определение времени взлома
Когда файлы найдены, определить время взлома очень просто — достаточно посмотреть время изменения самого раннего файла.
Если подозрительных файлов не найдено, но сайт заражен вирусом, посмотрите дату изменения файлов index.php, index.html или тех, в которых обнаружите вирус. Скорее всего в этом случае сайт взломали, украв пароль от FTP.
Поиск журналов взлома сайта
Теперь самое главное — чтобы эти журналы были в наличии!
Если на сайте только произведен дефейс или добавлен вирус ко всем файлам index.html, скорее всего, сайт взломали через кражу пароля FTP (или, гораздо реже, SSH). Посмотрите журналы подключения по FTP и SSH во время взлома — присутствие в нем неизвестных IP-адресов или большого количества разных IP-адресов, осуществивших успешное подключение к сайту, означает, что пароль украден.
В этом случае достаточно проверить компьютеры, с которых осуществлялся доступ к сайту, на вирусы, сменить пароли FTP и никогда больше не сохранять пароли в клиентах FTP.
Если же на сайте присутствуют PHP Shell или вредоносные скрипты (например, для рассылки спама), скорее всего, сайт взломали через уязвимость в CMS или каком-либо её плагине. В этом случае потребуется проанализировать логи веб-сервера.
Чтобы лучше понять, что необходимо искать, рассмотрим, как происходит взлом CMS.
Злоумышленник определяет, что на сайте установлены CMS или ее плагины, либо другое ПО (устаревшая Joomla, phpMyAdmin, редактор WYSIWYG, галерея фотографий и т. д.), потенциально подверженные уязвимости.
Он начинает перебирать известные эксплойты к этому ПО. Цель — каким-либо образом загрузить свой файл на сайт.
Когда уязвимость найдена, взломщик загружает PHP Shell.
Подключившись к PHP Shell, взломщик получает полный доступ к сайту и дальше может использовать его в любых целях.
Важный момент — загрузка PHP Shell. В предыдущей части мы определили, в какое время на сайт были загружены вредоносные скрипты. Теперь достаточно найти обращения к ним в журнале веб-сервера. Таким образом мы сможем определить IP-адрес злоумышленника. Это можно сделать простым grep'ом в access.log по имени файла PHP Shell'а.
Если удалось определить IP-адрес
Определив IP-адрес взломщика, мы производим поиск этого IP-адреса по журналу веб-сервера и видим все действия, которые он совершал. Где-то близко к моменту обращения к PHP Shell будет успешное использование уязвимости сайта.
Если определить IP-адрес не удалось
Описанный выше способ работает, если известно конкретное имя файла, через которое производилась работа с сайтом после взлома. Однако это имя не всегда известно. В этом случае придется поискать момент взлома немного подольше, но найти его все равно можно.
Большинству, подавляющему большинству взломов свойственны запросы HTTP POST, так как через них происходит загрузка файлов на взламываемый сайт. Через POST злоумышленник может также пытаться взломать форму ввода пароля или просто зайти в раздел администрирования с украденным паролем.
Если известно время взлома сайта (а мы его уже знаем), необходимо поискать в журнале веб-сервера все запросы POST, находящиеся близко ко времени взлома. Здесь нет конкретных советов — выглядеть они могут совершенно по-разному, но выглядеть они будут в любом случае необычно. Например, это могут быть запросы, содержащие '../../../../' или длинные запросы, содержащие имена файлов или запросы SQL.
Если ничего не удалось найти
Такое тоже может быть. В этом случае можно порекомендовать только чистую переустановку CMS и ее расширений и последующий импорт данных. Обязательно убедитесь, что версия CMS и ее расширений — последняя.
И ее расширений! Чаще всего взломы производятся не через ядро системы управления сайтом, а через какой-нибудь устаревший плагин, автор которого давно забросил его разработку.
Ну и, разумеется, смените все пароли, которые имеют какое-либо отношение к сайту.
Хозяйке на заметку
В процессе поиска уязвимостей на сайте, если нет возможности заблокировать к нему доступ посетителей, заблокируйте хотя бы запросы POST. Это предотвратит возможность применения большинства стандартных эксплойтов.
Не используйте устаревшие версии CMS и плагинов к ним. Следите за обновлениями!
После определения причины взлома не ограничивайтесь удалением найденных скриптов — добавленные злоумышленником точки проникновения могут быть хорошо спрятаны. Лучшая схема восстановления сайта после взлома — это закрыть к нему доступ посетителей, найти причину взлома, восстановить сайт из резервной копии (этим мы исключаем любые изменения сайта, которые мог произвести злоумышленник), обновить CMS, убедившись, что уязвимый компонент также обновился, после чего снова открыть доступ к сайту.
