Дмитрий Пукаленко
No Bunkum #1
Ноябрь 2009
Скачать PDF (478.21Kb) (Вы должны быть зарегистрированы на форуме)Механизмы функционирования руткитов для Linux - интересная и мало освещенная тема. Rootkit-технологии используются для таких задач, как сокрытие действий атакующего, подмена выдачи браузера, прозрачное проксирование, балансировка нагрузки, защита системы от атак.
Традиционно руткиты подразделяются на два больших класса: руткиты, работающие в пространстве пользователя (user-mode) и руткиты уровня ядра (kernel-mode). В данной статье я рассматриваю основные методы и нюансы реализации руткитов обоих типов.
Руткиты, работающие непосредственно в пространстве пользователя, стары как мир. Большинство из них функционируют за счет модификации утилит администрирования (ls, cat, ps, top, netstat и др.), обеспечивающей фильтрацию их вывода и сокрытие заданных файлов, настроек, сетевых подключений и другой системной информации. Ярким примером такого руткита является shv.
Подход, основанный на модификации исполняемых файлов, несет в себе массу недостатков. Во-первых, он не универсален: для обнаружения скрытых объектов достаточно воспользоваться утилитой, не входящей в стандартный набор администратора - например, просмотреть содержимое каталога в Midnight Commander. Во-вторых, все современные IDS (например, Tripwire) периодически сверяют целостность бинарных файлов по размеру и контрольной сумме. Как следствие описанных недостатков, данный подход неприменим в современных системах. Рассмотрим его альтернативы.
Система Linux предоставляет программисту широкие возможности для отладки приложений с помощью системного вызова ptrace(). Этот syscall позволяет получить практически полный контроль над сторонним процессом. Он имеет следующий прототип:
Первый параметр - команда отладчика, и назначение параметров addr и data меняется в зависимости от него. Для реализации руткита используются команды PTRACE_ATTACH, PTRACE_DETACH, PTRACE_GETREGS, PTRACE_SYSCALL, PTRACE_SETREGS, PTRACE_PEEKDATA, PTRACE_POKEDATA.
Рассмотрим вкратце логику работы руткита, основанного не перехвате ptrace().
В момент отладочного брейка процесс находится непосредственно перед выполнением системного вызова. При этом номер системного вызова находится в регистре eax - regs.orig_eax, а в regs.ebx, regs.ecx, regs.edx, regs.edi, regs.esi находятся остальные параметры. Для получения значений регистров вызываем ptrace с параметром PTRACE_GETREGS. При этом в параметр data загружается адрес структуры user_regs_struct, хранящейся в <sys/user.h>.
Как фильтровать системные вызовы? Для сокрытия процессов и файлов необходимо обрабатывать те вызовы, в которых значение regs.orig_eax соответствует константе __NR_getdents (__NR_getdents64). Для подмены содержимого файлов - __NR_read, __NR_write, и т.д. Полный список системных вызовов доступен в <asm/unistd.h>. Контроль всех сетевых вызовов на 32-битной архитектуре обеспечивается перехватом единственного системного вызова __NR_socketcall, при этом номер конкретной функции находится в regs.ebx (полный список номеров функций находится в <linux/net.h>). На 64-битных архитектурах за каждую сетевую процедуру отвечает отдельный системный вызов.
Если перехваченный вызов нам интересен, можно приступить к анализу аргументов. Вызываем ptrace с параметром PTRACE_PEEKDATA. При этом в параметре addr должен находиться реальный адрес в пространстве отлаживаемого процесса. Функция вернет 32-битное число (на 32-битных архитектурах), поэтому для получения полного содержимого анализируемого параметра нужно повторять в цикле процедуру вызова функции ptrace(..PTRACE_PEEKDATA..), постепенно увеличивая addr, необходимое число раз или до достижения нулевого байта, если речь идет о строке. После анализа и совершения необходимых приготовлений (например, сохранения адресов параметров и т.п.), можно переходить к следующему пункту.
Далее - анализ и изменение параметров. Модификация памяти процесса выполняется с помощью PTRACE_POKEDATA, при этом в качестве параметра addr указывается адрес в пространстве процесса, в качестве параметра data - значение (обратите внимание: значение, а не адрес!) для записи по данному адресу. Постепенно инкрементируя addr, запишем необходимые данные в пространство процесса.
Это базовый алгоритм ptrace-руткита, не учитывающий нюансов реализации. Рассмотрим основные проблемы и подводные камни, возникающие в процессе разработки.
Выделение памяти в адресном пространстве чужих процессов. Для этого можно применить грязный хак, заключающийся в следующем. На этапе инициализации процесс часто совершает системный вызов mmap2() для постраничного выделения памяти и munmap - для освобождения. Перехватив mmap2, можно модифицировать параметр, хранящийся в regs.edx: добавить туда PROT_WRITE|PROT_EXEC, и при необходимости увеличить размер запрашиваемой памяти. Когда же процесс вызовет munmap - можно модифицировать второй параметр вызова, выставив его равным 0, или даже подменить регистры так, чтобы была вызвана функция brk(), что приведет к выделению дополнительной памяти. Теперь у нас есть блок памяти в адресном пространстве процесса, который можно использовать для своих нужд.
Выполнение произвольного кода в контексте процесса. Для этого можно скопировать необходимый код в память процесса, полученную вышеописанным методом, сохранить контекст текущего процесса (при помощи PTRACE_PEEKUSER и PTRACE_POKEUSER, см. <sys/user.h>), изменить eip и исполнить записанный код пошагово, с помощью параметра PTRACE_SINGLESTEP, после чего восстановить сохраненный контекст.
Есть еще один интересный момент, связанный с сокрытием объектов в системе. Если администратор системы, в которой установлен руткит, попытается отладить какую-либо программу с помощью gdb или просто протрассировать ее при помощи strace, он получит -EPERM (Operation not permitted), что выдаст присутствие руткита. Для предотвращения такой возможности можно перехватывать сам системный вызов ptrace, делать PTRACE_DETACH, и помещать pid отлаживаемого процесса и pid отладчика в очередь до тех пор, пока отладчик повторно не вызовет ptrace с параметром PTRACE_DETACH. После чего можно снова присоединяться к процессу и продолжать контролировать его выполнение.
Переменная окружения LD_PRELOAD позволяет подгрузить свою библиотеку и подменить адреса библиотечных процедур, используемых в программе. Данную особенность системы также можно использовать с целью сокрытия тех или иных объектов. Недостаток этого метода в том, что перехватываются библиотечные функции, используемые программой, поэтому он узко специфичен. Но есть плюсы - например, перехватив SSL_read и SSL_write, можно читать и модифицировать незашифрованный трафик в обход SSL-шифрования!
Для использования данного метода переопределим в нашей .so библиотеке те функции, которые необходимо перехватывать, и обеспечим вызов оригинальной функции посредством ее динамической подгрузки из настоящей библиотеки с помощью dlopen/dlsym. Скомпилировав библиотеку, пропишем ее отдельной строкой в /etc/ld.so.preload, в результате чего все запускаемые впоследствии процессы будут работать с переопределенной функцией.
Что делать, если программа получает адреса функций динамически? В таком случае можно перехватывать вызовы dlopen и dlsym, и при совпадении параметров dlsym с перехватываемой функцией указывать адрес подставной процедуры.
Поскольку практически все программы используют функцию readdir для чтения элементов директории, ничто не мешает скрывать файлы и процессы, равно как и сам файл /etc/ld.so.preload.
User-mode руткиты обладают существенным недостатком: их очень легко обнаружить из режима ядра. При этом работа руткита в режиме ядра, напротив, предоставляет неограниченные возможности для манипуляции системой и оборудованием.
Самый распространенный метод, обеспечивающий функционирование руткита уровня ядра - это перехват системных вызовов путем подмены соответствующей записи в таблице системных вызовов sys_call_table. Детали этого метода заключаются в следующем. При обработке прерывания int 0x80 (или инструкции sysenter) управление передается обработчику системных вызовов, который после предварительных процедур передает управление на адрес, записанный по смещению %eax в sys_call_table. Таким образом, подменив адрес в таблице, мы получаем контроль над системным вызовом. Этот метод имеет свои недостатки: в частности, он легко детектируется антируткитами; таблица вызовов в современных ядрах не экспортируется; и кроме того, перехват некоторых системных вызовов (например, execve()) нетривиален.
Другим распространенным механизмом в kernel-mode руткитах является патчинг VFS (Virtual Filesystem Switch). Этот подход применяется в рутките adore-ng. Он основан на подмене адреса какой-либо из функций-обработчиков для текущей файловой системы.
Как и в Windows, широко используется сплайсинг - замена первых байтов кода системного вызова на инструкцию jmp, осуществляющую переход на адрес обработчика руткита. В коде перехвата обеспечивается выполнение проверок, возврат байтов, вызов оригинального кода системного вызова и повторная установка перехвата. Данный метод также легко детектируется.
Еще один метод - подмена самого обработчика прерываний в IDT.
Рассмотрим некоторые методы реализации kernel-mode руткита более подробно.
Краеугольный камень этого метода - поиск адреса таблицы системных вызовов sys_call_table. Как уже упоминалось выше, в ядрах версии 2.6 таблица не экспортируется.
Первый способ решения этой проблемы - поиск таблицы в /proc/kallsyms.
Если администратор системы отключил kallsyms, то этот метод не сработает.
Существует также метод, основанный на поиске известного нам адреса sys_close там, где, предположительно, может находиться таблица. [1]
Этот метод не дает стопроцентной гарантии обнаружения таблицы системных вызовов.
Зная, что реализация обработчика системных вызовов не менялась уже давно, мы можем использовать следующий алгоритм:
Код должен получиться примерно таким: [2]
Этот код ориентирован на работу с памятью ядра из адресного пространства пользователя, однако может быть легко модифицирован для работы в режиме ядра. На сегодняшний день он является самым универсальным и надежным методом поиска таблицы системных вызовов.
Еще одна проблема метода перехвата системных вызовов заключается в невозможности перехватить execve() для контроля над создаваемыми процессами. Для ее решения можно использовать грязный хак: поиск свободного слота в sys_call_table, запись туда старого адреса execve(), перехват, и последующие вызовы через int 0x80.
Антируткиты, основанные на контроле целостности таблицы, обходятся простым поиском в пространстве ядра сохраненной копии таблицы и последующим ее изменением.
Возможность загрузки дополнительных модулей в ядро может быть отключена при его сборке. В таких случаях используется патчинг ядра "на лету", подробно описанный в статье Phrack #58, Linux on-the-fly kernel patching without LKM[3]. Рассмотрим здесь основные принципы этого метода.
Во-первых, производится поиск таблицы системных вызовов. После этого необходимо найти адрес kmalloc для выделения памяти в пространстве ядра. Лучше всего это сделать через kmalloc, но в крайнем случае можно воспользоваться ненадежным методом брутфорса, основанным на поиске самой часто вызываемой функции со вторым параметром GFP_KERNEL. Для примера приведен код из статьи[3], модифицированный для ядер 2.6.х:
При использовании этого кода следует учитывать, что значение GFP_KERNEL различно в разных версиях ядра.
После определения адресов можно временно заменить какой-либо системный вызов (например, olduname()) своим кодом с прошитым в нем адресом kmalloc для выделения необходимой памяти, в которую впоследствии будет скопирован код новых системных вызовов. После успешного выполнения этой процедуры и копирования кода новых системных вызовов в ядро производится подмена значений в sys_call_table в соответствии со стандартным алгоритмом.
В этой статье рассмотрены основные технологии, применяемые в современных ring3 и ring0 руткитах для Linux. Некоторые методы остались за пределами статьи: например, патчинг VFS и смена обработчика прерываний - о них будет рассказано в следующей статье.