4. Поиск RootKit и программ, перехватывающих функции api (в соавторстве с Олегом Зайцевым)
Так называется первая секция текстового протокола. Она состоит из нескольких подпунктов.
Первые два описывают действия AVZ по детектированию и нейтрализации перехватов системных событий в UserMode и KernelMode:
1.1 Поиск перехватчиков api, работающих в UserMode
Анализ kernel32.dll, таблица экспорта найдена в секции .text
Функция kernel32.dll:CreateProcessA (99) перехвачена, метод APICodeHijack.JmpTo[5FF2558A]
1.2 Поиск перехватчиков api, работающих в KernelMode
Драйвер успешно загружен
SDT найдена (RVA=07B180)
Ядро ntkrnlpa.exe обнаружено в памяти по адресу 804D7000
SDT = 80552180
KiST = 80501030 (284)
Функция NtAccessCheck (01) перехвачена (805E5664->F73E17AA), перехватчик C:\WINDOWS\system32\Drivers\safemon.sys
Это отрывок из virusinfo_syscheck. В протоколе virusinfo_syscure за каждым детектированным перехватом следует информация о попытке его нейтрализации:
Функция kernel32.dll:CreateProcessA (99) перехвачена, метод APICodeHijack.JmpTo[5FF2558A]
>>> Код руткита в функции CreateProcessA нейтрализован
Функция NtAccessCheck (01) перехвачена (805E5664->F73E17AA), перехватчик C:\WINDOWS\system32\Drivers\safemon.sys
>>> Функция воcстановлена успешно !
>>> Код перехватчика нейтрализован
Эти записи также не являются однозначным признаком инфекции. Они лишь свидетельствуют о том, что в системе существуют перехваты, которых не должно быть по умолчанию. Обычно это признаки работы тех или иных программных средств защиты.
Что такое SSDT?
System Service Descriptor / Dispatch Table, таблица дескрипторов (описаний) / обработки системных сервисов. При вызовах системных функций она используется ядром Windows в процессе их обработки. Модифицируя SSDT, приложение получает возможность управлять этими функциями. Разберем примерную схему того, как руткит может скрывать требуемые файлы с помощью KernelMode перехватов.
Загрузив драйвер, AVZ ищет таблицу дескрипторов сервисов и сообщает о ее обнаружении.
Что такое RVA?
Адрес смещения, позволяющий обнаружить SDT в памяти. Информация об адресах и RVA в протоколе AVZ является технической информацией, и какой-либо анализ этого адреса со стороны хелпера не требуется.
Что такое KiST?
Это сокращенное название так называемой KiServiceTable. Это таблица, входящая в структуру SDT и содержащая информацию обо всех функциях Native API ядра (самый важный элемент STD – таблица адресов функций). Для поиска адреса функции в KiST необходимо знать ее индекс в таблице. Единой системы нумерации не существует, и в различных версиях операционных систем нумерация своя. Документированной таблицы соответствия также не существует, поэтому для поиска соответствия между номерами функций и их индексами в таблице KiST антируткиты и вредоносные программы применяют различные недокументированные методики, большинство из которых основано на том, что эти номера жестко заданы в коде функций-переходников.
В общем случае упрощенная схема вызова функции на примере функции CreateFile показана на рисунке:
В данном случае приложение вызывает функцию CreateFile из библиотеки kernel32.dll; вызывается функция с суффиксом A – т.е. ANSI-вариант функции. В Windows XP, к примеру, он является переходником на функцию с суффиксом W (Unicode-вариант), а эта функция, в свою очередь, - не более чем переходник на статически импортируемую функцию NtCreateFile в ntdll.dll. Последняя опять же является переходником – в данном случае уже на код, обращающийся к ядру через sysenter. В ядре обработчик sysenter является по сути диспетчером – он определяет адрес функции по ее номеру и выполняет вызов функции (для этого как раз и требуется KiST, являющаяся таблицей соответствия). В нашем примере будет вызвана функция NtCreateFile ядра. Эта функция в свою очередь вызывает множество функций ядра, многие из которых не экспортируются и не документированы, но в конечном итоге произойдет обращение к драйверам файловой системы и собственно выполнение операции создания или открытия файла. Столь длинная цепочка вызовов и множество функций-переходников открывают массу путей для перехвата функций – перехват возможен на любом из указанных этапов.
Существенная разница между перехватами UserMode и KernelMode заключается в двух моментах:
Перехват в KernelMode оказывает глобальное воздействие на систему. Это не мешает перехватчику дифференцированно воздействовать на различные процессы (например, блокировать некие операции только антивирусам). Перехваты UserMode не оказывают влияние на работу KernelMode кода, и в UserMode влияют только на те процессы, в которые внедрен перехватчик. Последнее часто применяется на практике – например, руткит-шпион может внедриться только в процесс браузера, или, скажем, для маскировки процесса руткит может внедряться только в диспетчер задач.
Для установки перехватов к KernelMode вредоносная программа должна получить доступ в KernelMode, чаще всего для этого в составе вредоносной программы имеется один или несколько драйверов
Перехватчики ring3, как правило, несложно обнаружить, но так как обычно машинный код перехватчика внедряется в процессы, то можно установить факт перехвата, но невозможно установить, кто эти перехваты установил (исключения существуют – в простейшем случае код функций-перехватчиков размещается в DLL, подгружаемой в адресное пространство процессов – обнаружить такую DLL несложно, равно как несложно проследить за тем, что адреса перехватчиков ведут в эту библиотеку. AVZ выполняет данную проверку автоматически). Чаще всего перехват функций в ring3 осуществляется для следующих библиотек:
kernel32.dll
ntdll.dll
user32.dll
advapi32.dll
ws2_32.dll
wininet.dll
rasapi32.dll
urlmon.dll
netapi32.dll
Если рассмотреть возможные места и методы перехватов (см. рисунок выше), то можно выделить несколько основных:
Перехват в UserMode подменой адреса. Суть этого перехвата состоит в том, что для статически импортируемых функций у процесса имеется таблица статического импорта, содержащая адреса всех импортируемых функций. Эта таблица заполняется системным загрузчиком исполняемых файлов в момент их запуска, но впоследствии может быть изменена руткитом – ему достаточно просканировать таблицу и модифицировать ее. Для динамически импортируемых функций руткит, как правило, перехватывает статически импортируемую функцию GetProcAddress библиотеки kernel32.dll. Эта функция применяется приложениями для определения адресов функций по их именам в динамике – руткиту остается только выдать для интересующих его функций адреса перехватчиков вместо реальных адресов.
Перехват в UserMode модификацией машинного кода (т.н. слайсинг кода). Суть метода состоит в том, что руткит модифицирует машинный код интересующих его функций в памяти. В результате модификации кода при вызове функций управление получает код перехватчика. Важно отметить, что несложно обнаружить модификацию в начале машинного кода функции, но гораздо сложнее это сделать в случае, если модификация выполнена где-то в глубине кода функций или в коде неэкспортируемых функций библиотеки;
Перехват обработчика SYSENTER и INT2E. Как указывалось выше, данные обработчики по сути являются диспетчерами вызовов функций ядра, поэтому перехват позволяет руткиту контролировать все вызовы;
Перехват в KernelMode путем модификации адресов KiST. Это наиболее простой и распространенный метод перехвата, сводящийся к подмене адресов соответствующих функций в таблице KiST;
Перехват в KernelMode путем модификации машинного кода функций. Данный метод также достаточно популярен, причем можно выделить две разновидности данного метода – модификация кода в начале функции и модификации в глубине кода. Последние намного сложнее обнаружить; например, известны руткиты, модифицирующие машинный код неэкспортируемых функций ядра;
Модификация таблиц обработчиков IRP у драйверов и применение драйверов-фильтров. Данный метод часто применяется для блокировки доступа к файлам и маскировки файлов;
Модификация машинного кода драйверов;
Применение CallBack функций. Данный механизм является документированным методом отслеживания операций с реестром, запуска процессов и загрузки библиотек и драйверов. Устанавливая собственные CallBack функции, руткит может вмешаться в стандартную работу системы, что в частности позволяет заблокировать доступ к определенным ключам реестра или блокировать запуск заданных процессов;
DKOM руткиты. Руткиты данного типа не перехватывают функции и не модифицируют машинный код ядра. Вместо этого данный тип руткитов модифицирует данные ядра, что, в частности, позволяет маскировать запущенные процессы и загруженные драйверы.
Перехваты в UserMode и KernelMode имеют важную особенность. Диагностическая утилита, выполняющая поиск перехватов, получает информацию только о первом перехватчике, перехватывающем ту или иную функцию. На самом деле перехватчиков одной функции может быть несколько – в зависимости от порядка их установки в систему.
К примеру:
Функция NtOpenFile (74) перехвачена (8057D529->F752C000), перехватчик C:\WINDOWS\system32\Drivers\kl1.sys
Это запись из протокола исследования системы, где из перехватчиков системных событий имеется только Антивирус Касперского.
В протоколе исследования системы, где в дополнение к Kaspersky Internet Security установлена программа System Safety Monitor, та же запись выглядит по-другому:
Функция NtOpenFile (74) перехвачена (8056E254->F73E1C28), перехватчик C:\WINDOWS\system32\Drivers\safemon.sys
Однако это не значит, что kl1.sys не перехватывает более данную функцию. Образуется своего рода цепочка драйверов, и он по-прежнему контролирует ее, но не виден диагностическим средствам из-за safemon.sys. При восстановлении SSDT порядок драйверов значения не имеет, но при изучении лога не следует забывать об этой особенности перехватов KernelMode.
Другой особенностью, также показанной на рисунке, является возможность обхода некоторых перехватов. Например, работающая в ring-3 программа может установить собственный драйвер и обратиться к функциям ядра напрямую, обходя все перехваты ring-3 и некоторые типы перехватов ring-0. Эта особенность активно применяется в антируткитах – к примеру, можно составить список файлов или список процессов, пользуясь функциями различного уровня и затем сравнить полученные списки – расхождение укажет на маскируемые элементы. Похожим образом в AVZ реализован поиска маскирующихся процессов и драйверов – в процессе нейтрализации перехватов антируткит-модуль делает несколько «снимков» и сравнивает их друг с другом – появление отклонений указывает на факт маскировки. Однако возможны и ложные срабатывания, особенно на сервере, на котором идут фоновые процессы, сопряженные с запуском и завершением фоновых приложений – если некое приложение запустится в ходе работы антируткита, то он может посчитать, что этот процесс маскировался и стал видимым за счет снятия перехватов.
В силу тех или иных причин иногда AVZ не удается загрузить драйвер, получить от него данные или нейтрализовать перехваты. К примеру, при противодействии вредоносного ПО системе антируткита можно увидеть сообщение: