Описание методов работы руткитов в UNIX. В предыдущее статье я попытался рассказать об основных методиках стелсирования в Windows. Теперь пришло время для нисов. Хочу повториться и сказать, что статья рассчитана на обычных пользователей, а не на системщиков, поэтому не стоит рассчитывать на рассказ о принципиально новых способах невидимости, т.к. вся информация взята из различных публичных источников. Также статья не претендует описание всех существующих методах стелсирования. Разнообразие является и преимуществом, и недостатком UNIX’а. Поэтому методы работы руткитов меняются для каждой системы. Не смотря на большие различия никсов и NT, некоторые принципы стелсирования очень схожи. Начнем с того, что существуют ядерные (kernel) и неядерные (non-kernel) руткиты. Вторые от первых отличаются тем, что никаким образом не изменяют ядро. Итак, начнем. Первый способ остаться незамеченным – заменить системные утилиты (ls, ps, dir, netstat). Как известно, вся работа в UNIX’е строиться на маленьких программах, предназначенных для решения только одной задачи. Заменив эти программы на свои, мы сможем контролировать их. Преемущество данного способа – способность работы в разных системах и простота в реализации. Конечно, любая защитная программа сразу же нас засекет. Итог: простой, но ненадежный способ остаться невидимым. Следующий прием – подмена библиотеки. Прикладные программы редко обращаются к ядру напрямую, а используют системно-независимую библиотеку libc.so.x (x – номер версии). Следовательно, создав фейковую библиотеку, можно перехватывать и контролировать системные вызовы. Из недостатков выделяются сложность написания, ведь библиотека содержит туеву хучу всяких функций, а любые недоработки способны обрушить ось. Вывод: очень ненадежный способ. Модификация таблицы смешений. Таблица смещений в UNIX – аналог таблицы импорта в Windows. Меняя адреса функций, можно заменять их на обработчики, способные фильтровать выводимые данные. Главным недостатком такого метода является необходимость запуска процесса под режимом отладки. Противостоять ptrace( библиотека отладки) несложно, поэтому не во всех процессах руткит сможет установить перехват. Итог: Простой, надежный, но не лишенный недостатков способ. Можно сказать, что на прикладном уровне очень мало шансов выжить руткиту. Его легко обнаружить. А, обнаружив, можно вычислить хакера. Поэтому большинство современных руткитов спускаются на уровень ядра. О том, как они это делают, пойдет речь ниже. Автору известно два способа повлиять на работу ядра. Первый – загрузка нового или замена уже существующего модуля (Loadable Kernel Module или LKM). Второй – модификация псевдоустройств /dev/mem (образ физической памяти), /dev/kmem (Образ виртуальной памяти). Рассмотрим их поподробнее. LKM – аналог драйверов винды, но в отличии от дров написать их намного легче. Правда от системы к системе и от версии к версии структура LKM меняется. Так, например, LKM, написанный для Linux’а с ядром 2.6, отличается от такого же модуля, только заточенного для ядра с версией 2.4. Также нам придется позаботится о сокрытии нового модуля. Нужно найти адрес структуры module info, и затереть его. Ядро не отображает модули без имени и референсов. Беда в том, что адрес module info меняется от ядра к ядру. Чтобы не мучиться с поиском адреса можно просто затроянить уже существующий модуль и надеяться, что администратор этого не заметит. Бывает так, что загрузить модуль в систему не получается (допустим, в ядре отключена поддержка LKM). Тогда нам придется модифицировать ядро в памяти. Как и любое другое устройство оперативная память монтируется на файловую систему. Это псевдоустройства /dev/mem (физическая память до виртуальной трансляции) и /dev/kmem (после виртуальной трансляции). /dev/kmem доступен только с уровня ядра, поэтому лучше изменять /dev/mem, доступный root’у. Теперь рассмотрим, как скрыться от бдительных глаз админа в ядре. Для осуществления стелсирования в UNIX используются перехват системных вызовов (syscall). Для того, чтобы скрыть файлы и процессы нужно перехватить getdents. Также можно замаскировать сетевые соединения и свой LKM-модуль. Указатели на системные вызовы лежат в переменной sys_call_table, которую экспортирует ядро. Главный недостаток данного способа – раскладка системных вызовов меняется от ядра к ядру. По этому методу работают большинство современных руткитов. На этом я заканчиваю обзор методов работы руткитов. Хочу добавить, что для любого существующего руткита есть методики выявления. Как говориться «На каждое действие есть противодействие». Но, написав свой руткит, либо основательно модифицировав уже существующий, все защиты пойдут лесом. P.S. Статья предназначена для понимания работы операционной системы. За незаконное применение данного материала автор ответственности не несет.
Статья неплохая, только меня смутила фраза, о том, что программы в никсах являютс однозадачными. Они не могут быть такими, т. к. существует множество специальных опций, позволяющих им выполнять различные задачи. Кроме того, странным я нахожу утверждение о том, что для любого существующего руткита есть противодействие - это справедливо только для тех руткитов, которые выпадают в паблик. В этом я согласен - такой руткит можно выявить при анализ одной двумя спец. прогами (rkhunter, etc...). Лично от себя прошу автора дать практический пример внедрения ядерного руткита, либо подмены библиотеки.
баян. а во вторых как ты в 2.6 в узнаешь адрес таблицы системных вызовов, если он ядром не экспортируется? То, что статья ориентирована на новичков(как ты пишешь), не освобождает от ответственености за незнание принципов функционирования Linux. ps. Что тут можно незаконно применить? Автор ничего не написал
