RootKit узнаем, что да как

ВВЕДЕНИЕ

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

Вирусы давным давно переросли из обычных хулиганских шалостлевых программ в экономичеого рода вредоносное программное обеспечение, такие цитаты вы уже слышали и читали не один раз, и то, что антивирусные компании день ото дня борятся с всё новыми и новыми разновидностями вирусов. Но один объект из всей этой дьявольской системы почему то не рассматривается антивирусными компаниями, ну или же рассматривается частично для галочки с написанием небольшего модуля. Данным объектом является rootkit — это программное обеспечение которое помогает злоумышленнику остоваться незамеченным во взломанной машине.

Каждый из нас, точнее каждый из тех кто сидит(ел) на windows сталкивался с выскакиванием окошек с одной кнопочкой ОК и сообщением, с какими то не понятными цыфрами. Эти окна реально мешают и влияют на психику, что может привести к нервному срыву и в один прикрасный день вы можете очутиться в желтой комнате окружающая тебя только мягкими стенами =). Ну, если убрать шутки в сторону, то — это сообщение знак того, что rootkitu не удалось совершить свой каварный замысел по какой либо причине, может не хватила прав, может файл был занят или банально косяк windows (хоть в чем то польза от них). На данной стадии для вас ничего не понятно, по этому давайте приступим по быстрее к делу.

ROOTKIT ЧТО ЗА ЗВЕРЬ?

RootKit — происхождение этого слово ищет свое начало, задолго до появления первых дырявых форточек(windows). Данное слово водилось в далеких и загадочных для нас в то время UNIX системах, которое имело свое логическое начало. Хакер как только проникал в систему и получал права суперпользователя(root) то устанавливал ряд утилит для скрытия следов пресудствия в системе. А точнее подчищает всякие системные файлы.

Но, как видно из статистики инновационные продвижения в сфере информационных систем а конкретнее информационной и системной безопасности не стоит на месте и rootkit обрел очень большие масштабы и накрыл медным тазом операционную систему windows =).

В опирационной системе windows невозможно изменение системных файлов, но есть более легкий способ это:

• перехват системных функций Windows API на уровне пользователя;
• то же на уровне ядра (перехват Native API).

Rootkit так и класифицируется на:

• Уровня пользователя (user-mode);
• Уровня ядра (kernel-mode).

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

1. Одноразовые — данный вид RootKit при попадании в компьютер жертвы не записываются на жесткий диск, а идут прямиком в оперативную память, отследить такого хитрюгу практически не возможно ведь он находится в оперативной памяти, поможет убрать данный RootKit банальная перезагрузка компьютера которая очистит опиративную память.
2. Долговременные — этот вид RootKit в частых случаях не просто записывается на жесткий диск, а еще имеет наглость устанавливать свои собственные драйвера в систему, что практически дает ему возможность выдавать себя за проверенное программное обеспечение или даже какой не будь из системных процессов.

МЕХАНИЗМ РАБОТЫ ROOTKIT.

Как же все таки работает этот заверь? Давайте разберемся, а начнем пожалуй с первого варианта «перехват системных функций Windows API на уровне пользователя». Для того, что бы разобраться в данном способе необходимо немного погрузиться в программирование, давайте вспомним как происходит вызов функций, размещеные в dll библиотеке.

Существует два сопособа

1. Раннее связывание - Этот метод основан на том, компилятору известен перечень импортируемых программой функций. Опираясь на эту информацию, компилятор формирует так называемую таблицу импорта EXE файла. Таблица импорта – это особая структура (ее местоположение и размер описываются в заголовке EXE файла), которая содержит список используемых программой библиотек и список импортируемых из каждой библиотеки функций. Для каждой функции в таблице имеется поле для хранения адреса, но на стадии компиляции адрес не известен. В процессе загрузки EXE файла система анализирует его таблицу импорта, загружает все перечисленные в ней DLL и производит занесение в таблицу импорта реальных адресов функций этих DLL. У раннего связывания есть существенный плюс – на момент запуска программы все необходимые DLL оказываются загруженными, таблица импорта заполнена – и все это делается системой, без участия программы. Но отсутствие в процессе загрузки указанной в его таблице импорта DLL (или отсутствие в DLL требуемой функции) приведет к ошибке загрузки программы. Кроме того, очень часто нет необходимости загружать все используемые программой DLL в момент запуска программы.
2. Позднее связывание - Отличается от раннего связывания тем, что загрузка DLL производится динамически при помощи функции API LoadLibrary. Эта функция находится в kernel32.dll, поэтому если не прибегать к хакерским приемам, то kernel32.dll придется загружать статически. При помощи LoadLibrary программа может загрузить интересующую ее библиотеку в любой момент времени. Соответственно для получения адреса функции применяется функция kernel32.dll GetProcAddress. Чтобы не вызывать GetProcAddress перед каждым вызова функции из DLL программист может однократно определить адреса интересующих его функций и сохранить их в массиве или некоторых переменных.Независимо от метода связывания системе необходимо знать, какие функции экспортирует DLL. Для этого у каждой DLL имеется таблица экспорта – таблица, в которой перечислены экспортируемые DLL функции, их номера (ординалы) и относительные адреса функций (RVA).

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

При модификации таблицы импорта идея метода проста – RootKit находит в памяти таблицу импорта программы и исправляет адреса интересующих его функций на адреса своих перехватчиков (естественно, он предварительно где-то у себя запоминает правильные адреса). В момент вызова API функции программа считывает ее адрес из таблицы импорта и передает по этому адресу управление. Методика универсальна, но у нее есть существенный недостаток - перехватываются только статически импортируемые функции. Но есть и плюс – методика очень проста в реализации и есть масса примеров, демонстрирующих ее реализацию. Поиск таблицы импорта в памяти не представляет особой сложности, поскольку для этого существуют специализированные API функции, позволяющие работать с образом программы в памяти. Исходный текст такого перехватчика на языке C занимает несколько листов печатного текста.

Перехват функций LoadLibrary и GetProcAddress может быть выполнен любым методом, в классической реализации применяется методика – модификация таблицы импорта. Идея методики проста – если перехватить GetProcAddress, то при запросе адреса можно выдавать программе не реальные адреса интересующих ее функций, а адреса своих перехватчиков. Как и в методе “модификация таблицы импорта” программа «не почувствует» разницы. При вызове GetProcAddress она получает адрес и выполняет вызов функции. У данного метода есть минус – он не позволяет перехватить статически импортируемые функции.

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

Перехват функций в режиме ядра (kernelmode)

Опять же, для понимания перехвата функций, необходимо рассмотреть взаимодействие библиотек пользовательского режима и ядра.

Основное взаимодействие с ядром производится через библиотеку ntdll.dll, большинство функций которой являются переходниками, обращающимся к ядру через прерывание INT 2 Eh. Дальнейшее обращение к функциям ядра основана на структуре, именуемой KeServiceDescriptorTable (SDT) расположенной в ntoskrnl .exe. SDT – это такая таблица, содержащая адреса точек входа сервисов ядра. Упрощенно можно сказать, что для перехвата функций необходимо написать драйвер, который произведет модификацию таблицы SDT. Перед модификацией драйверу необходимо сохранить адреса перехватываемых функций и записать в таблицу SDT адреса своих обработчиков. Этот метод часто называют перехватом Native API и естественно он работает только в NT (и соответственно W2K, XP, W2003). Следует отметить, что перехват Native API осуществляют не только руткиты – существует масса полезных программ, перехватывающих функции при помощи правки SDT – в качестве примера могут служить популярная утилита RegMon от SysInternals или программа Process Guard .

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

МЕТОДИКИ ОБНАРУЖЕНИЯ ROOTKIT

К сожалению, нельзя дать универсальных рекомендаций по обнаружению rootkit, но приведенные ниже действия позволят обнаружить большинство современных RootKit:

1. Сравнение двух «снимков» системы (например, списка файлов на диске). Первый снимок делается на проверяемой системе, второй – после загрузки с CD или подключения исследуемогоHDD к заведомо чистому компьютеру. Подобная методика гарантированно позволит обнаружить любой RootKit, который маскирует на диске свои файлы.
2. Сравнение данных, возвращаемых API функциями разного уровня и получаемых низкоуровневыми методами (например, прямым чтением диска и анализом файлов реестра). Данная методика не требует перезагрузки исследуемого ПК и реализована в бесплатной утилите RootkitRevealer от SysInternals (http://sysinternals.com). Другим примером может случить утилита Klister (rootkit.com) для построения списка запущенных процессов, которая состоит из драйвера и консольной программы, использующей этот драйвер;
3. Анализ в памяти функций основных библиотек на предмет наличия изменений их машинного кода. Данный метод наиболее эффективен для борьбы с RootKit в пользовательском режиме. Подобная методика позволяет не только обнаружить перехват функций, но и восстановить нормальную работу поврежденных функций. Кроме того, сравнение «снимков» системы, полученных до и после восстановления функций API во многих случаях позволяет обнаружить маскирующиеся процессы, сервисы и драйверы. Данная методика не требует перезагрузки и один из вариантов реализован в утилите AVZ (http://z-oleg.com/secur/avz/download.php);
4. Анализ и восстановление ServiceDescriptorTable. Данная методика позволяет бороться с рядом перехватчиков, работающих в режиме ядра (собственно, с перехватчиками, основанными на правкеSDT). Практическая реализация – утилита SDTRestore(http://security.org.sg/code/sdtrestore.html). Однако восстановление SDT окажет воздействие на работу всей системы и может привести к очень неприятным последствиям (в простейшем случае – полное зависание системы с выходом на BSoD, в худшем – непредсказуемое нарушение нормальной работы приложений, перехватывающих NativeAPI для реализации своих функций).
5. Исследование аномального поведения файлов, использования сети, запуска задач по расписанию и в момент загрузки, регистрационных записей пользователей.

ЗАКЛЮЧЕНИЕ

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

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