Злоумышленники постоянно совершенствуют методы внедрения вредоносного кода на веб-страницы зараженных сайтов. Если раньше это бывала модификация статического контента или php-скриптов CMS, то сейчас прибегают к использованию более сложных техник.
В наши дни чаще всего заражению подвергается веб-сервер: устанавливаются вредоносные модули, внедряются вредоносные shared objects, либо же исполняемый файл перекомпилируется с вредоносной функциональностью. Для внедрения вредоносного JavaScript активно используется, например, Flash.
В конце 2013 года наш робот начал детектировать большое количество вредоносных сайтов, на страницы которых был внедрен вредоносный Flash-объект. На странице размещался вот такой код.
Этот flash-ролик загружался в браузер посетителя сайта и выполнял ActionScript, отправлявшийзапрос на адреса вида:
hxxp://rdomn1394028305.hopto.me/gray-bg.png?img=<random_number>,
например:
hxxp://rdomn1394089507.hopto.me/gray-bg.png?img=0.28730966709554195
В ответе на данный запрос передавались данные:
Они представляли собой зашифрованный JavaScript-код, который расшифровывается и выполняется оператором eval. В итоге flash-ролик формировал iframe c URL’ом вида zzbdbqs.podzone.net/ytydhdy9.html.
В iframe загружался frameset, подгружающий в браузер пользователя landing page от Neutrino Exploit Kit:
Далее landing page работала следующим образом. Скрипт fshciym.js — это фреймворк jQuery версии 1.9.1. Он активно участвовал в процессе деобфускации, которая выполнялась в компактном теле главной подпрограммы скрипта:
Функция wdb() возвращала разные js-операторы в зависимости от поданых на вход параметров. Таким образом, главная подпрограмма преобразовалась в код:
Этот код подгружал с хостинга эксплойт-папка документ amnjzvktkqdbj и передавал его на вход функции ijvb, которая выполняла decodeURIComponent и последующее расшифрование документа. В итоге формировался комплексный скрипт из PluginDetect и кода:
Этот код определял, какие программы установлены у пользователя (MS Office, VLC Player, Java, Flash), и в зависимости от результатов подгружал страницу с подходящими эксплойтами. Помимо интересной структуры вредоносного кода, выполняющегося в браузере пользователя, этот случай интересен способом заражения сервера.
Несколько вебмастеров, обратившихся в нашу техподдержку, согласились дать нам root-доступ к тем своим серверам, которые были заражены. Мы выяснили, что для этого был использован вредоносный модуль для Apache. Он представляет собой отдельный .so (как правило, с именем mod_status.so), который прописывается в конфигурацию веб-сервера Apache. Для того чтобы его было сложнее обнаружить и удалить злоумышленники прописали загрузку модуля в конфигурационные скрипты других модулей (например, perl.conf). Измененным файлам конфигурации при помощи утилиты chattr устанавливались атрибуты, запрещающие изменение этих файлов. Саму же утилиту chattr после использования удаляли. Вместо нее записывался пустой файл с таким же названием и атрибутами, которые запрещают его удалять.
В ходе инициализации модуль устанавливал несколько хуков, путем вызова функций:
ap_hook_log_transaction,
ap_hook_post_config,
ap_hook_insert_filter,
ap_register_output_filter
При вызове процедуры post_config_hook (устанавливается вызовом ap_hook_post_config) происходила расшифровка и загрузка конфигурации модуля. Также создавался file mapping, который в дальнейшем использовался для межпроцессного взаимодействия. После этого этапа проверялись привилегии процесса и, если он имел права root, то происходил его fork и запускался бесконечный цикл. В нём модуль проверял наличие в системе сессии пользователя с правами root и запрещенных процессов, а при необходимости производил backconnect к удаленному серверу, давая злоумышленникам возможность удаленного управления.
Внедрение вредоносного кода в HTTP-ответы сервера происходило в функции, которая устанавливается в качестве output filter веб-сервера Apache. Непосредственно перед внедрением вредоносный модуль проверял является ли HTTP-запрос управляющим, разрешено ли удаленное управление модулем вообще и нужно ли обновить его конфигурацию. Затем происходила серия проверок: не истекло ли время внедрения вредоносного кода и содержится ли он в конфигурации.
Если результаты были положительными, следом проверялись флаги, сигнализирующие об активной сессии пользователя с правами root или о запрещенном процессе в системе. После проверялись параметры запроса и ответа – User-Agent, Content-Type, Referer, наличие подстрок, до или после которых происходит внедрение вредоносного кода. Если все эти проверки проходили успешно, то вредоносный код внедрялся в HTTP-ответ.
Вредоносный модуль также позволял злоумышленникам осуществлять удаленное управление сервером. Для этого необходимо было послать HTTP запрос, который содержит заголовок “Pragma” со специальным значением. В ходе обработки такого запроса это значение декодировалось при помощи алгоритма Base64, расшифровывались первые 8 байт значения и первые 4 байта проверялись на равенство константе 0xDEADBEEF. Вторые 4 байта этого 8ми байтового блока представляли собой команду. Типы команд и их описание в таблице:
| Значение команды | Описание |
|---|---|
| 10001h | Получить статус |
| 10002h | Обновить конфигурацию |
| 10003h | Возобновить внедрение кода в HTTP ответы |
| 10004h | Приостановить внедрение кода в HTTP ответы |
| 10005h | Сделать бэкконнект к удаленному серверу |
Остальная часть значения Pragma — это полезная нагрузка для команды. Данные передавались в открытом виде за исключением пакета с обновлением конфигурации, который зашифрован при помощи алгоритма XTEA (11 раундов) в режиме ECB.
Помимо этого, вредоносный модуль содержал функции для мониторинга выполняющихся в системе процессов и наличия сессии пользователя с правами root.
В процессе мониторинга нежелательных процессов модуль читалсодержимое директории /proc/ и получал командную строку запущенных процессов путем чтения /proc/%d/cmdline. Полученные значения командных строк проверялись на наличие названий запрещенных процессов, которые перечислены в конфигурации вредоносного модуля. В случае обнаружения нежелательного процесса внедрение вредоносного кода в HTTP-ответы сервера временно прекращалось.
Похожим образом происходила проверка сессии пользователя с правами root. Вредоносный модуль получал ID запущенных процессов, а для каждого процесса — его статус путем чтения /proc/%d/status. Далее из полученных данных модуль получал UID-ы и сравнивал их с 0. В случае, если процесс удовлетворял этому условию, то модуль смотрел его /proc/%d/fd и искал подстроку pts. Для тех файловых дескрипторов, для которых эта подстрока была найдена, получалось время последней модификации,.Если разница текущего времени и полученного меньше значения, определенного в конфигурации, модуль считал, что в системе есть сессия пользователя root и также временно прекращала внедрение вредоносного кода.
Начальная конфигурация вредоносного модуля
Обновленная конфигурация вредоносного модуля (внутри виден вредоносный код для внедрения в HTTP-ответы)
Для внедрения вредоносного кода злоумышленники придумывают все новые и новые методы и переходят от инициирования отдельных страниц и скриптов к использованию исполняемых файлов веб-сервера, что затрудняет детект вредоносного кода традиционными методами. Если ваш сервер подвергся подобному заражению, то выявить вредоносный модуль поможет проверка всех модулей Apache при помощи сервиса VirusTotal.
Следите за своими веб-серверами и сайтами на них, чтобы избежать заражения, потери посещаемости, а в случае хостинга – массового оттока клиентов. Наблюдайте за разметкой сайтов на выдаче – для этого можно зарегистрировать сайты в Яндекс.Вебмастере, а также читать письма о заражении, которые мы присылаем на стандартные email-адреса. В случае, если ваша компания является хостингом или разрабатывает соответствующее ПО, возможно, вам будет удобнее пользоваться Safe Browsing API, для которого мы недавно выпустили новый PHP SDK, или параметром «virused» в API Вебмастера.
Берегите своих пользователей, сайты и серверы!
ссылка на оригинал статьи http://habrahabr.ru/company/yandex/blog/218143/
Добавить комментарий