Записки исследователя компьютерных вирусов
Шрифт:
Небрежное тестирование операционной системы вкупе с использованием потенциально опасных языков программирования привело к тому, что всякий нехороший человек получил возможность выполнять на вашей машине свой зловредный машинный код, управление которому передается путем нехитрого переполнения буфера. Однако современные хакеры в своей массе настолько тупы, что даже переполнить буфер, не уронив при этом машину, оказываются не в состоянии!
Рис. 1.1. Это – не признак нестабильности системы. Это – признак вирусной атаки! Если нажать ОК – перестанет работать буфер обмена и некоторые другие функции системы, если нажать Отмена – запустится отладчик (если он у вас есть) и система полностью встанет. Если же не делать ни того, ни другого – система успешно продолжит свою работу…
Немедленно кликните мышью на Windows Update и скачайте все критические обновления, которые вы по своей лени не скачали до сих пор! Поймите же, наконец, что антивирусы против этой беды вам все равно не помогут, поскольку осуществляют лечение пост-фактум, когда зачастую лечить уже нечего… На худой конец, закройте 135-й порт – тогда вирусы и троянские кони не смогут распространяться.
Подробнее об этом рассказывается в разделе, посвященном червям и методам борьбы с ними.
Места наиболее вероятного внедрения вирусов
Объектом вирусного поражения могут выступать исполняемые файлы (динамические библиотеки, компоненты ActiveX, плагины), драйверы, командные файлы операционной системы (bat, cmd), загрузочные сектора (MBR и BOOT), оперативная память, файлы сценариев (Visual Basic Script, Java Script), файлы документов (Microsoft Word, Microsoft Excel) и… и это далеко не все! Фантазия создателей вирусов поистине безгранична, и потому угрозы следует ожидать со всех сторон.
Поскольку охватить все вышеперечисленные типы объектов в рамках «Записок…» не представляется сколь-нибудь разрешимой задачей, автор остановил свой выбор на самых интересных вирусоносителях – на исполняемых файлах. Во-первых, вирусы, поражающие исполняемые файлы (а также троянские программы, распространяющиеся через них же), лидируют по численности среди всех остальных типов вирусов вообще. Во-вторых, методология анализа new-ехе файлов на предмет их заражения не в пример скудно освещена. В-третьих, тема дизассемблирования достаточно интересна и сама по себе. Для многих она служит источником творческого вдохновения да и просто хорошим средством времяпрепровождения. Так что не будем мешкать и совершим наш решительный марш-бросок, снося всех вирусов, встретившихся на нашем пути!
Основные признаки вирусного внедрения
Единственным гарантированным способом выяснения, относится ли данный файл к «плохим» файлам или нет, является его полное дизассемблирование. Не скрою, дизассемблирование – крайне кропотливая работа и на глубокую реконструкцию программы размером в пять-десять мегабайт могут уйти годы, если не десятки человеко-лет! Чудовищные трудозатраты делают такой способ анализа чрезвычайно непривлекательным и бесперспективным. Давайте лучше отталкиваться от того, что подавляющее большинство вирусов и троянских коней имеют ряд характерных черт, своеобразных «родимых пятен», отличающих их от всякой «нормальной» программы. Надежность таких «индикаторов» зараженности существенно ниже, и определенный процент зловредных программ при этом останется незамеченным, но… как говорится, на безрыбье и слона из мухи сделаешь!
Количество всевозможных «родимых пятен», прямо или косвенно указывающих на зараженность файла, весьма велико, и ниже перечислены лишь наиболее характерные из них. Но даже они позволяют обнаружить до 4/5 всех существующих вирусов, а по некоторым оценкам и более того (по крайней мере, все «лауреаты» вирусного ТОР-20 – обнаруживаются).
Текстовые строки
Прежде чем приступать к тотальному дизассемблированию исследуемого файла, нелишне пролистать его дамп на предмет выявления потенциально небезопасных текстовых строк, к которым, в частности, относятся команды SMTP – сервера и командного интерпретатора операционной системы (HELO/MAIL FROM/MAIL TO/RCPT ТО и DEL/COPY/RD/RMDIR соответственно), ветвей автозапуска реестра (RunServices, Run, RunOnce), агрессивные лозунги и высказывания («легализуем марихуану», «сам дурак») и т. д.
Конечно, все это еще не свидетельствует о наличии вируса (троянской программы), а отсутствие компрометирующих программу текстовых строк не гарантирует ее лояльности, но… просто поразительно, какое количество современных вирусов ловится таким элементарным способом. Не иначе как снижение культуры программирования дает о себе знать! Действительно, подавляющее большинство современных программ (и вирусов в том числе) разрабатывается на языках высокого уровня, и программисты не дают себе никакого труда хоть как-то скрыть «уши», торчащие из секции данных (не знают, как это сделать?). Откомпилированная программа просто шифруется статическими упаковщиками, которые легко поддаются автоматической/полуавтоматической распаковке, выдавая исследователю исходный дамп со всеми текстовыми строками на поверхности (см. раздел «Идентификация упаковщика и автоматическая распаковка»).
Ниже в качестве примера приведен фрагмент вируса I-Worm.Kiliez.e, на малоизвестность которого жаловаться не приходится (Вах! Как трудно взглянуть на дамп того, что вы запускаете!) (листинг 1.1). Текстовые строки, содержащиеся в теле I-Worm.Kiliez.e, выдают агрессивные намерения последнего с головой!
Листинг 1.1. Фрагмент вируса I-Worm.Kilez.e
Идентификация упаковщика и автоматическая распаковка
Упаковка исполняемых файлов «навесными» упаковщиками была широко распространена еще во времена господства MS-DOS и преследовала собой следующие цели:
– уменьшение размеров программы на диске;
– сокрытие текстовых строк от посторонних глаз;
– затруднение анализа программы;
– «ослепление» сигнатурного поиска.
Два последних пункта стоит отметить особо. Напрямую дизассемблировать упакованную программу нельзя. Прежде исследователю предстоит разобраться с упаковщиком, зачастую основанным на весьма нетривиальном алгоритме и содержащим большое количество разнообразных приемов против отладчиков и/или дизассемблеров. Также существуют и полиморфные упаковщики (например, tElock), генерирующие машинный род распаковщика на «лету» и делающие зашифрованные экземпляры одной и той же программы не похожими друг на друга.
Для борьбы с упаковщиками было создано большое количество автоматических распаковщиков, работающих по принципу трассировки исполняемого кода и отслеживания момента передачи управления на оригинальный код. Для борьбы с антиотладочными приемами использовалась технология эмуляции процессора, обхитрить которую было не так-то просто, хотя все-таки возможно, но на этот случай в некоторых из распаковщиков был предусмотрен режим ручной распаковки, в котором распаковывалось все, что только было можно распаковать.
С переходом на Windows многое изменилось. Количество упаковщиков резко возросло, но ни одного универсального распаковщика до сих пор так и не появилось, а потому анализ упакованных файлов представляет собой одну из актуальнейших проблем современной антивирусной индустрии.
ПРИМЕЧАНИЕ
Если при дизассемблировании исследуемого файла большую часть исполняемого кода дизассемблер представил в виде дампа или выдал на выходе бессмысленный мусор (неверные опокоды команд, обращения к портам ввода/вывода, привилегированные команды, несуществующие смещения и т. д.), то файл, скорее всего, упакован и/или зашифрован.