Валентин Холмогоров - Pro Вирусы
Методы обеспечения автоматического запуска
Собственно, способов, позволяющих вредоносной программе автоматически запуститься на инфицированном компьютере, не так уж и много, и все они зависят в первую очередь от типа операционной системы, в которой действует вредоносная программа, а также от ее типа. Например, троянцы в 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 и заключается в том, что злоумышленник непосредственно в памяти процесса заменяет первые байты кода самой функции, вставляя туда инструкцию безусловного перехода на собственную, вредоносную функцию, после выполнения которой управление (в случае необходимости) возвращается обратно оригинальной функции. Этот метод чуть более сложен в реализации и потому встречается на практике реже.
