Инструментальные средства обеспечения безопасности

       

Execve_Sniffer


Этот инструмент еще не выпущен публично; его дебют состоится в этой книге. Написанный Кейтом Джонсом (Keith J. Jones) инструмент execve_sniffer в большей степени является программой "доказательства-концепции", чем инструментом, "пригодным для часа пик", но его можно изменить так, чтобы удовлетворить определенные потребности. Инструмент execve_sniffer загружается как модуль ядра. Он "обертывает" системный вызов execve. После того как системный вызов запакован, все запросы к этой функции будут полностью зарегистрированы в виде сообщений ядра.

Чтобы понять, почему это действие важно, вы должны понять системный вызов execve. Каждый раз, когда в системе выполняется команда, командная строка передается в системный вызов execve для выполнения. Когда мы обертываем этот системный вызов, то можем сделать с информацией, которая передается в этот вызов, что захотим (подобно тому, что делает инструмент Knark, описанный в лекции "Черный ход и средства удаленного доступа"). Поскольку мы ребята хорошие, то хотим лишь сообщать о том, какая команда была выполнена, а затем передавать саму команду оригинальному системному вызову execve.

Вся эта работа может показаться неважной, если вы можете поместить в сеть анализатор сетевых потоков (sniffer) и видеть ту же самую информацию, но этот инструмент был разработан в ответ на все увеличивающееся использование Secure Shell (SSH) для шифрования связи. Поэтому запись каждой команды, выполненной в системе, может быть единственной возможностью справиться с шифрованием. Кроме того, мы рекомендуем после установления execve_sniffer скрыть его с помощью инструмента modhide.o, имеющегося в Knark, чтобы преступник его не обнаружил и не попытался выгрузить.

Следующий текст дает пример вывода инструмента execve_sniffer из системы RedHat v6.2 Linux.

Execve Sniffer Inserted execve - user: 0 pid: 769 filename: /sbin/lsmod args: lsmod execve - user: 0 pid: 770 filename: /usr/bin/w args: w execve - user: 0 pid: 771 filename: /usr/sbin/tcpdump args: tcpdump -s 65535 -n -w /tmp/.net execve - user: 0 pid: 772 filename: /bin/dmesg args: dmesg

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

Пример из жизни. Сценарий взлома системы Unix

В этом примере мы анализируем систему RedHat v6.2 Linux. На хосте установлена стандартная система RedHat без ненужных служб, которые были заблокированы и удалены.

Взломщик получил доступ через службу rpc.statd, которая распространялась несколько лет назад. Как только взломщик получил доступ в систему, он добавил новых пользователей так, чтобы он мог воспользоваться утилитой telnet в любое время, когда захочет. Этот метод взлома оставляет "отпечатки пальцев" в живом ответе, который мы здесь выполним.

Системный администратор вошел в систему утром и заметил, что файл дневных сообщений (файл /etc/motd) был изменен, и содержит следующее:

"Ваш сайт парализован. Я взломал его. Я планирую удалить файлы, если вы не заплатите мне $4000. Это не шутка. Я крутой парень! Your momma wears combat boots! Подписано, Владимир Дорохов"

Администратор, конечно, покачал головой, решив, что слишком ретивый ребенок решил позабавиться с его системой.

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

Примеры, представленные в этой лекции были зафиксированы при использовании данной машины-жертвы. Вернитесь к этим примерам, чтобы освежить в памяти результаты, которые мы получили.

lsof. С помощью команды lsof обнаруживаются два подозрительных процесса: процесс 1, который записывает в файл и открыл "сырой" сокет, и процессы inetd, которые открыли TCP-порт 4375. После дальнейшего анализа файла inetd.conf мы видим, что демон открыл TCP-порт, который связан с привилегированной оболочкой (root shell). Короче говоря, это обеспечивает приглашение к вводу команд, которое не нуждается ни в каких мандатах для входа в систему с привилегированным доступом (поэтому они не обнаруживаются в выводе команд last или w). Для такого входа в систему никогда не должно быть никаких законных причин. Ниже приведена строка из файла inetd.conf:

4375 stream tcp nowait root /bin/sh -h

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

last. Команда last дает нам последнюю ключевую часть информации, потому что мы никогда не видели вход в систему пользователя с именем kjohnson (kjohnson был владельцем процесса 1 и изменил файл /etc/motd). Если файлы регистрации не были изменены, то мы можем предположить, что учетная запись пользователя mpepe использовалась, как черный ход в систему, после того как она была взломана, и пользователь был переключен на kjohnson с помощью команды su.

<

Содержание раздела