Анализ злонамеренного программного обеспечения

Автор: S.G.Masood
Перевод: SecurityLab

Угроза злонамеренного программного обеспечения в настоящее время является самой большой угрозой защиты Internet. Еще несколько лет назад более или менее единственной формой злонамеренных программ были компьютерные вирусы. В настоящее время коллекция злонамеренных кодов пополнилась сетевыми саморазмножающимися вирусами, троянами, DDoS агентами, IRC ботами, шпионскими программами и так далее. Также заметно изменились и разнообразились способы нападений, позволяющие злонамеренным агентам распространятся через массовые рассылки, различные уязвимости в браузерах, уязвимости операционной системы и P2P сети. Множество постоянно используемого программного обеспечения содержит в себе злонамеренный код. Большинство подобных программ может быть обнаружено с помощью антивирусов и программных средств, предназначенных для поиска и удаления различных рекламных и шпионских модулей. Однако этой защиты не всегда достаточно, и бывают случаи, когда небольшая программа обходит все уровни вашей защиты и ставит под угрозу ваши персональные данные. Хотя антивирусное программное обеспечение непрерывно обновляется, всегда существует небольшой, но все-же существенный процент злонамеренных программ, которые не будут обнаружены вашими автоматизированными средствами защиты. К сожалению, этот процент возрастает с каждым днем.

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

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

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

2. Подготовка, цели, предположения и инструментальные средства

2.1 Подготовка

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

Анализ кода - один из первичных методов, используемых для исследования злонамеренного программного обеспечения. Лучший способ понять, как работает программа, конечно, состоит в том, чтобы изучить исходный код программы. Однако исходный код для большинства злонамеренных программ недоступен. Злонамеренное программное обеспечение чаще всего распространяется в виде выполняемых программ, и двоичный код должен дополнительно исследоваться, используя отладчики и дизассемблеры. Однако использование этих инструментальных средств требует высоких специализированных знаний, поэтому их могут использовать очень ограниченное количество специалистов. Учитывая это, любой код, несмотря на его размер и сложность, может быть полностью исследован, используя методы анализа кода.

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

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

2 Цели в анализе

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

Используя эти методы, люди должны получить возможность анализировать неизвестный исполняемый код и определять - злонамеренный ли он или нет. Те, кому требуется более глубокое изучение, должны быть способны восстановить и исследовать код программы, чтобы полностью понять и задокументировать ее работу.

2.3 Предположения и определения

В этой части мы рассмотрим несколько предположений ради удобства и понятности. Вот они:

1. Мы предполагаем, что исследуемое программное обеспечение для Win32 систем на Intel x86 машинах. Основные принципы могут быть также применены к любой другой платформе.

2. Хост машина, на которой выполняется исследуемый код, упоминается как "хост жертвы" или "машина жертвы".

3. Другие компьютеры в тестируемой сети сети упоминаются как как "сниффер машина".

2.4 Инструментальные средства

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

Предложенная структура разделена на шесть стадий:

1. Создание управляемой среды
2. Контроль изменения среды
3. Сбор информации
4. Анализ информации
5. Восстановление изображения
6. Документация результатов

3.1 Создание управляемой среды

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

• Должно использоваться не менее двух машин. Одна машина используется для запуска злонамеренной программы (машина жертвы) а другая для создания среды и анализа сетевого трафика (сниффер машина).
• Две связанных в сеть машины лаборатории должны быть изолированы от остальной части сети.
• Свежие копии операционных систем должны быть установлены на каждой из двух машин. Так как мы анализируем Win32 программу, то WinNT машина должна выступать в качестве машины жертвы, а *nix основанная OS система установлена на сниффер машине.
• Инструментальные средства должны быть установлены на соответствующих машинах.
• Исследуемый Win32 код должен быть перемещен на Windows систему.
• Желательно не устанавливать никаких дополнительных приложений на хост жертвы, кроме необходимых для анализа утилит.

Это самая основная установка для лаборатории анализа злонамеренного программного обеспечения. Кроме этого и в зависимости от ситуации, могут быть выполнены и другие модификации. Например, если злонамеренный код пытается соединиться с удаленным сервером xyz.com, то должен быть установлен DNS сервер на одной из машин в лаборатории и создана DNS запись для домена xyz.com. Превосходная статья, которая обсуждает создание лаборатории анализа злонамеренного программного обеспечения - "An Environment for Controlled Worm Replication and Analysis".

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

3.2 Контроль изменения среды

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

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

Элементы среды, которые должны быть проконтролированы:

3.2.1 Машина жертвы

Некоторые элементы, которые должны быть проконтролированы в машине жертвы:

• Файловая система. Необходимо зафиксировать любые изменения в файловой системе. Существует множество программ, которые могут создать снимок файловой системы и после того, как произошли какие либо изменения, отобразить их. К примеру, мы можем использовать для этих целей программы - Winalysis и Installrite.
• Реестр. Реестр является следующим компонентом, который должен быть зафиксирован. Большинство злонамеренных приложений изменяют записи реестра. Поэтому критично фиксировать любые изменения системного реестра. Winalysis, как упомянуто выше, - одна из доступных программ, которая может использоваться для контроля изменений системного реестра.
• Запущенные процессы: Снимок запущенных процессов может быть создан с использованием различных программ. Некоторые из них доступны на Sysinternals.
• Открытые порты: Снимок открытых портов может быть создан с использованием утилиты netstat. Однако она не отображает имена процессов, которые привязаны к порту. Для этого, мы можем использовать утилиту Fport от Foundstone.
• Также должны быть зафиксированы изменения в пользователях, группах, сетевых общедоступных ресурсов и сервисов.

3.2.2 Сетевой Трафик

Следующий элемент, в котором должны быть зафиксированы изменения, является сетевой трафик. Даже когда нет никаких приложений, запущенных на тестовой системе, все равно существует некоторый сетевой трафик. Этот трафик должен быть зарегистрирован и должен быть определен “нормальный трафик” для нашей сети. Любые изменения от “нормального трафика”, мы предполагаем были вызваны нашим исследуемым кодом.

Любое программное обеспечение для анализа сетевого трафика (сниффер), установленное на “сниффер машине”, может использоваться для наших задач. Однако, чтобы упростить нашу задачу, предпочтительно использовать анализатор протоколов, типа Ethereal.

3.2.3 Внешнее представление

Хотя мы создали снимок открытых портов в машине жертвы, всегда лучше создать еще один снимок от внешней машины. Сканер портов, запущенный на нашей “cниффер машине”, может использоваться для выполнения поставленной задачи. Для большинства пользователей, удачным выбором сканера портов является Nmap.

3.3 Сбор информации

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

3.3.1 Статический анализ

В течении статической стадии анализа мы собираем всю возможную информацию об исследуемом коде, не выполняя его. Для этого используется множество различных методов и инструментальных средств. Статический анализ показывает сценарии, HTML, GUI, пароли, команды, каналы управления, и так далее. Также регистрируются вещи подобно имени файла, размеру, версии (right-click>properties>version в Win32).

Также извлекаются и регистрируются читаемые строки из исследуемого кода. Для этого может использоваться программа типа Binary Text Scan. Эти строки раскрывают множество различной информации о исследуемой программе.

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

3.3.2 Динамический анализ

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

После получения снимка всех изменений, которые выполнил наш код в системе, мы прерываем работу исследуемого процесса. Теперь определены различия между новым снимком и базовым снимком. В этом шаге могут использоваться различные инструментальные средства, типа упоминавшихся ранее Winalysis и InstallRite, а также Filemon и Regmon от Sysinternals могут использоваться для динамического мониторинга файловой системы и реестра.

Зарегистрированная информация формирует данные следующей стадии нашего анализа. Информация, сгенерированная здесь, может быть новыми файлами, записями системного реестра, открытыми портами, и т.д.

Иногда, статический шаг анализа должен быть повторен еще раз после выполнения динамического анализа.

3.4 Анализ информации

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

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

3.4.1 Интернет поиск

Поисковая система может использоваться для поиска дополнительной информации о нашей программе. Ключевые слова для поискового сервера могут быть взяты из информации, сгенерированной в течение предыдущей стадии "Статического Анализа". Вещи подобно именам файла, записям системного реестра, командам, и т.д. часто показывают много информации о злонамеренном программном обеспечении. Некоторые хорошие источники информации в Интернете включают Базы данных вирусов (представленные производителем антивирусов), новостными группами и листами рассылок. Чаще всего поиск в Интернете предоставит вам достаточно информации о злонамеренном программном обеспечении, в связи с чем, пропадает необходимость в дальнейшем исследовании.

3.4.2 Методы запуска

Каждое злонамеренное программное обеспечение создает способ быть выполненным после перезагрузки системы. Это - самый уязвимый аспект злонамеренного программного обеспечения. Есть ограниченное число путей во всех операционных системах, которые программа может использовать, чтобы запуститься автоматически после перезагрузки операционной системы. Информация, собранная в течение предыдущей стадии, может быть проанализирована, чтобы идентифицировать метод запуска злонамеренного программного обеспечения. Рекомендуем почитать статью о возможных методах запуска - Paul Collins' Startup List.

3.4.3 Протокол связи

Анализатор сетевых протоколов, подобно Ethereal, во многих случаях может идентифицировать протокол связи, используемый исследуемым кодом. Когда дело обстоит не так, должен быть исследован используемый протокол. Это – отдельная тема и ее описание не входит в данную статью.

3.4.4 Механизм распространения

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

3.5 Документация результатов

Необходимо задокументировать результаты анализа злонамеренного программного обеспечения. Одно из главных преимуществ - то, что знания, включенные в документацию, могут использоваться для анализа других систем.

4. Заключение

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