Записки исследователя компьютерных вирусов
Шрифт:
Рис. 2.1. Типовая схема заражения исполняемого файла путем его поглощения
Рис. 2.2. Пример файла, поглощенного вирусом UNIX.a.out. Крохотный, всего в 300 байт, размер кодовой секции указывает на высокую вероятность заражения
Получив управление, вирус извлекает из своего тела содержимое оригинального файла, записывает его во временный файл, присваивает ему атрибут исполняемого и запускает «излеченный» файл на выполнение, а после завершения удаляет вновь. Поскольку подобные манипуляции редко остаются незамеченными, некоторые вирусы отваживаются на «ручную» загрузку жертвы с диска. Впрочем, корректный загрузчик elf-файла написать ой как нелегко и еще сложнее
Характерной чертой подобных вирусов является крошечный сегмент кода, за которым следует огромный сегмент данных (оверлей), представляющий собой самостоятельный исполняемый файл. Попробуйте контекстным поиском найти eli/coff/a.out-заголовок – в зараженном файле их будет два! Только не пытайтесь дизассемблировать оверлей/сегмент данных, – осмысленного кода все равно не получится, так как, во-первых, для этого требуется знать точное расположение точки входа, а во-вторых, расположить хвост дизассемблируемого файла по его «законным» адресам. К тому же оригинальное содержимое файла может быть умышленно зашифровано вирусом, и тогда дизассемблер вернет бессодержательный мусор, в котором будет непросто разобраться. Впрочем, это не сильно затрудняет анализ. Код вируса навряд ли будет очень большим, и на восстановление алгоритма шифрования (если тот действительно имеет место) не уйдет много времени.
Хуже, если вирус переносит часть оригинального файла в сегмент данных, а часть – в сегмент кода. Такой файл выглядит как обыкновенная программа за тем единственным исключением, что большая часть кодового сегмента представляет собой «мертвый код», никогда не получающий управления. Сегмент данных на первый взгляд выглядит как будто бы нормально, однако при внимательном рассмотрении обнаруживается, что все перекрестные ссылки (например, ссылки на текстовые строки) смещены относительно их «родных» адресов. Как нетрудно догадаться – величина смещения и представляет собой длину вируса.
Дизассемблирование выявляет характерные для вирусов этого типа функции execи fork, использующиеся для запуска «вылеченного» файла, функцию chmod – для присвоения файлу атрибута исполняемого и т. д.
Заражение посредством расширения последней секции файла
Простейший способ неразрушающего заражения файла состоит в расширении последней секции/сегмента жертвы и дозаписи своего тела в ее конец (рис. 2.3, 2.4).
Рис. 2.3. Типовая схема заражения исполняемого файла путем расширения его последней секции
Рис. 2.4. Внешний вид файла, зараженного вирусом PolyEngine.Linux.LIME.poly; вирус внедряет свое тело в конец секции данных и устанавливает на него точку входа. Наличие исполняемого кода в секции данных делает присутствие вируса чрезвычайно заметным
Далее по тексту просто «секции», хотя применительно к ELF-файлам это будет несколько некорректно, так как системный загрузчик исполняемых ELF-фай-лов работает исключительно с сегментами, а секции игнорирует.
Строго говоря, это утверждение не совсем верно. Последней секцией файла, как правило, является секция. bss, предназначенная для хранения неинициа —
лизированных данных. Внедряться сюда можно, но бессмысленно, поскольку загрузчик не настолько глуп, чтобы тратить драгоценное процессорное время на загрузку неинициализированных данных с медленного диска. Правильнее было бы сказать «последней значимой секции», но давайте не будем придираться, это ведь не научная статья, верно?
Перед секций. bss обычно располагается секция. data, содержащая инициализированные данные. Вот она-то и становится основным объектом вирусной атаки! Натравив дизассемблер на исследуемый файл, посмотрите – в какой секции расположена точка входа. И если этой секцией
окажется секция данных, исследуемый файл с высокой степенью вероятности заражен вирусом.При внедрении в а. out-файл вирус в общем случае должен проделать следующие действия:
1. Считав заголовок файла, убедиться, что это действительно a.out-файл.
2. Увеличить поле a_data на величину, равную размеру своего тела.
3. Скопировать себя в конец файла.
4. Скорректировать содержимое поля a_entry для перехвата управления (если вирус действительно перехватывает управление таким образом).
Внедрение в ELF-файлы происходит несколько более сложным образом:
1. Вирус открывает файл и, считывая его заголовок, убеждается, что это действительно ELF-файл.
2. Просматривая Program Header Table, вирус отыскивает сегмент, наиболее подходящий для заражения (для заражения подходит любой сегмент с атрибутом PLL0AD; собственно говоря, остальные сегменты более или менее подходят тоже, но вирусный код в них будет смотреться несколько странно).
3. Найденный сегмент «распахивается» до конца файла и увеличивается на величину, равную размеру тела вируса, что осуществляется путем синхронной коррекции полей p_filez и pjnemz.
4. Вирус дописывает себя в конец заражаемого файла.
5. Для перехвата управления вирус корректирует точку входа в файл (e_entry) либо же внедряет в истинную точку входа jmp на свое тело (впрочем, методика перехвата управления – тема отдельного большого разговора).
Маленькое техническое отступление. Секция данных, как правило, имеет всего лишь два атрибута: атрибут чтения (read) и атрибут записи (write). Атрибут исполнения (execute) у нее по умолчанию отсутствует. Означает ли это, что выполнение вирусного кода в ней окажется невозможным? Вопрос не имеет однозначного ответа. Все зависит от особенностей реализации конкретного процессора и конкретной операционной системы. Некоторые из них игнорируют отсутствие атрибута исполнения, полагая, что право исполнения кода напрямую вытекает из права чтения. Другие же возбуждают исключение, аварийно завершая выполнение зараженной программы. Для обхода этой ситуации вирусы могут присваивать секции данных атрибут execute, выдавая тем самым себя с головой; впрочем, такие экземпляры встречаются крайне редко, и подавляющее большинство вирусописателей оставляет секцию данных с атрибутами по умолчанию.
Другой немаловажный и неочевидный на первый взгляд момент. Задумайтесь, как изменится поведение зараженного файла при внедрении вируса в непоследнюю секцию. data, следом за которой расположена. bss? A никак не изменится! Несмотря на то что последняя секция будет спроецирована совсем не по тем адресам, программный код об этом «не узнает» и продолжит обращаться к неинициализированным переменным по их прежним адресам, теперь занятым кодом вируса, который к этому моменту уже отработал и возвратил оригинальному файлу все бразды правления. При условии, что программный код спроектирован корректно и не закладывается на начальное значение неинициализированных переменных, присутствие вируса не нарушит работоспособности программы.
Однако в суровых условиях реальной жизни этот элегантный прием заражения перестает работать, поскольку среднестатистическое UNIX-приложение содержит порядка десяти различных секций всех назначений и мастей.
Взгляните, например, на строение утилиты Is, позаимствованной из следующего дистрибьютива UNIX: Red Hat 5.0 (листинг 2.5).
Листинг 2.5. Так выглядит типичная карта памяти нормального файла
Секция. data расположена в самой «гуще» файла, и, чтобы до нее добраться, вирусу придется позаботиться о модификации семи остальных секций, скорректировав их поля p_offset (смещение секции от начала файла) надлежащим образом. Некоторые вирусы этого не делают, в результате чего зараженные файлы не запускаются.