Что такое rootkits, и как с ними бороться

СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Что такое rootkits, и как с ними бороться

На новый сервер установлен Linux последнего выпуска, убраны все лишние сервисы, firewall настроен так, что завидуют друзья. Теперь можно сидеть почитывать художественную литературу и попивать кофе. А вот и нет. Так может думать админ, который ни разу не пробовал свои силы во взломе своих систем.

К сожалению, находясь на курсах, заметил странную закономерность. Некоторые из присутствующих вслепую доверяли firewall, основываясь, как правило, на очень простом предположении, что если он отсеивает ненужную часть трафика, то взломщику просто нет путей для проникновения на компьютер. Да, действительно, firewall, действуя по классической схеме «свой-чужой», отсекает неугодные администратору пакеты. Но если, например, открыт 80 порт для доступа к веб-серверу, то и пакеты, направленные на такой порт, беспрепятственно пройдут через него и, естественно, следуя законам Мерфи, обязательно найдется уязвимость в таком «легальном» сервисе, не говоря уже, что сам firewall может стать объектом атаки. Дальше, как говорится, все это уже дело времени.

Чтобы иметь возможность и далее возвращаться во взломаную систему, при этом, чтобы сисадмин не мог их увидеть, а система их действия не регистрировала, нападающий устанавливает современный вариант троянского коня, набор утилит – rootkits. Обычно в этот набор входит sniffer, при помощи которого прослушивается сеть для возможного перехвата ценной информации (пароля, например), модифицированный набор основных системных программ (ps, ls, who, find, netstat, ifconfig ...), скрипты для чистки логов. Для дистанционного управления запускается нелегальный демон удаленного доступа, открывающий сетевой порт, который «не замечают» модифицированные утилиты. При этом, чтобы сохранить максимальное приближение к оригинальному файлу, трояненные утилиты имитируют ту же дату создания файла и размер.

Небольшая история развития rootkits

В начале 80-х все было скучно до безобразия. Команда last показывала, кто и когда хулиганил в системе, команды ls и ps выдавали новые файлы и неизвестные процессы, netstat сообщала текущие сетевые подключения и порты, на которых слушались входящие подключения, команда ifconfig сообщала администратору, если интерфейс локальной сети на основе протокола ethernet был установлен в «неопределенный» (PROMISCIOUS) режим, означающий работу программы-сниффера, следы его пребывания можно было также отыскать в /var/log/messages. Естественно, такое положение дел не устраивало взломщиков, и были придуманы методы, позволяющие скрыть их действия. Описание этих методов появились в некоторых электронных и печатных журналах, таких, как 2600 (http://www.2600.com/phrack) или Phrack (http://www.phrack.org). Например, статья «Hiding Out Under Unix» Black Tie Affair (25 номер, файл р25-06) описывает возможность, и приводится исходный код, позволяющий путем модификации файла /etc/wtmp скрыть свое пребывание в системе. И понеслось, через некоторое время появились программы, «умеющие» модифицировать свой timestamp и подгонять размер под требуемый. Теперь такие программы, содержащие троян, отличить от оригинальных очень было затруднительно, и сисадмин считал, что работает на чистой системе. Эти программы были объединены в единый комплект утилит, названный «Root Kits», исходно разработанные Lord Somer, сегодня находятся уже в шестой версии с несколькими вариантами. Версия 3 – Linux Root Kit 3 (lrk3) от декабря 1996 года содержала обычные методы перехвата паролей и сокрытия действий. Администратор, зная входящие в комплект файлы, мог вычислить зараженные путем просмотра в текстовом редакторе, сравнивая строки в файлах, кроме того, команда find могла сообщить обо всех измененных за 24 часа файлах. Следующая версия lrk4, выпущенная в ноябре 1998 года, получила еще несколько измененных программ (pidof, killall, find, top, crontab ...), позволяющих взять систему под больший контроль. Чтобы администратор системы не заметил изменений, они были защищены паролем (по умолчанию satori), который можно было заменить при компиляции. Но у rootkits такого класса есть один существенный недостаток, а именно они изменяют файлы на диске и поэтому могут быть обнаружены при сравнении контрольных сумм. Так что при ее контроле такой rootkit выявить труда не составляло. Но прогресс на месте не стоял, и был разработан новый класс rootkit, способных поражать ядро, использующих модули ядра (Linux Kernel Module – LKM). Номер 50 (от апреля 1997 года) журнала Phrack содержал краткую, но очень поучительную статью «Abuse of the Linux Kernel for Fun and Profit» (p50-05), после которой уже нельзя было полностью доверять своему ядру. Принцип работы такого rootkit прост.

Как известно, применение модулей ядра позволяет расширить возможности ядра операционной системы без необходимости его перекомпиляции. Злоумышленник пишет код модуля ядра и загружает его. В дальнейшем, работая в пространстве ядра, такой модуль перехватывает системные вызовы и модифицирует ответ по своему предназначению, скрывая таким образом взлом системы. Но теперь взломщик получает практически безграничную власть в системе. Он может без проблем фильтровать логи, прятать файлы и процессы, выходить за пределы chroot, скрывать состояние системы и многое другое, зависящее только от фантазии взломщика. Программы контроля целостности типа Tripwire бесполезны против этого класса rootkit. Боролись с этим злом на первом этапе, контролируя добавление и удаление модулей, ограничением круга пользователей (демонов), которые могли работать с модулями или вообще отказом от их использования (т.е. ответ N в опции CONFIG_MODULES) и собирая монолитное ядро. Некоторое время это как-то помогало, но Сильвио Цезаре (Silvio Cesare) обосновал возможность загрузки модуля в ядро, используя устройство /dev/kmem, управляющее памятью ядра, и написал программу kinsmod, позволяющую проделать это, хотя это все намного сложнее. Для информации загляните на его страницу http://www.big.net.au/~silvio, там до недавнего времени лежал файл runtime-kernel-kmem-patching.txt, но сейчас почему-то пропал или, например, целых три статьи в номере 58 (файлы р58-0х06, р58-0х07, р58-0х08) журнала Phrack «Sub proc_root Quando Sumus (Advances in Kernel Hacking)», «Linux on-the-fly kernel patching without LKM» и «IA32 ADVANCED FUNCTION HOOKING», и есть информация в следующих номерах журнала.

Были предложены несколько вариантов решений проблемы, например, по адресу http://www.cs.uni-potsdam.de/homepages/students/linuxer, можно найти вариант Себастьяна Крамера (Sebastian Krahmer), предлагающего контролировать и регистрировать вызов execve() и в комбинации с контролем логов пробовать отловить вторгшегося. Вот список типично изменяемых системных вызовов: sys_clone, sys_close, sys_execve, sys_fork, sys_ioctl, sys_kill, sys_mkdir, sys_read, sys_readdir, sys_write. Но до окончательной победы еще ой как далеко.

Как защититься от rootkits?

Так как rootkits – это программы, обеспечивающие беспроблемное существование взломщика, а не программы для взлома системы, то чтобы от них не избавляться, лучше их попросту не подцеплять. А посему настраиваем firewall, убираем все лишние сервисы, и вакцинируем систему, т.е. устанавливаем всевозможные патчи, обновляем ПО, убираем поддержку модулей ядра или хотя бы периодически проверяем загруженные при помощи lsmod (если еще доверяете этой утилите). При помощи специальных патчей к ядру вроде LIDS (http://www.lids.org) ограничиваем права root, лишая тем самым нападающего части преимуществ, а также защищаем исполняемые файлы, установив для них режим «только для чтения» – READONLY, чтобы никто не мог их заменить или удалить, а файлам журналов разрешить только дозапись данных APPEND, чтобы исключить возможность стирания данных. Запустив команду netstat -an, запоминаем все открытые порты на свежей системе, а заодно убеждаемся, что ничего не забыто. В дальнейшем необходимо для выяснения возможных различий производить сканирование при помощи внешнего чистого компьютера (испытуемому лучше не доверять). Используем, например, nmap.

# nmap -v -P0 -sU -sT -p 1-65535 IP_ADDRESS

Таким образом, проверим все TCP- и UDP-порты, хотя это и займет некоторое время.

Свежеустанавливаемый софт проверяем при помощи контрольной суммы md5sum (http://www.gnu.org/software/textutils/textutils.html). Те, кто пользуется rpm-based дистрибутивами, могут воспользоваться возможностями этого менеджера пакетов. Когда устанавливается новая программа, то данные о пакете в целом и отдельных файлах, его составляющих, в том числе и контрольная сумма, заносятся в базу данных. Поэтому, введя команду:

# rpm -Va > file

можно получить представление об измененных файлах. Если файл окажется пустой, то изменений нет, но, правда, это еще не подтверждает, что система чиста. Но вот если появятся подобные строки:

# rpm –Va

то измененные файлы необходимо проверить:

• M – отличается состояние (включая разрешения и тип файла).
• S – отличается размер файла.
• 5 – отличается сумма MD5 .
• D – не соответствует число основных/второстепенных устройств.
• L – не соответствует путь readLink(2).
• U – отличается пользователь-владелец.
• G – отличается группа-владелец.
• T – отличается mTime.

Чтобы не возиться со всей системой и немного упростить задачу, в первую очередь необходимо проверять пакеты net-tools, fileutils, util-linux, procps, psmisc, и findutils (командой rpm -V имя_пакета). Правда, в приведенном примере это все конфигурационные файлы, в которых, естественно, появились изменения по сравнению с оригиналом, а вот если будут попадаться файлы из каталогов, содержащих исполняемые файлы, то необходимо насторожиться. При помощи команды rpm -qf /path/to/file можно проверить, является ли данный файл частью пакета. Обнаруженное расхождение можно, естественно, предварительно сохранив измененные файлы для дальнейшего изучения, тут же восстановить.

# rpm -Uvh -force <имя_файла.rpm>

Программы проверки контроля целостности системы типа Tripwire (http://www.tripwire.org) или AIDE – Advanced Intrusion Detection Environment (http://www.cs.tut.fi/~rammer/aide.html) позволяют автоматизировать процесс подсчета контрольных сумм и выдачи результата сравнения. Но при их использовании желательно базу держать на отдельном носителе, тем самым также защищая ее от модификации. Также возможное заражение может подсказать непривычное поведение любимой утилиты, т.к. ее протрояненный вариант может иметь немного отличающиеся опции запуска.

И наконец специально обученная на нахождение rootkit утилита – chkrootkit (http://www.chkrootkit.org), которая выдаст предупреждение в случае, если на машине появится какой-либо известный ей rootkit. Обращаю еще раз внимание на слово «известный», так как ситуация в данном случае аналогична таковой с антивирусами, определяя с ходу уже зарегистрированный вирус, те могут пропустить что-то новенькое. Пакет состоит из нескольких утилит, выполняющих свою задачу. Так, утилита chkrootkit проверяет сигнатуры в следующих файлах: aliens, asp, bindshell, lkm, rexedcs, sniffer, wted, w55808, scalper, slapper, z2, amd, basename, biff, chfn, chsh, cron, date, du, dirname, echo, egrep, env, find, fingerd, gpm, grep, hdparm, su, ifconfig, inetd, inetdconf, init, identd, killall, ldsopreload, login, ls, lsof, mail, mingetty, netstat, named, passwd, pidof, pop2, pop3, ps, pstree, rpcinfo, rlogind, rshd, slogin, sendmail, sshd, syslogd, tar, tcpd, tcpdump, top, telnetd, timed, traceroute, vdir, w, write. И на момент моего последнего посещения обнаруживала 51 известных типа rootkit и тестировалась на Linux, FreeBSD, OpenBSD, NetBSD, Solaris, HP-UX 11, True64 и BSDI. Установка заключается в выполнении команды make sense, компиляция обычно проходит без проблем. И далее запускаем:

# ./chkrootkit

и так далее.

Утилита имеет три, на мой взгляд, заслуживающих ключа работы. Если хотите проверить систему, загрузившись с другого компьютера или при помощи LiveCD, то при помощи ключа -r можно указать каталог, который будет использован как корневой при поиске.

# ./chkrootkit -r /mnt/test

Так как chkrootkit использует для своей работы некоторые типичные UNIX-утилиты (awk, cut, egrep, find,head, id, ls, netstat, ps, strings, sed, uname), которые могут быть компрометированы, то во избежание ошибки при поиске необходимо использовать статически скомпилированные версии этих утилит (опять же сохранив их где-нибудь подальше), а каталог, где они находятся, указать при помощи ключа -p:

# ./chkrootkit -p /mnt/safebin

Для исследования подозрительных строк в двоичных файлах можно ее запустить в опытном режиме, использовав ключ -х:

# ./chkrootkit -x | more

Утилита ifpromisc позволяет определить, находится ли сетевой интерфейс в PROMISCIOUS-режиме.

#./ ifpromisc

За обнаружения троянов в модулях ядра отвечают утилиты chkproc и chkdirs. Утилиты chklastlog, chkwtmp и check_wtmpx проверяют удаление данных в лог-файлах, strings обеспечивает работу со строками. И еще на сайте утилиты имеется большое количество ссылок на материалы по теме статьи.

Команда find (если ей можно доверять) может обнаружить файлы и каталоги, чьи имена начинаются с точки (или с пробела с точкой), которые обычно используют взломщики для хранения своих данных.

# find /  -name "*.*"

Утилита rkdet (http://vancouver-webpages.com/rkdet) представляет собой демон, который обнаруживает попытку установки rootkit или сниффера. При обнаружении такой попытки системному администратору посылается уведомление по e-mail, протоколирует его в logfile, может отключить систему от сети или вовсе остановить ее. Не требует перекомпиляции вместе с ядром.

Единственный путь обнаружения LKM rootkit – это анализ системной памяти. Один из способов состоит в сравнении адреса системного вызова, который rootkit изменяют на свой.

При помощи утилиты кstat, ссылку на которую можно найти на http://s0ftpj.org/en/site.html, можно исследовать /dev/kmem. Для установки понадобится наличие исходных текстов ядра и при компиляции нового ядра утилиту необходимо обязательно пересобрать.

При помощи ключа -Р можно просмотреть полный список процессов, включая спрятанные LKM (при иследовании проблемы, для интереса сравните с ps aux), получить подробную информацию о процессе можно, воспользовавшись ключом -р с указанием pid.

# kstat –p 270

Для вывода таблицы адресов системного вызова используйте флаг -s:

# kstat –s 

и так далее.

И теперь, периодически сравнивая полученные значения, можно проверять наличие данного вида rootkit в системе. И если на выходе получим что-то похожее на:

то стоит немного призадуматься над тем, что творится в системе.

Второй проект Стефана Ауберта (Stephane Aubert) Rkscan (http://www.hsc.fr/ressources/outils/rkscan/download) предлагает инструмент для автоматического определения наличия очень популярных LKM rootkit Adore (http://spider.scorpions.net/~stealth) и knark (http://packetstrom.securify.com). Здесь все просто: скачиваем, распаковываем, компилируем.

# gcc -o rkscan rkscan1.0.c

И запускаем под обычным пользователем, потому что под root программа ругается и работать не хочет.

$ ./rkscan

И конечно же, врага надо знать в лицо, поэтому, чтобы знать, чего можно действительно ожидать от того или иного rootkit, можно только при очень детальном их исследовании. Вы можете скачать и попробовать различные rootkit в действии (только в учебных целях!) с сайта packetstorm (http://packetstorm.decepticons.org/UNIX/penetration/rootkits).

Вот в принципе и все, что хотелось рассказать сегодня. Вывод один – админ должен быть немного параноиком, потому что нападающий всегда идет на шаг впереди. Успехов.

Комментарии могут оставлять только зарегистрированные пользователи