Записки исследователя компьютерных вирусов
Шрифт:
чтение/запись файла) и опционально функция поиска файлов на диске/в сети. В противном случае вирус просто не сможет реализовать свои репродуктивные возможности, и это уже не вирус получится, а Троянский Конь!
Существует по меньшей мере три пути для решения этой задачи:
1. Использовать системные функции жертвы (если они у нее, конечно, есть).
2. Дополнить таблицу импорта жертвы всем необходимым.
3. Использовать native-API операционной системы.
Ассемблерные вирусы (а таковых среди UNIX-вирусов подавляющее большинство) разительно отличаются от откомпилированных программ нетипичным для языков высокого
Теперь рассмотрим каждый из вышеперечисленных пунктов во всех подробностях.
Заражение посредством поглощения файла
Вирусы этого типа пишутся преимущественно начинающими программистами, еще не успевшими освоить азы архитектуры операционной системы, но уже стремящимися кому-то сильно напакостить. Алгоритм заражения в общем виде выглядит так: вирус находит жертву, убеждается, что она еще не заражена и что все необходимые права на модификацию этого файла у него присутствуют. Затем он считывает жертву в память (временный файл) и записывает себя поверх заражаемого файла. Оригинальный файл дописывается в хвост вируса как оверлей либо же помещается в сегмент данных (рис. 2.1, 2.2).
Рис. 2.1. Типовая схема заражения исполняемого файла путем его поглощения
Рис. 2.2. Пример файла, поглощенного вирусом UNIX.a.out. Крохотный, всего в 300 байт, размер кодовой секции указывает на высокую вероятность заражения
Получив управление, вирус извлекает из своего тела содержимое оригинального файла, записывает его во временный файл, присваивает ему атрибут исполняемого и запускает «излеченный» файл на выполнение, а после завершения удаляет вновь. Поскольку подобные манипуляции редко остаются незамеченными, некоторые вирусы отваживаются на «ручную» загрузку жертвы с диска. Впрочем, корректный загрузчик elf-файла написать ой как нелегко и еще сложнее его отладить, поэтому появление таких вирусов представляется достаточно маловероятным (ELFэто вам не простенький a.out!)
Характерной чертой подобных вирусов является крошечный сегмент кода, за которым следует огромный сегмент данных (оверлей), представляющий собой самостоятельный исполняемый файл. Попробуйте контекстным поиском найти 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.