Не секрет, что большинство сайтов в наши дни взламываются не вручную. Есть большая армия ботов, которые ищут уязвимость в скриптах сайтов, брутфорсят админ-панели CMS, FTP/SSH аккаунты, затем загружают небольшие скрипты-загрузчики или бэкдоры, через них внедряют в скрипты сайта несколько десятков управляющих «агентов», а также раскидывают по случайным каталогам, открытым на запись, веб-шеллы, спам-рассыльщики и другие вредоносные php (и иногда perl) скрипты. Изнутри зараженный сайт выглядит примерно так (фрагмент отчета сканера AI-BOLIT):
Паттерны заражения (число, состав и назначение вредоносных скриптов) могут меняться. В данном случае статистика по заражению следующая:
- 41 вставка бэкдора
- 5 WSO веб-шеллов
- 4 скрипта, внедряющих вредоносный код в .php файлы
- 7 mail() спам-рассыльщиков
- 2 спам-рассыльщика, работающих через SMTP
- 1 бэкдор
- 1 скрипт, внедряющий вредоносный код в wordpress/joomla скрипты
Среди “вредоносов” есть всякие интересные, усердно-обфусцированные экземпляры:
Но речь сегодня пойдет не о них. Интереснее анализировать не столько статический вредоносный код в файлах, сколько процесс работы с «вредоносами» в динамике: какие запросы и в каком формате шлют командные центры внедренным бэкдорам, с какой интенсивностью, с какими параметрами и т.п. Кроме того, статический анализ для современных зловредов работает плохо, потому что некоторые скрипты не содержат payload’ов.
Возьмем популярный бэкдор:
Он состоит из одной-двух строк и служит для приема и исполнения PHP-кода. Payload «прилетает» в параметрах POST запроса и исполняется в тот же момент. Естественно, код payload’а нигде не сохраняется, поэтому процесс динамического анализа обычно упирается в отсутствие данных: нет логов с телом запросов, которые содержали бы исследуемый код.
Чтобы проанализировать общение командного центра со своими «агентами», нужно логгировать HTTP запросы к вредоносным скрипта, а для этого нужно своевременно настроить протоколирование тела POST запроса в файл, что никогда не делается на shared-хостингах. На выделенных серверах, врочем, POST запросы с данными тоже не логгируются. Связано это с экономией ресурсов сервера и, в общем случае, отсутствием необходимости. Но это еще не все. Вторая проблема, связанная с анализом взлома и заражения сайта — это позднее обращение владельца зараженного сайта к специалистам.
Почти всегда «пациенты» обращаются спустя 2-3 недели после появления первого вредоносного скрипта. То есть когда загруженный код уже внедрен, “отлежался” и начинает активно эксплуатируется злоумышленниками, а сайт блокируется хостингом по причине спам-рассылки, фишинговых страниц или атак на сторонние ресурс. Кстати, “отлеживается” код для того, чтобы замести следы взлома и сразу не вызвать подозрений у владельца сайта. Недели через две ротация логов делает свое «грязное» дело, стирая информацию о том, каким образом вредоносный код был загружен на сайт, и внедренные зловреды начинают создавать вредную «полезную» нагрузку: атаковать другие ресурсы, загружать на сайт дорвей-страницы, спам-рассыльщики, внедрять код редиректов на связки сплойтов, рассылать тонны спам писем с фишинговым контентом и пр.
Но время от времени все-таки удается настроить логгирование на зараженном сайте и собрать внутренности запросов к вредоносным скриптам. Итак, что же скрыто от чужих глаз?
Достаточно типично для такого заражения – это внедрение в корневой .htaccess редиректа на pharm-партнерку (продажа “виагры”, и т.п), wap-click партнерку (подписка на медиа-контент за SMS) или вредоносный ресурс (для проведения drive-by атак или загрузки трояна под видом обновления flash-плейера или антивируса).
Редирект в данном случае внедряется следующим образом: в POST запросе передается php-код, который обернут в base64. Код исполняется с помощью бэкдора на взломанном сайте и добавляет свой обработчик 404 ошибки, при которой перебрасывает посетителей на сайт злоумышленника. Причем, достаточно иметь на какой-нибудь странице сайта отсутствующую картинку, скрипт или .css файл, чтобы у посетителя сработал редирект. Домены, на которые перенаправляются посетители, периодически меняются.
Еще один пример лога запросов к внедренным бэкдорам и загруженным скриптам для спам-рассылки:
Здесь также все данные передаются в base64 кодировке через POST- и COOKIE-переменные. Причем, исполняемые фрагменты дважды обернуты в base64 кодировку, дабы обойти WAFы и веб-сканнеры, которые в курсе про base64 и умеют ее декодировать. В раскодированном варианте запрос к бэкдору выглядит так:
В payload’е выполняется обход каталогов и инжектирование кода, который будет искать wordpress файлы в доступных каталогах и делать одну из двух вещей: или внедрять в них вредоносный контент, или восстанавливать оригинальный контент файлов (так командный центр внедряет вредоносы на время или по-расписанию). Чтобы было сложнее найти измененные скрипты, дата модификации (mtime) у файлов выставляется по дате изменения одного из wordpress скриптов. В дополнение, выставляются атрибуты “только для чтения”, чтобы неопытные веб-мастера не смогли их отредактировать (многих это действительно озадачивает).
Что касается другой «полезной» нагрузки — рассылки спама — контент дважды заворачивается в base64 и передается в параметрах POST запроса к спам-рассыльщику. А время от времени могут отсылать какие-то проверочные письма со служебной информацией:
Интересное наблюдение: если с сайта удалить все вредоносные скрипты, то через несколько неудачных запросов процесс общения с «агентами» останавливается. То есть командный центр не пытается сразу же повторно взломать сайт и загрузить на него бэкдоры, видимо по той же самой причине – скрыть процесс первичной загрузки бэкдоров. Но если оставить при лечении хотя бы один бэкдор, то через него снова загрузят целую “вязанку” хакерских шеллов, бэкдоров и спам-рассыльщиков.
Поэтому лечить сайт всегда нужно очень аккуратно.
ссылка на оригинал статьи https://habrahabr.ru/post/280516/
Добавить комментарий