Книга: Pro Вирусы

Глава 6. Технологии заражения

Глава 6. Технологии заражения

Дроппер

Несмотря на довольно скромные размеры (средний размер вредоносной программы составляет 60–100 килобайт) ряд современных вредоносных приложений, как правило, включает в себя несколько модулей, реализующих различные функции. Один из таких модулей принято называть дроппером, он может быть реализован как в виде отдельного файла, так и в качестве составного компонента сложной угрозы.

Например, широко распространенные троянцы семейства MulDrop представляют собой троянцев-дропперов: основное (и единственное) назначение этих вредоносных программ — установка на атакуемый компьютер другого троянца, который хранится внутри контейнера Trojan.MulDrop, как одна матрешка в другой (как правило — в упакованном и зашифрованном виде). В отличие от троянцев-загрузчиков (Trojan.Download), Trojan.MulDrop не скачивает «полезную нагрузку» из Интернета, а извлекает ее «из себя».

Иными словами, дроппер — это объект, осуществляющий извлечение содержащихся в нем основных модулей вируса или троянца, их распаковку и установку в операционной системе. Основные компоненты вредоносной программы при этом могут помещаться дроппером, например, в одну из папок на диске или загружаться непосредственно в оперативную память. Основная функция дроппера — сохранить в атакуемой системе все компоненты вредоносного приложения, при необходимости зарегистрировать их в автозагрузке и передать им управление.

Инфектор

Еще один компонент вредоносных приложений называют инфектором. Инфектор — это модуль, осуществляющий заражение файловых объектов (например исполняемых файлов или динамических библиотек) либо загрузочной записи компьютера путем изменения их внутренней структуры.

Инжектор

Инжектором принято называть функциональный модуль вредоносной программы, реализующий встраивание вредоносных компонент в запущенный процесс другого приложения (инжект). После успешного осуществления инжекта вредоносный компонент вируса или троянца выполняется в контексте инфицированного процесса.

Объект для инжекта во многом определяется целью злоумышленников и функциональным назначением самой вредоносной программы. Наиболее распространенным объектом для инжектов в Windows являются запущенные в системе процессы браузеров или различные системные процессы, такие как svchost.exe или explorer.exe (проводник).

Лоадер

Лоадером называют компонент вредоносной программы, осуществляющий загрузку других модулей (например, динамических библиотек) в оперативную память компьютера и (в ряде случаев) настройку этих компонентов в памяти. Для загрузки компонент лоадер может использовать как функции API, так и различные собственные механизмы.

Процесс заражения

Соответственно, различные компоненты вредоносной программы в целях инфицирования операционной системы могут действовать совместно. В качестве примера такой функциональной интеграции можно рассмотреть механизм заражения Microsoft Windows одной из ранних версий вредоносной программы, принадлежащей к семейству Ramnit (Rmnet).

Первым на атакуемом компьютере запускается дроппер, который извлекает из своего тела, расшифровывает, а потом помещает во временную папку инфектор загрузочной записи и несколько модулей, реализованных в виде динамических библиотек. Затем дроппер запускает инфектор с помощью одной из системных функций, после чего файл инфектора удаляется.

После успешного запуска инфектор модифицирует основную загрузочную запись компьютера (MBR, Master Boot Record) с целью обеспечения запуска модулей Rmnet до старта средств антивирусной защиты, если таковые установлены на инфицированной машине. Оригинальная MBR вместе с частью вирусной загрузочной записи перемещается в конец диска.

При запуске операционной системы вредоносная программа получает управление, имеющийся в ее архитектуре инжектор встраивает модули Rmnet в один из запущенных процессов, в контексте которого они начинают выполняться. Один из модулей предназначен для саморепликации вредоносной программы, второй выполняет функции бэкдора, третий осуществляет мониторинг сетевого трафика, и, наконец, последний реализует функцию кражи паролей от различных приложений, в частности FTP-клиентов. Описанная здесь схема заражения представлена на рис. 11.

Рис. 11. Одна из реализаций схемы заражения ОС Windows

В зависимости от модификации и типа вредоносного приложения механизм заражения может значительно меняться: представленный выше весьма упрощенный алгоритм является лишь одним из множества возможных вариантов и достаточно схематичен. Современные вредоносные приложения могут использовать различные руткит-технологии, позволяющим им эффективно скрывать свое присутствие в операционной системе, а также применять всевозможные методы антиотладки.

Инфицирование файловых объектов

Современные файловые вирусы реализуют различные методы заражения файлов, иногда достаточно изощренные. В общем случае механизм заражения файловых объектов можно упрощенно представить следующим образом. Определив по тем или иным заданным вирусописателем критериям подходящий для заражения файл, вирус модифицирует его, дописывая в его структуру собственное тело (иногда — в зашифрованном виде, в этом случае при выполнении вредоносного кода задействуется специальный механизм его расшифровки). В частности, вирус может поместить свою копию в начало файла, а оригинальное содержимое перенести в его конец. Затем вирус изменяет код приложения таким образом, чтобы при его запуске первым управление получил встроенный в него вредоносный компонент (например, размещая в соответствующей секции файла команду перехода на начало вируса). После выполнения основного тела вируса управление передается обратно инфицированному приложению, и оно выполняет свои функции так, как и было изначально задумано его разработчиками. Пользователь в большинстве случаев не замечает того, что в момент старта программы произошло что-то необычное. Такой метод заражения можно условно представить в виде схемы (рис. 12).

Рис. 12. Один из возможных алгоритмов заражения файловых объектов вирусом

Существует вариант заражения, при котором оригинальный файл, наоборот, в том или ином виде сохраняется внутри вредоносной программы и в момент запуска вируса отображается в память компьютера или сохраняется в какой-либо папке на диске и запускается оттуда. Схожий алгоритм использовали, например, вирусы семейства Neshta. В процессе заражения машины вирус сохранял свою копию в папке установки Windows под именем svchost.com, а затем изменял параметр ключа системного реестра [HKCRexefileshellopencommand], записывая в него значение “(default)” = “%WinDir%svchost.com “%1” %*”. В результате при попытке запуска пользователем любой программы на инфицированном компьютере в первую очередь запускалось тело вируса из файла svchost.com, которому передавалось имя нужного пользователю приложения в виде параметра. Если этот исполняемый файл еще не был инфицирован ранее, Neshta сохранял его имя в специальном журнале для последующего заражения и запускал оригинальную программу. Если же пользователь пытался запустить ранее зараженный файл, вирус, получив управление, распаковывал оригинальный исполняемый файл нужной пользователю программы, помещал его во временную папку текущего пользователя Windows и запускал оттуда.

С целью избежания повторного заражения вирусы, как правило, используют специальные уникальные идентификаторы — в процессе заражения файла инфектор проверяет наличие в структурах файла соответствующей строки, и в случае ее обнаружения заражения не происходит. Описанная выше схема представлена на рис. 13.

Рис. 13. Альтернативный алгоритм заражения файловых объектов вирусом

Существуют и альтернативные методы заражения, используемые злоумышленниками значительно реже. Например, известно семейство вредоносных программ (иногда их называют общим термином «вирус-компаньон»), действовавших достаточно просто: они сохраняли свою копию в той же папке, где расположен исходный файл приложения, причем с тем же самым именем, а оригинальный исполняемый файл переименовывали. При запуске такой программы пользователем сначала запускался вирус, а после того, как он отрабатывал, управление передавалось оригинальному приложению.

Методы обеспечения автоматического запуска

Собственно, способов, позволяющих вредоносной программе автоматически запуститься на инфицированном компьютере, не так уж и много, и все они зависят в первую очередь от типа операционной системы, в которой действует вредоносная программа, а также от ее типа. Например, троянцы в Mac OS X обеспечивают собственную автозагрузку с использованием файлов PLIST (Property List). Буткиты, о которых мы уже беседовали ранее, модифицируют для этих целей загрузочную запись, получая, таким образом, возможность запуститься одновременно с операционной системой (либо даже до завершения процесса ее загрузки), однако в любом случае — до момента старта действующих на компьютере антивирусных средств защиты.

На ранних этапах эволюции антивирусных программ для ОС Windows троянцы зачастую просто создавали скрытый ярлык, указывающий на исполняемый файл вредоносной программы, в системной папке автозагрузки Windows. Большинство современных угроз для этой цели модифицируют отвечающую за автозапуск приложений ветвь системного реестра, как правило, выбирая в этом качестве ветвь [HKLM или HKCU SoftwareMicrosoftWindowsCurrentVersionRun]. Однако до сих пор существуют троянцы, действующие по старинке: определив место расположения папки автозагрузки для текущего пользователя Windows (для этого троянец получает значение ключа реестра [HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell FoldersStartup]), вредоносная программа просто сохраняет в этой директории собственный исполняемый файл, устанавливая для него атрибуты «системный» и «скрытый».

Вредоносные программы для ОС Linux используют другие методы автозапуска, обусловленные особенностями архитектуры этой операционной системы. Так, некоторые Linux-троянцы задействуют для данных целей службу выполнения приложений по расписанию (планировщика задач) cron, создавая соответствующие записи в конфигурационном файле crontab. Другие изменяют содержимое служебной директории «~/.config/autostart/». Один из троянцев, принадлежащих к семейству Linux.BackDoor.Fysbis, добавлял во все найденные в директории /etc/ файлы rc.local строку со ссылкой на инфицированный файловый объект либо (если изменить содержимое файлов не получилось) пытался создать файл службы в папке /usr/lib/systemd/system/ и установить ее в системе, выполнив соответствующую последовательность команд.

Инжекты

Инжект (не следует путать с веб-инжектом) — это механизм, позволяющий вирусу или троянцу встраивать вредоносный объект в запущенный и уже работающий в операционной системе процесс другого приложения, после чего внедренный объект начинает выполняться в контексте данного процесса. Инжекты осуществляются вредоносными программами с несколькими возможными целями. Во-первых, внедрение в процесс приложения позволяет получить доступ к различным ресурсам, используемым данным приложением. Например, инжект в процесс браузера открывает перед злоумышленником возможность обходить установленные в брандмауэре ограничения или перехватывать вызовы соответствующих функций API. Во-вторых, внедренный в работающую программу вредоносный объект не будет демонстрироваться в Диспетчере задач Windows в виде отдельного процесса и потому станет как бы невидимым для пользователя. Есть и еще один заметный «плюс» инжекта с точки зрения злоумышленника: вредоносный код выполняется в операционной системе с привилегиями программы-«носителя», то есть основного процесса приложения, в которое инжектирован вредоносный объект. Иными словами, если программа, например, запущена от имени Администратора, вирусный код также получит аналогичные права на зараженной машине и сможет выполнять действия, недоступные для ограниченной учетной записи простого пользователя.

В настоящее время известно порядка 20 различных практических методов выполнения инжектов в процессы, запущенные в ОС семейства Microsoft Windows. Я не буду описывать их подробно, поскольку соответствующую техническую информацию можно без труда отыскать в популярных учебниках по программированию. В общем случае (самый распространенный метод) последовательность действий вредоносной программы такова:

• выбор приложения, в которое будет осуществляться инжект;

• поиск и получение соответствующего дескриптора процесса;

• выделение в адресном пространстве процесса памяти для внедрения вредоносного объекта по соответствующему адресу;

• копирование вредоносного компонента в выделенную область памяти;

• создание нового потока в виртуальном адресном пространстве процесса, в который внедрен вредоносный код.

Многие разработчики инжектов используют для реализации данного механизма стандартные функции API, например, WriteProcessMemory для копирования кода в память процесса и CreateRemoteThread для запуска удаленного потока. Другие поступают иначе. Так, создатели некоторых образцов троянцев семейства Trojan.Inject использовали альтернативную методологию: инжектор вредоносной программы создавал «замороженный» экземпляр процесса svchost.exe (хост-процесс для загружаемых из динамических библиотек служб), подготавливал адреса всех необходимых для работы встраиваемого кода функций API, затем выделял требуемое адресное пространство памяти и полностью копировал троянца в процесс, после чего «размораживал» его.

В некоторых, довольно редких, случаях инжекты выполняются с использованием различных уязвимостей или недокументированных возможностей тех или иных компонентов операционной системы. Так, сразу несколько троянских программ использовали в свое время уязвимость в компоненте explorer.exe, вернее, в его подсистеме GUI (графического интерфейса пользователя). Однако подобные случаи на практике все же встречаются нечасто.

Перехват вызовов функций

Для реализации различных практических задач многие вредоносные программы обладают механизмом перехвата вызовов API-функций в процессах других приложений. Иногда эту технологию называют «хуками».

Кратко процедуру «хукинга» можно описать следующим образом. Очень многие приложения, выполняющиеся в среде Microsoft Windows (если не сказать «почти все»), используют для своей работы так называемые динамические подключаемые библиотеки (Dynamic Link Library), физически представленные в виде файлов с расширением .dll. Динамические библиотеки в свою очередь содержат определенный набор используемых приложениями функций. Сделано это, чтобы «разгрузить» само приложение, избавить его от «лишнего» кода. Например, разные программы могут многократно использовать одну и ту же функцию. Вместо того чтобы размещать ее код в самом приложении, разработчики позволяют этой программе обращаться к соответствующей динамической библиотеке и вызывать нужную ей функцию оттуда. При этом подразумевается, что одной стандартной библиотекой может пользоваться сразу несколько разных программ.

Когда программа запускается на выполнение, ОС Windows создает для нее отдельный процесс, выделяя для приложения определенный объем памяти. В начале каждого исполняемого файла перечислены имена динамических библиотек, которые использует это приложение: система осуществляет их поиск (в папке, где установлена сама программа, или в системных директориях Windows), аллоцирует (выделяет) память в процессе работающего приложения и загружает туда эти библиотеки. Когда программа вызывает какую-либо функцию, нужную ей для работы в данной момент времени, она автоматически определяет, в какой библиотеке и по какому адресу хранится данная функция, после чего строит специальную таблицу зависимости вида «имя функции — имя библиотеки — адрес функции внутри библиотеки» (она называется таблицей импорта функций), отыскивает нужный адрес в памяти процесса и передает на него управление (рис. 14).

Рис. 14. Стандартный механизм работы приложения и перехват вызовов функций с передачей управления на вредоносный объект Собственно, задача «хукинга» заключается в том, чтобы «убедить» программу, будто нужная ей функция хранится не по этому адресу, а расположена в другом месте, например, в совершенно иной динамической библиотеке, которая была предварительно встроена в процесс методом инжекта.

Практически перехват вызовов функций осуществляется обычно перестановкой указателя, то есть, изменением содержимого этой самой «таблицы зависимостей» таким образом, чтобы имя вызываемой функции ссылалось в конечном итоге на нужный злоумышленнику адрес функции в памяти процесса.

Второй метод носит наименование code injection и заключается в том, что злоумышленник непосредственно в памяти процесса заменяет первые байты кода самой функции, вставляя туда инструкцию безусловного перехода на собственную, вредоносную функцию, после выполнения которой управление (в случае необходимости) возвращается обратно оригинальной функции. Этот метод чуть более сложен в реализации и потому встречается на практике реже.

Так, некоторые банковские троянцы при запуске снимают хуки с ряда функций системных библиотек с целью обхода различных инструментальных средств, позволяющих исследовать вредоносную программу — таким образом реализуется механизм антиотладки. Установка перехватов вызовов функций широко используется и в целях непосредственного выполнения приложением деструктивных действий.

Например, встроившись в процесс Проводника, некоторые троянцы могут перехватывать вызов функции ZwQueryDirectoryFile с целью сокрытия собственных файлов на диске инфицированного компьютера ­— при обращении к такому файлу будет автоматически установлен код ошибки STATUS_NO_SUCH_FILE. Нередко установка хуков на определенные функции применяется троянцами-шпионами для «просеивания» сетевого трафика (сниффинга) в поисках логинов и паролей.

Существует огромное количество практических задач, которые могут быть реализованы с использованием установки тех или иных хуков. Фактически перехват вызовов функций открывает перед злоумышленниками почти полный контроль над приложением. С помощью хуков, например, можно отслеживать действия пользователя (движения курсора и нажатия кнопок мыши), предотвращать создание или закрытие окон, выгрузку компонентов приложения, перехватывать сообщения от других процессов, контролировать работу приложения с файловыми объектами и т. д.

Например, если злоумышленник хочет, чтобы другая программа не завершила используемый им инфицированный процесс, он может установить хуки на функции открытия и завершения процессов (OpenProcess, TerminateProcess), и в момент вызова этих функций другими процессами осуществлять проверку, не пытаются ли они завершить процесс его вредоносного приложения.

С этой точки зрения горизонты применения технологии перехвата вызовов функций ограничены, по большому счету, только набором самих функций, естественными рамками архитектуры операционной системы и фантазией злоумышленника.

Оглавление книги