Как вычислить создателя вируса

Обновлено: 26.04.2024

Появившийся в Интернет 26 января вирус Mydoom, также известный как NovaRG, не только поразил систему электронной почты, но и спровоцировал начало яростных (и, порой, бессмысленных) споров о том, кто именно стоит за этой напастью.

Как известно, компьютеры, зараженные Mydoom, в "час "Д" должны начать атаку на сервер компании SCO Group для того, чтобы вывести его из строя, напоминает BusinessWeek. Расположенная в американском штате Юта, компания SCO Group известна тем, что именно она заявляет о своих правах на основу кода "открытой" операционной системы Linux. Из-за этого к ней предъявляют достаточно серьезные претензии другие создатели "открытых" компьютерных программ, настаивающие на том, что этот код не принадлежит никому. В подобных условиях было бы логично предположить, что инициатором атаки на сервер SCO Group, и, соответственно, создателем вируса Mydoom мог бы быть кто-то, причастный к спорам между этой компанией и ее оппонентами из числа программистов-любителей "открытого" кода, говорится в материале Worldeconomy.

По данным компании MessageLabs, занимающейся исследованием компьютерных вирусов, Mydoom впервые появился в России, что, правда, вовсе не означает, что он был создан именно в этой стране. Единственная подсказка, оставленная автором, состоит из английской фразы "синк-1.01; энди; Я просто делаю мою работу, ничего личного, извини", зашифрованной в программном коде вируса. Относительно мотивации автора Mydoom поползло еще больше слухов после того, как 28 января в Сети появился новый вариант этого вируса, нацеленный не только на сайт SCO Group, но и на сайт самой Microsoft.

Отсутствие четкой информации об авторе (или авторах?) Mydoom породило множество спекуляций на эту тему. "Мы не знаем, где кроются корни этой атаки, хотя у нас есть определенные подозрения по этому поводу", – говорит генеральный директор SCO Group Дарл МакБрайд: "Это преступная деятельность, и ее необходимо остановить. SCO предлагает вознаграждение в размере $250 000 за информацию, которая приведет к аресту и осуждению лиц, ответственных за это преступление". Более подробные комментарии от SCO Group нам пока получить не удалось.

Гораздо менее сдержанны в высказываниях адепты программного обеспечения с "открытым" кодом, многие из которых и без того просто помешаны на всевозможных конспирологических "теориях заговора". На сайте Slashdot.org, на котором собираются "открытокодники", можно найти десятки версий истории появления Mydoom. Многие посетители сайта считают, что руку к этому приложила сама SCO Group. Так, по словам посетителя под именем "Герцог-теней", становясь жертвой получившей широкую огласку вирусной атаки, в организации которой можно обвинить "адептов открытого кода", SCO Group только выигрывает. "Кто еще может получить преимущества от вируса, который был выявлен на столь раннем этапе?", – говорит он.

Ему вторит Брюс Перенс, гуру сторонников "открытого" программного кода. По его мнению, у SCO Group может быть веская причина попытаться "подставить" "открытокодников" для того, чтобы спасти свою собственную репутацию. "Мы дали явно понять, что они [SCO Group] солгали под присягой на суде. Такая компания не остановится перед тем, чтобы атаковать свой собственный сайт для того, чтобы представить своих оппонентов в черном свете", – заявляет он в статье, вывешенной на его собственном сайте. Другой потенциальный претендент на звание создателя Mydoom, по мнению Перенса – это спэммеры, т.е. организаторы назойливых рекламных почтовых рассылок, недовольные тем, как с ними борются программисты-"открытокодники". "Вполне вероятно, что этот вирус был создан с целью очернить создателей Linux спэммерами, SCO или кем-то еще. И, только ваше поведение может повлиять на то, преуспеют ли эти люди в своей миссии", – обращается Перенс к своим последователям.

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

Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!

Поговорим о компьютерных вирусах? Нет, не о том, что вчера поймал ваш антивирус. Не о том, что вы скачали под видом инсталлятора очередного Photoshop. Не о rootkit-e, который стоит на вашем сервере, маскируясь под системный процесс. Не о поисковых барах, downloader-ах и другой малвари. Не о коде, который делает плохие вещи от вашего имени и хочет ваши деньги. Нет, всё это коммерция, никакой романтики…

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

Мы будем говорить о вирусах, живущих в исполняемых файлах форматов PE и ELF, то есть о вирусах, тело которых представляет собой исполняемый код для платформы x86. Кроме того, пусть наш вирус не будет уничтожать исходный файл, полностью сохраняя его работоспособность и корректно инфицируя любой подходящий исполняемый файл. Да, ломать гораздо проще, но мы же договорились говорить о правильных вирусах, да? Чтобы материал был актуальным, я не буду тратить время на рассмотрение инфекторов старого формата COM, хотя именно на нем были обкатаны первые продвинутые техники работы с исполняемым кодом.

Начнём со свойств кода вируса. Чтобы код удобней было внедрять, разделять код и данные не хочется, поэтому обычно используется интеграция данных прямо в исполняемый код. Ну, например, так:

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

Куда положить вирус? Необходимо найти достаточно места, чтобы вирус туда поместился, записать его туда, по возможности не разломав файл и так, чтобы в области, в которой вирус окажется, было разрешено исполнение кода.
Как передать управление на вирус? Просто положить вирус в файл недостаточно, надо еще совершить переход на его тело, а после завершения его работы вернуть управление программе-жертве. Или в другом порядке, но, в любом случае, мы же договорились не ломать ничего, да?

Исполняемый файл (PE или ELF) состоит из заголовка и набора секций. Секции – это выровненные (см. ниже) буферы с кодом или данными. При запуске файла секции копируются в память и под них выделяется память, причем совсем необязательно того объёма, который они занимали на диске. Заголовок содержит разметку секций, и сообщает загрузчику, как расположены секции в файле, когда он лежит на диске, и каким образом необходимо расположить их в памяти перед тем, как передать управление коду внутри файла. Для нас интересны три ключевых параметра для каждой секции, это psize, vsize, и flags. Psize (physical size) представляет собой размер секции на диске. Vsize (virtual size) – размер секции в памяти после загрузки файла. Flags – атрибуты секции (rwx). Psize и Vsize могут существенно различаться, например, если программист объявил в программе массив в миллион элементов, но собирается заполнять его в процессе исполнения, компилятор не увеличит psize (на диске содержимое массива хранить до запуска не нужно), а вот vsize увеличит на миллион чего-то там (в runtime для массива должно быть выделено достаточно памяти).

Флаги (атрибуты доступа) будут присвоены страницам памяти, в которые секция будет отображена. Например, секция с исполняемым кодом будет иметь атрибуты r_x (read, execute), а секция данных атрибуты rw_ (read,write). Процессор, попытавшись исполнить код на странице без флага исполнения, сгенерирует исключение, то же касается попытки записи на страницу без атрибута w, поэтому, размещая код вируса, вирмейкер должен учитывать атрибуты страниц памяти, в которых будет располагаться код вируса. Стандартные секции неинициализированных данных (например, область стека программы) до недавнего времени имели атрибуты rwx (read, write, execute), что позволяло копировать код прямо в стек и исполнять его там. Сейчас это считается немодным и небезопасным, и в последних операционных системах область стека предназначена только для данных. Разумеется, программа может и сама изменить атрибуты страницы памяти в runtime, но это усложняет реализацию.

Также, в заголовке лежит Entry Point — адрес первой инструкции, с которой начинается исполнение файла.

Необходимо упомянуть и о таком важном для вирмейкеров свойстве исполняемых файлов, как выравнивание. Для того чтобы файл оптимально читался с диска и отображался в память, секции в исполняемых файлах выровнены по границам, кратным степеням двойки, а свободное место, оставшееся от выравнивания (padding) заполнено чем-нибудь на усмотрение компилятора. Например, логично выравнивать секции по размеру страницы памяти – тогда ее удобно целиком копировать в память и назначать атрибуты. Даже вспоминать не буду про все эти выравнивания, везде, где лежит мало-мальски стандартный кусок данных или кода, его выравнивают (любой программист знает, что в километре ровно 1024 метра). Ну а описание стандартов Portable Executable (PE) и Executable Linux Format (ELF) для работающего с методами защиты исполняемого кода – это настольные книжки.

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

Выбираем вкусный исполняемый файл (достаточно толстый, чтобы в него поместилось тело вируса, с нужным распределением секций и т.п.).
Читаем свой код (код тела вируса).
Берем несколько первых инструкций из файла-жертвы.
Дописываем их к коду вируса (сохраняем информацию, необходимую для восстановления работоспособности).
Дописываем к коду вируса переход на инструкцию, продолжающую исполнение кода-жертвы. Таким образом, после исполнения собственного кода вирус корректно исполнит пролог кода-жертвы.
Создаем новую секцию, записываем туда код вируса и правим заголовок.
На место этих первых инструкций кладем переход на код вируса.

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

Итак (рассматриваем классические вирусы), на входе имеем исполняемый файл и один из сотни тысяч потенциальных вирусов в нем. Давайте детектировать. Пусть это кусок исполняемого кода вируса:

сокрытие кода самого вируса;
сокрытие его точки входа.

Сокрытие точки входа (Entry Point Obscuring) в результате послужило толчком для появления в вирусных движках автоматических дизассемблеров для определения, как минимум, инструкций перехода. Вирус старается скрыть место, с которого происходит переход на его код, используя из файла то, что в итоге приводит к переходу: JMP, CALL, RET всякие, таблицы адресов и т.п. Таким образом, вирус затрудняет указание смещения сигнатуры.

Гораздо более подробно некоторые алгоритмы таких движков и детектора мы посмотрим во второй статье, которую я планирую написать в ближайшее время.

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

Китайские киберпреступники изначально были сфокусированы на атаках против пользователей онлайн-игр и краже данных. Отличительной чертой русскоязычных всегда было изобретение новых технологий, специализация на создании ботнетов, организация краж денег у банков и их клиентов, а также распространение спама и проведение DDoS-атак. Расцвет российского хакерства пришелся на 90е-начало 2000х годов, когда множество хороших молодых программистов не могли найти достойной работы, поэтому и занимались киберпреступлениями. С улучшением экономической ситуации в стране количество киберпреступников снижается, — это видно на примере и России.

Иногда вирусописатели добавляют в код своих программ скрытые послания. Например, наши американские коллеги как-то обнаружили в коде непонятную им надпись, и когда они показали ее нам, мы обнаружили написанное транслитом оскорбительное послание от русскоязычного хакера. Но подобные находки – редкость, большинство вирусописателей стараются скрыть или замаскировать свою национальную принадлежность.
- Существует ли возможность распознать "национальность вируса", то есть, понять происхождение вредоносной программы или ее создателя?
— Определить, кто стоит за атаками в киберпространстве, крайне непросто, а намеренное использование группировками ложных меток, призванных сбить исследователей с верного следа, лишь усложняет эту задачу.
В целом, определить страну, из которой исходит атака, можно по многим факторам. Прежде всего, это анализ кода – в нем могут содержаться слова, косвенно указывающие на языковую или национальную принадлежность авторов. Но, с нашей точки зрения, одних этих слов недостаточно для обвинительных выводов.
Киберпреступники могут намеренно оставлять ложные следы, запутывая тем самым следствие. Кроме того, русский язык, например, является языком общения во многих странах бывшего СССР, особенно в сфере компьютерных технологий. Поэтому делать выводы о "российском" следе в том или ином деле на этой основе — довольно опрометчиво. Аналогичная ситуация и с другими языками.

Отталкиваться от "цели", то есть, — от того, какие файлы или документы ищут киберпреступники, тоже недостаточно для точной атрибуции. Каждый случай уникален, — многое можно найти при анализе серверов управления вредоносной программой, IP-адресов, использованных хакерами.
Но, например, в истории с атакой Red October (*речь идет об обширной сети кибершпионажа против дипломатических и государственных структур, НИИ, промышленных компаний и военных ведомств разных стран) окончательно в "русском следе" мы убедились уже спустя несколько месяцев после публикации, – когда получили данные о том, что за хостинг серверов оплата проводилась наличными через уличные терминалы оплаты в Москве. Также мы получили часть переписки на чистом русском языке между хакерами и службой поддержки хостинговой компании.

К неоднозначным случаям можно отнести случаи с атаками Lazarus: различные исследования деятельности хакерской группы Lazarus неоднократно указывали на Северную Корею, однако признаки были в основном косвенные. К примеру, атака на Sony Entertainment была проведена незадолго до премьеры фильма "Интервью", в финале которого убивают лидера КНДР Ким Чен Ына (*выход фильма в прокат в США планировался на 25 декабря 2014г., но 18 декабря был отменён компанией "Sony Pictures Entertainment" из-за угроз хакеров и бойкота со стороны владельцев кинотеатров).

Однако предположение о причастности "северного соседа" основывалось, прежде всего, на возможном мотиве.
Некоторые дополнительные улики экспертам "Лаборатории Касперского" удалось установить в ходе расследования инцидента в одном из банков в Юго-Восточной Азии. На одном из взломанных серверов, который Lazarus использовала в качестве командного центра, удалось обнаружить важный артефакт. Первые подключения к серверу осуществлялись через VPN и прокси, и отследить их местонахождение было практически невозможно. Однако был также зафиксирован один запрос от редкого IP-адреса в Северной Корее. По одной из версий, это может указывать на то, что атакующие подключались к серверу с этого адреса из Северной Кореи. Однако нельзя также исключать вероятность, что подключение было "ложным флагом", то есть попыткой намеренно запутать экспертов и пустить их по ложному следу, или же кто-то из жителей Северной Кореи случайно посетил адрес сервера. То есть, окончательных доказательств мы так и не получили.

Впрочем, вопрос атрибуции это, прежде всего, задача правоохранительных органов. В 2014 году ФБР обнародовали результаты расследования атаки на Sony Pictures Entertainment и представили доказательства причастности Северной Кореи к этому инциденту.
Так что, атрибуция является чрезвычайно сложной задачей. Важно собрать не один и не два фактора, указывающих на причастность хакерской группы определенной национальности или организации к совершению преступления. Это долгий процесс, требующий тесного взаимодействия между компаниями в области безопасности, жертвами и правоохранительными органами разных стран мира, и при этом зачастую не приводящий к результату. Исключения бывают, как правило, только если сами атакующие допускают какие-то грубейшие ошибки.
— Существуют ли "внутренние бренды" среди группы создателей вредоносных кодов? Можно ли по почерку узнать не только откуда люди, сделавшие программу, но и к какой группировке они принадлежат?
— Можно рассмотреть группировку Sofacy: о ее русскоязычности свидетельствуют и некоторые комментарии в коде (не на русском конечно, а латиницей, транслит), и версии операционной системы, на которой файлы создавались, и часовые пояса. Кроме того, есть ряд дополнительных факторов: пересечение некоторых технологий в коде с другими ранее известными группами, также считающимися русскоязычными (например с Miniduke), использованные при регистрации доменов (еще в 2007 году) данные, некоторые ошибки в написании английских слов, свойственные русскоязычным авторам и т.д. Таким образом, получается целый комплекс улик, каждая из которых по отдельности мало что значит, но сложив их воедино можно получить общую картину.

Создатели вирусов нападают

Антивирусный сканер может быстро обнаружить изменения в программе, проверяя ее размер. Если размер файла был изменен в процессе запуска, это хороший индикатор того, что вирус инфицировал программу. Чтобы обойти эту проверку, пустотные (cavity) вирусы прятали свой код в пустых пространствах внутри файла программы, оставляя размер файла неизменным. Пустотные вирусы пошли еще со времен MS-DOS, начиная с вируса Lehigh. Использование этой техники в создании вирусов значительно возросло, когда Microsoft разработал Windows PE формат для возможности взаимодействия Windows программ в разных ОС Windows. С целью ускорить загрузку программ в формате PE, компиляторы Windows программ создавали пустые пространства внутри файлов. Многие вирусы, такие как W2K/Lamchi, использовали эти пустые пространства для сокрытия вирусного кода.

Создатели вирусов также стали применять технику сокрытия точки входа (entry point obscuration - EPO), чтобы прятать место нахождения jump-инструкции к коду вируса. Червь W32/MTX@M и вирус Win95/SK были одними из первых, использующих эту технику. Существует множество разновидностей этой идеи, от сокрытия блока вирусного кода в теле программы до фактического интегрирования вирусного кода в код программы. Многие АВ профессионалы рассматривают EPO вирусы как наиболее перспективные.

Создатели вирусов стали использовать техники шифрования для предотвращения быстрой идентификации антивирусным ПО. Изменяя ключ шифрования от компьютера к компьютеру, вирус может защитить свой код от быстрой идентификации. Группы разработчиков вирусов, такие как 29A VX, и отдельные разработчики, например Zombie и Black Baron, работают над усовершенствованием методов шифрования и мутации.

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

Суть не только в том, чтобы спрятать злонамеренный код, создатели вирусов также предпринимают шаги для атак против антивирусного ПО. Существуют три основных атаки, которые могут быть применены против эмуляторов системы. Первая из них – включение ненормальных и неестественных инструкций. Это программные инструкции, которые АВ программисты могли не рассмотреть ввиду того, что они практически не используются в реальных программах и слишком сложны для эмуляции, в итоге они не обнаруживаются эмуляторами.

Во второй атаке на эмуляторы системы, создатели вирусов пытаются использовать задержку между оценкой эмулятором подозрительного кода и временем исполнения в реальной системе. IDEA.6155 – наиболее старый пример этой атаки, в котором долгая процедура дешифровки может переполнить ограниченные ресурсы эмулятора.

В третьей атаке на эмуляторы кода, вирус пытается определить, что он находится в эмуляторе, используя ограничения в дизайне эмуляторов кода. Никакой эмулятор не может учесть все вероятные ситуации. Вирус может также варьировать свое поведение в зависимости от системной даты или воспринимая изменения типа потери сетевого соединения. Например, известно, что Magistr не заражает исполняемые файлы при отсутствии Интернет-соединения.

Вирус W32.Simile - один из последних метаморфных вирусов. Этот очень сложный вирус способен существовать как на Linux, так и на Windows платформах. Большая часть кода вируса, содержащего более 14000 ассемблерных команд, посвящена собственному метаморфическому механизму. Этот вирус, написанный создателем вирусов The Mental Driller, и обнаруженный в марте 2002 г., имеет множество антиэмуляторных функций. Он использует псевдослучайный алгоритм дешифровки, который использует модульные арифметические функции для дешифровки тела вируса нелинейным способом, не от начала до конца, а кусками, выбранными, по видимому, случайным образом, для того, чтобы запутать эмулятор.

Чтобы еще больше запутать эмулятор, вирус Simile воспользовался инструкцией RDTSC (Read Time Stamp Counter). Вирус анализирует внутренний процессорный счетчик и случайным образом определяет, пора расшифровывать код, или еще подождать. Это означает, что вирус может не расшифроваться с первой или даже с нескольких попыток. Ввиду сложности вирусного кода, он содержит множество ошибок, которые могут помешать расшифровке вируса в течение длительного времени.

Сложность Simile также указывает на то, что мало кто из создателей вирусов возьмется за написание действительно сложных вирусов. Наоборот, успех Hybris, Klez , Magistr, MTX, и Sircam указывает на то, что вирусам, эффективно использующим поддельные адреса возврата или изменение тела вируса, обеспечена долгая жизнь на мировой арене.

Антивирусные программисты отражают атаку!

Если файл в состоянии покоя не показывает наличие вируса, вирус все же может выйти из него при запуске. Анализ стека CPU эмулятора может указать на наличие признаков, сигнализирующих о наличии вируса.

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

Читайте также: