4 октября мы выступили с докладом «Embedding malware on websites using executable webserver files» на конференции VirusBulletin 2013. В этом докладе мы рассказали о:
- истории эволюции вредоносного кода на веб-сайтах для drive-by download атак;
- новых методах распространения вредоносного кода;
- подходах к детектированию.
Краткая история эволюции вредоносного кода на веб-сайтах для Drive-by download атак.
Одним из первых способов распространения вредоносного кода было изменение статического содержимого веб-страниц. Атакующие просто добавляли на страницу вредоносные скрипты и iframe.
Но спустя некоторое время такие модификации стали быстро обнаруживаться антивирусными программами по сигнатурам. Для того чтобы затруднить сигнатурный анализ, злоумышленники стали использовать различные методы обфускации кода на JavaScript. В ответ на это антивирусные вендоры начали внедрять в свои продукты эмуляторы JavaScript, что увеличило точность детектирования подобного вредоносного кода.
Следующим этапом эволюции Drive-by download атак стала модификация исходных текстов различных CMS и их шаблонов. Вредоносный код стал проверять различные параметры HTTP-запросов и на основании результатов проверки решать, внедрять вредоносный код на страницу или нет.
Современные методы распространения вредоносного кода
В процессе исследования мы выявили следующие три современных способа распространения вредоносного кода:
- модификация исходного кода веб-сервера;
- модификация HTTP-ответа;
- установка дополнительных модулей веб-сервера.
Модификация исходного кода веб-сервера
В первом квартале 2012 года мы стали детектировать большое количество вредоносных редиректов на ресурсы в доменной зоне org.in. Конечной целью перенаправления была landing page неизвестного ранее exploit kit. [http://safesearch.ya.ru/replies.xml?item_no=449].
Через некоторое время подобные редиректы стали осуществляться с одного из серверов крупного украинского хостера. Мы выяснили, что злоумышленники добавили вредоносную функциональность в исходные тексты веб-сервера nginx и заменили исполняемый файл веб-сервера на зараженный [http://safesearch.ya.ru/replies.xml?item_no=665].
В дальнейшем выяснилось, что аналогичные модификации существуют также для других популярных веб-серверов, например, Apache и lighttpd.
Модификация HTTP-ответа
В конце 2012 года был обнаружен новый руткит для Linux, который представлял собой загружаемый модуль ядра. Этот руткит перехватывает вызовы некоторых системных функций, анализирует исходящий трафик и внедряет вредоносный код непосредственно в HTTP-ответы.
Установка дополнительных модулей веб-сервера
Злоумышленники устанавливают дополнительные модули веб-сервера, чтобы изменять данные, передающиеся от сервера к браузеру пользователя. Общая схема этого процесса представлена на схеме:
Для своих целей атакующие используют две разновидности модулей для веб-сервера Apache:
- популярные бесплатные модули, которые настраиваются атакующими на внедрение вредоносного кода;
- специально разработанные модули, которые продаются на черном рынке.
Ниже представлена вредоносная конфигурация для mod_substitute и результаты ее работы.
Из специально разработанных модулей самыми популярными сейчас являются Trololo_mod и Darkleech, они продаются на различных хакерских форумах. Мы проанализировали около 90 образцов вредоносного модуля Darkleech и собрали статистику по адресам серверов управления.
По нашим данным, наиболее крупный командный сервер управлял приблизительно 38 тыс. зараженных серверов.
Методы детектирования вредоносного кода
Для того чтобы обнаружить заражение сервера, можно применить несколько общеизвестных методов.
- Проверить файлы и конфигурацию при помощи антивирусного ПО. Однако данный метод не очень эффективен, так как большинство новых образцов серверного вредоносного ПО, к сожалению, не детектируется обычными антивирусами.
- Использовать anti-rootkit программы. Этот способ тоже работает не всегда, потому что не все вредоносные программы содержат функциональность руткитов.
- Применять различные системы контроля версий и целостности файлов. Но стоит помнить, что атакующий может изменить конфигурационные файлы веб-сервера, перезапустить веб-сервер с вредоносной конфигурацией, а затем вернуть конфигурационные файлы в прежнее состояние. После этого конфигурационные файлы на диске будут иметь такие же контрольные суммы, как раньше, и не будут содержать вредоносных настроек, однако веб-сервер до следующего перезапуска будет использовать вредоносную конфигурацию и распространять вредоносный код.
Обнаружить вредоносный код на веб-сервере может быть легче, если перед этим найти результаты его работы в HTTP-ответах, которые веб-сервер выдаёт браузерам пользователей.
Яндекс разработал систему, которая может детектировать вредоносный код по HTTP-ответам сервера. Подробнее о ней написано здесь. Вы также можете использовать наш Safe Browsing API, чтобы проверять, заражен веб-сервер или нет. Дополнительную информацию о заражении и способах его устранения можно получить с помощью сервиса Яндекс.Вебмастер и Яндекс.Помощь.
Как не допустить заражения исполняемых файлов веб-сервера
- Используйте дистрибутивы серверного ПО из первоисточников (сайтов разработчиков), по возможности собирайте его из оригинального исходного кода самостоятельно.
- Вовремя обновляйте ваш веб-сервер, чтобы в установленном на нём ПО было как можно меньше известных уязвимостей.
- Закрывайте неиспользуемые порты, отключайте ненужные сервисы.
- Используйте сложные логины и пароли.
- Следите за рабочими компьютерами, которые используются для работы с веб-сервером, не допускайте их заражения.
Мы хотим поблагодарить за сотрудничество вебмастеров и системных администраторов, которые присылали нам образцы серверного вредоносного кода, что позволило нам провести это исследование и поделиться результатами.
Если у вас есть любой подозрительный код, конфигурационные файлы, логи атак на ваш веб-сервер, присылайте их для анализа по адресу virus-samples@yandex-team.ru.