Смекни!
smekni.com

Рис.3 Модификация машинного кода прикладной программы

4.3 Модификация таблицы импорта

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

Рис. 4 Модификация таблицы импорта

4.4 Перехват функций LoadLibrary и GetProcAddress

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

Рис. 5 Перехват функций LoadLibrary и GetProcAddress

4.5 Метод, сочетающий методику 2 и 3

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

Рис. 6 Метод сочетающий Перехват функций LoadLibrary и GetProcAddress и модификацию таблицы импорта

4.6 Модификация программного кода API функции.

Данные метод сложнее в реализации, чем подмена адреса. Методика состоит в том, что RootKit находит в памяти машинный код интересующих его функций API и модифицирует его. При таком методе перехвата функции уже нет надобности в модификации таблицы импорта запущенных программ и передаче программам искаженных адресов при вызове GetProcAddress. С точки зрения вызова функции все остается «как есть» за одним исключением – теперь уже по «правильному» адресу внутри «правильной» DLL находится машинный код RootKit.

Рис.7. Модификация программного кода API функции.

Чаще всего вмешательство в машинный код перехватываемых функций минимально. В начале функции размещается не более 2-3 машинных команд, передающих управление основной функции-перехватчику. Для выполнения вызова модифицированных функций RootKit должен сохранить исходный машинный код для каждой модифицированной им функции (естественно, сохраняется не весь машинный код функции, а измененные при перехвате байты). Именно такая методика перехвата реализована в широко известном HackerDefender и библиотеке AFX Rootkit (www.rootkit.com).

4.7. Модификация библиотек DLL на диске

Данная методика состоит в том, что системная библиотека модифицируется на диске. Методы модификации аналогичны описанным выше, только изменения производятся не в памяти, а на диске. Подобная методика не получила широкого распространения.

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

Рис.8 Перехват функций в режиме ядра

Для понимание типовой для методики перехвата функций в режиме ядра следует рассмотреть принципы взаимодействия библиотек пользовательского режима и ядра. Рассмотрим это взаимодействие на упрощенной схеме:

Основное взаимодействие с ядром производится через ntdll.dll, большинство функций которой являются переходниками, обращающимся к ядру через прерывание INT 2Eh (следует заметить, что прикладной программе ничто не мешает напрямую вызывать INT 2Eh). Дальнейшее обращение к функциям ядра основана на структуре, именуемой KeServiceDescriptorTable (или сокращенно SDT), расположенной в ntoskrnl.exe. SDT – это таблица, содержащая адреса точек входа сервисов ядра NT. Описание функций и методик перехвата можно найти в книге Свена Шрайбера «Недокументированные возможности Windows 2000», там же приведена схема взаимодействия, послужившая прототипом для приведенной здесь схемы. Упрощенно можно сказать, что для перехвата функций необходимо написать драйвер, который произведет модификацию таблицы SDT. Перед модификацией драйверу необходимо сохранить адреса перехватываемых функций и записать в таблицу SDT адреса своих обработчиков. Данный метод чем-то напоминает перехват прерываний в MSDOS или описанную выше методику 2.

Этот метод часто называют перехватом Native API и естественно он работает только в NT (и соответственно W2K, XP, W2003). Следует отметить, что перехват Native API осуществляют не только руткиты – существует масса полезных программ, перехватывающих функции при помощи правки SDT – в качестве примера могут служить популярная утилита RegMon от SysInternals или программа Process Guard.

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

6 Rootkit-технологии для UNIX

Ситуация в UNIX очень напоминает ситуацию в мире Windows. Атакующий устанавливает rootkit на компьютер после того, как был получен привилегированный доступ — root. Права root, необходимые для инсталляции подавляющего большинства rootkit, можно получить с помощью использования известных уязвимостей, если злоумышленник имеет доступ в систему с правами обычного пользователя. В этом случае он может использовать локальный эксплойт или утилиты для взлома базы с паролями. Если злоумышленник не имеет соответствующих прав, то для проникновения в систему он может использовать удаленный эксплойт или, например, сниффер для перехвата паролей. Подобный перехват паролей возможен для целого ряда служб (ftp, telnet и др.) по причине того, что они осуществляют передачу паролей по сети в открытом виде.

В зависимости от предоставляемых возможностей rootkit может содержать различные вредоносные программы (Trojan-DDoS, Backdoor и прочие), которые устанавливаются на взломанный компьютер и ожидают команд от атакующего. Кроме того, rootkit могут содержать заплатки, которые закрывают уязвимости в защите системы с целью предотвращения повторного проникновения со стороны другого атакующего.

Также как и в Windows, в UNIX имеются и rootkit уровня приложений, и rootkit уровня ядра.

Рассмотрим уровень приложений. Как правило, подобные rootkit состоят из «троянизированных» версий обычных программ, скрывающих присутствие своих компонент в системе, и бэкдора, предоставляющего скрытый доступ в систему. Примерами rootkit уровня приложений являются lkr, trOn, ark и др.

Продемонстрируем работу rootkit уровня приложений на примере tr0n. Для сокрытия своего присутствия в системе данный rootkit выполняет целый ряд действий: в момент инсталляции он останавливает syslogd-демон, затем подменяет своими троянскими версиями следующие системные утилиты du, find, ifconfig, login, ls, netstat, ps, top, sz. Кроме того, в систему добавляется троянская версия sshd-демона. В завершение, в фоновом режиме запускается sniffer, в inetd.conf добавляется запуск telnetd-, rsh-, finger-демонов, перезапускается inetd и снова стартует syslogd.

Обычно tr0n располагается в /usr/src/.puta, но благодаря установленной ранее троянской версии утилиты ls, этот каталог невидим.

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

Существует несколько способов внедрения rootkit в ядро системы UNIX:

Использование LKM. Ядро linux, как и ядра многих других ОС, способны загружать модули (или драйверы устройств) «на лету», что позволяет злоумышленнику изменить системные вызовы ядра и тем самым выдавать некорректную информацию (например, исправленный список файлов). Использование подобного приема можно предотвратить, если скомпилировать монолитное ядро без поддержки LKM, но такое решение имеет существенный недостаток — необходимость включения в ядро всех нужных драйверов.

Запись в /dev/kmem, который предоставляет доступ к занятой ядром области памяти. Запись в /dev/kmem переписывает ядро «на лету». Таким образом, для изменения ядра необходимо лишь найти нужное место в памяти, но это решаемая проблема. Существует исправление, запрещающее записывать в /dev/kmem напрямую. Также это можно сделать через mmap.