Спомощью обработчиков исключений можно эксплуатировать уязвимости

вкоде, чтобы получить контроль над выполнением. Указатель на сведения об обработке исключения хранится в стеке, и во время переполнения стека злоумышленник может его перезаписать, подменив обработчик своим собственным. В итоге, когда произойдет исключение, злоумышленник сможет выполнить свой код. Более детально исключения будут рассмотрены в главах 8–10, 15 и 16.

Сравнение режимов ядра и пользователя

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

Почти весь код, за исключением ОС и драйверов оборудования, выполняется в пользовательском режиме. Каждый процесс обладает собственной памятью, правами доступа и ресурсами. Если программа в режиме пользователя выполнит некорректную инструкцию и выйдет из строя, Windows сможет ее завершить и вернуть все ее ресурсы.

Обычно пользовательский режим не предоставляет прямого доступа к аппаратному обеспечению и ограничивается лишь определенным набором регистров и инструкций процессора. Для взаимодействия с оборудованием или изменения состояния ядра приходится использовать Windows API.

Функция Windows API, которая работает со структурами ядра, должна делать вызов из самого ядра. О наличии такого вызова в дизассемблированном коде могут свидетельствовать инструкции SYSENTER, SYSCALL и INT 0x2E. Чтобы найти в ядре заранее определенную функцию, они используют справочные таблицы, так как непосредственное переключение между режимом пользователя и ядра невозможно.

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

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

Код ядра представляет большой интерес для авторов вредоносного ПО, потому что он дает больше возможностей, чем код в пользовательском режиме. Большинство программ, обеспечивающих безопасность (как антивирусы и брандмауэры), работает в режиме ядра — это позволяет им отслеживать активность всех приложений, запущенных в системе. Вредонос, работающий в ядре, может с легкостью нарушить работу таких программ или обойти их защиту.

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

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

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

Native API

Native API — это низкоуровневый интерфейс для взаимодействия с Windows, который редко используется обычными программами, но популярен среди разработчиков вредоносного ПО. Путем вызова функций из Native API можно обойти стандартный Windows API.

Функция, которая находится в Windows API, обычно не выполняет запрашиваемое действие самостоятельно, поскольку большинство важных структур данных находится в ядре и недоступно за его пределами (из пользовательского режима). Компания Microsoft создала многоступенчатую процедуру, с помощью которой пользовательское приложение может получить доступ к нужным возможностям. То, как это работает для вызовов в большинстве API, проиллюстрировано на рис. 7.3.

Рис. 7.3. Режимы пользователя и ядра

Пользовательские приложения имеют доступ к пользовательским API, таким как kernel32.dll, и другим DLL, которые, в свою очередь, обращаются к специальной библиотеке ntdll.dll, отвечающей за взаимодействие между пространством пользо-

вателя и ядра. Процессор переключается в режим ядра и выполняет в нем функцию, которая обычно находится в процессе ntoskrnl.exe. Это довольно извилистый путь, но разделение между API ядра и пользователя позволяет компании Microsoft изменять внутренности системы, не затрагивая существующие приложения.

Функции из ntdll.dll используют те же API и структуры, что и само ядро. В совокупности они составляют Native API. Этот интерфейс не должен вызываться обычными приложениями, но ничто в системе этому не препятствует. И хотя Microsoft не предоставляет исчерпывающей документации для Native API, ему посвящены разные сайты и книги. Лучшим источником информации по этой теме является справочник Гэри Неббета Windows NT/2000 Native API Reference (Sams, 2000), хотя он уже довольно старый. Более свежие сведения можно найти на таких веб-ресурсах, как undocumented.ntinternals.net.

Использование Native API является привлекательным для авторов вредоносных программ, позволяя им делать вещи, которые иначе были бы невыполнимыми. Этот интерфейс обладает многими возможностями, недоступными в обычном Windows API.

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

На рис. 7.4 показано, как плохо спроектированная система безопасности пытается отследить вызов системной функции из kernel32.dll. Чтобы обойти эти систему, некий гипотетический вредонос использует Native API. Вместо вызова стандартных для Windows функций ReadFile и WriteFile он обращается к функциям NtReadFile и NtWriteFile, которые находятся внутри ntdll.dll и не отслеживаются. Качественный пакет безопасности следит за вызовами на всех уровнях, в том числе и в ядре, делая подобный подход бесполезным.

Рис. 7.4. Использование Native API с целью избежать обнаружения

В Native API есть множество вызовов для получения информации о системе, процессах, потоках, дескрипторах и других элементах. Среди них можно выделить

NtQuerySystemInformation, NtQueryInformationProcess, NtQueryInformationThread, NtQueryInformationFile и NtQueryInformationKey. Эти вызовы предоставляют намного более подробную информацию, чем любая функция, доступная в Win32. Некоторые из них позволяют устанавливать детальные атрибуты для файлов, процессов, потоков и т. д.

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

ПРИМЕЧАНИЕ

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

Родными называют приложения, которые не используют подсистему Win32, а обращаются напрямую к Native API. Среди вредоносного ПО такие приложения изредка встречаются, но обычных программ подобного рода почти не существует. Поэтому, если встретите такой код, знайте, что он, скорее всего, заражен. Определить, является ли приложение родным, можно по его подсистеме в PEзаголовке.

Итоги главы

Эта глава посвящена концепциям Windows, которые играют важную роль в анализе безопасности. При исследовании вредоносных программ вы непременно будете сталкиваться с такими понятиями, как процессы, потоки и сетевые возможности.

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

Лабораторная работа 7.1

Проанализируйте вредоносную программу Lab07-01.exe.

Вопросы

1.Как эта программа обеспечивает постоянное возобновление своей работы (например, после перезагрузки компьютера)?

2.Зачем эта программа использует мьютексы?

3.Какая локальная сигнатура подойдет для обнаружения этой программы?

4.Какая сетевая сигнатура подойдет для обнаружения этой программы?

5.Каково назначение этой программы?

6.При каких условиях эта программа завершит свою работу?

Лабораторная работа 7.2

Проанализируйте вредоносную программу Lab07-02.exe.

Вопросы

1.Каким путем эта программа обеспечивает постоянное возобновление своей работы?

2.Каково назначение этой программы?

3.При каких условиях эта программа завершит свою работу?

Лабораторная работа 7.3

Для этой лабораторной работы мы извлекли два зараженных файла: исполняемый Lab07-03.exe и библиотеку Lab07-03.dll. Мы сделали это до их запуска, это важно, поскольку вредонос может изменить себя во время выполнения. Оба файла были найдены в одном и том же каталоге на компьютере жертвы. При анализе их следует запускать именно в таком виде. Обнаруженная строка 127 (IP-адрес типа loopback) позволяет подключаться к локальной системе (в настоящей версии этого вредоноса содержится удаленный адрес, но мы поменяли его на локальный, чтобы вас защитить).

ПРЕДУПРЕЖДЕНИЕ

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

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

Вопросы

1.Каким образом эта программа обеспечивает постоянное возобновление своей работы?

2.Какие две локальные сигнатуры можно подобрать для этого вредоноса?

3.Каково назначение этой программы?

4.Как бы вы удалили эту программу после установки?

Часть III Продвинутый динамический анализ