From: Saint_I
Newsgroups: http://www.securitylab.ru/
Date: Mon, 20 Sep 2004 18:21:07 +0000 (UTC)
Subject: Анализ инцидента на работающей Linux системе
Оригинал: http://www.securitylab.ru/44339.html
Анализ инцидента на работающей Linux системе. Часть первая
Мариус Бурдах, перевод Saint_I
Введение
Во время расследования инцидента мы часто сталкиваемся с ситуацией,
когда пользователь или администратор скомпрометированной системы не
выключил питание компьютера. В этом случае мы можем получить доступ к
ценной информации, которая будет утеряна при выключении компьютера.
Речь идет о запущенных процессах, открытых TCP/UDP портах, образах
удаленных программ, которые всё ещё находятся в основной памяти,
содержимом буферов, очередях запросов на соединение, установленных
соединениях и модулях, загруженных в зарезервированную часть
виртуальной памяти ядра ОС Linux. Вся эта информация может помочь
исследователю в расследовании инцидента. Кроме того, если инцидент
произошел сравнительно недавно, возможно восстановить практически всю
информацию о данных используемых взломщиком и о предпринятых им
действиях.
Иногда описанные здесь процедуры - единственный способ получения
данных, так как определённые типы злонамеренного кода, такие - как LKM
руткиты, загружаются только в память и не вносят никаких изменений в
файлы или каталоги. Подобная ситуация существует в операционной
системе Windows, например, червь Witty, код которого нигде не
сохраняется в виде файла, но тем не менее этот червь заразил систему и
выполнил произвольный код в памяти системы.
С другой стороны методы, представленные ниже, также имеют серьёзные
ограничения и нарушают первоначальные требования сбора процедур для
цифрового исследования - требования, которые не могут быть легко
выполнены. Например, утилита, предназначенная для сбора информации
пространства ядра, полученного в результате изменений состояния
целевой системы. Запуская любую утилиту на работающей системе, мы
загружаем её в память и создаём минимум один процесс, который может
перезаписать возможную улику. Создавая новый процесс, система
управления памятью операционной системы размещает данные в основной
памяти и тем самым может переписать другие, не освобождённые данные из
основной памяти или на swap разделе.
Также проблемы возникают, когда мы планируем действовать в рамках
законодательства. Подписи взломщика, найденные в образах основной
памяти не могут быть доверенным источником, так как могут быть созданы
с помощью утилит. Итак, до того, как предпринять какие-либо действия,
мы должны решить, необходимо ли извлекать данные с работающей
скомпрометированной системы или нет. Зачастую сбор информации не стоит
затраченного времени. В основной памяти мы можем найти пароли или
зашифрованные файлы. Используя файловую систему /proc мы можем так же
восстановить программы, которые были удалены, но всё ещё расположены в
памяти.
В идеале я мог бы себе представить тип аппаратно-ориентированного
решения для Intel компьютеров, которое бы позволяло нам полную
выгрузку памяти на внешний носитель без какой-либо помощи операционной
системы. Подобное решение существует на компьютерах Sparc, посредством
чего мы можем полностью выгрузить физическую память, используя OpenBot
firmware. К сожалению, подобного решения не существует для Intel или
AMD компьютеров.
Несмотря на все вышеперечисленные проблемы, программные методы могут
помочь в расследовании инцидентов, и я попытаюсь описать их в данной
статье. Основная цель этой статьи - демонстрация методов, которые
используются во время проведения процедуры сбора улик. Вся собранная
информация может быть использована для проведения, в последующем,
анализа.
Анализ инцидента
Эта статья состоит из четырех частей:
* 2.1 Анализ окружения
* 2.2 Подготовка инструментов для анализа инцидента
* 2.3 Сбор информации о системе (пошаговые процедуры)
* 2.4 Анализ собранных данных
В этой статье будут рассмотрены пункты 2.1, 2.2 и частично пункт 2.3
Анализ окружения
До сбора информации с работающей системы следует провести анализ
окружения. Сначала мы должны запустить сетевой сниффер и
проанализировать сетевой трафик, проходящий через скомпрометированную
систему. Это обязательное условие. Некоторые типы злонамеренной
активности можно обнаружить только путём записи и анализа сетевого
трафика в реальном времени. Утилита tcpdump - превосходная утилита для
этой цели. Мой совет - сохранять пакеты в raw формате, в противном
случае могут возникнуть некоторые проблемы, связанные со спецификой
настройки.
До того, как начинать какие-либо действия на скомпрометированной
системе, мы должны задокументировать процесс сбора информации на
бумаге. Эта процедура поможет нам избежать случайных ошибок во время
проведения анализа. Необходимо сделать дополнительные записи после
каждого выполненного шага на тот случай, если дело будет передано в
суд.
Далее необходимо записать результаты выполнения команд во время фазы
сбора информации. Затем мы подключаемся к определённому хосту в нашей
локальной сети, на который мы будет отсылать информацию со
скомпрометированной системы. Запись информации на скомпрометированной
системе может удалить следы взлома. Для того, чтобы было как можно
меньше конфликтов на скомпрометированной системе мы должны отправить
всю возможноую информацию на удалённый хост. Это одно из важнейших
правил в процессе анализа инцидента. И как было сказано ранее - это
требование не так уж легко выполнить.
Если у нас нет набора утилит, доступных для установки на съемные
носитель, настало время подготовить его для нашей скомпрометированной
системы. Используя инструменты из этого набора, мы будем собирать всю
важную информацию, начиная с наиболее нестабильных данных, заканчивая
наименее нестабильными. Далее будет описан способ подготовки внешнего
носителя, содержащего необходимый набор инструментов.
Подготовка инструментов для анализа инцидента
Важно помнить, что во время сбора информации мы должны следовать
следующим принципам:
* не запускать приложения на скомпрометированной системе. Почему?
Взломщик мог модифицировать системные команды (такие как netstat)
или системные библиотеки (такие как libproc), в результате
полученная информация может быть недостоверной.
* не запускать программы, которые могут модифицировать метаданные
файлов или директории.
* все результаты исследования должны быть сохранены на удаленной
машине. Для переноса данных будем использовать утилиту netcat.
* Следует использовать утилиты для подсчёта значений хэша цифровых
данных. Это своего рода гарантия, что цифровые данные не были
изменены. Нам необходимо удостовериться, что данные не изменены и
надежно сохранены на удалённом хосте, поэтому мы так же сравним
подсчитанные хэш значения ресурса и места назначения. Иногда
невозможно подсчитать значение хэша на скомпрометированном хосте.
Например, когда мы пытаемся использовать md5sum на /dev/mem
устройстве два раза подряд, каждый раз значение будет разным. Это
происходит потому, что каждый раз, когда мы загружаем программу в
память (и соответственно создаём новый процесс, который использует
для работы память) мы меняем значение памяти. Для расчета хэшей мы
будем использовать утилиту md5sum.
* В некоторых случаях мы не сможем предотвратить запись информации в
память или swap скомпрометированной системы. Более подробно мы
рассмотрим этот случай в части 2.3. В результате мы будем
использовать следующий набор инструментов для расследования
инцидентов, представленный в Таблице 1.
Таблица 1: Набор инструментов для расследования инцидента.
1. nc (http://www.securitylab.ru/tools/30717.html)
Как собрать: $tar zxvf nc110.tgz; make linux
Как проверить: file nc or ldd nc
2. dd (http://www.gnu.org/software/fileutils/fileutils.html)
(добавлено в утилиты ядра)
3. datecat (http://www.gnu.org/software/coreutils/)
Как собрать: $ tar zxvf coreutils-5.0.tar.gz; configure CC="gcc -static", make
Как проверить: file date cat or ldd date cat
4. pcat (http://www.porcupine.org/forensics/tct)
Как собрать: $tar zxvf tct-1.14.tgz; make CC="gcc -static"
Как проверить: file pcat or ldd pcat
5. Hunter.o (http://www.phrack.org/phrack/61/p61-0x03_Linenoise.txt)
Для того, чтобы сделать модуль более <<независимым>> убрали следующие
строки из исходника
Мы можем загрузить этот модуль в другие ядра путём удаления
MODVERSIONS.
Как собрать: $ gcc -c hunter.c -I/usr/src/linux/include/
6. Insmod (http://www.kernel.org/pub/linux/utils/kernel/modutils/for kernel 2.4)
Как собрать: $./configure-enable-insmod_static; make
Как проверить: file insmod.static or ldd insmod.static
7. NetstatArproute (http://freshmeat.net/projects/net-tools/)
Как собрать: $bzip2 -d net-tools-1.60.tar.bz2; tar xvf
net-tools-1.60.tar.bz2; make config; make CC="gcc -static"
Как проверить: file netstat arp route or ldd netstat arp route
8. dmesg (http://ftp.cwi.nl/aeb/util-linux/util-linux-2.12.tar.gz)
Как собрать: $./configure; make CC="gcc -static"
Как проверить: file dmesg or ldd dmesg
Как только мы успешно соберем все перечисленные утилиты, мы скопируем
их на съемный носитель (например, на CD-RW диск).
Сбор информации о системе (пошаговые процедуры)
Следующее и очень важное требование, то, что мы должны начать собирать
информацию в определённой последовательности, начиная с данных
обладающих наименьшим сроком жизни, заканчивая наиболее <<живучей>>
информацией. Мы должны помнить об этом в процессе сбора информации.
Шаг 1: Съёмка фотоаппаратом экрана скомпрометированной системы.
Это своего рода скриншот, конечно же, мы должны использовать цифровую
камеру для этой задачи. Это простой шаг.
До того, как перейти к установке носителя, давайте сначала задумаемся
о последствиях, которые могут возникнуть при подключении носителя к
скомпрометированной системе. В данный момент давайте проигнорируем
влияние на память скомпрометированной системы.
Для монтирования съемного носителя мы должны использовать ненадежную
команду mount. Если всё пойдёт, согласно нашему плану, мы запустим
остальные команды с монтированного носителя.
Также мы должны исследовать изменения, которые произошли в системе при
использовании команды mount. Файлы и каталоги, которые были изменены
при использовании команды mount, приведены в таблице 2.
# strace /bin/mount /mnt/cdrom
Таблица 2: Файлы, которые были изменены после использования команды mount.
* используя ключ "-n", можно предотвратить доступ к этому файлу.
Мы не учли ситуацию, в которой взломщик модифицировал команду mount.
Например, при запуске этой команды будет вызван специальный процесс,
который удаляет все доказательства злонамеренной активности на
скомпрометированной системе, вместо того, чтобы смонтировать носитель.
Такой процесс называется "deadman switch". Но давайте предположим, что
у нас все в порядке с командой mount, и вернёмся к процессу сбора
данных.
Я предполагаю, что была проверена каждая команда, которую вы
собирались сохранить на носителе, который в будущем будет использован
на скомпрометированной системе для сбора улик.
Давайте рассмотрим возможные проблемы, которые могут возникнуть при
монтировании внешнего носителя.
* После того, как мы вставили носитель в привод, процесс "Volume
Manager" смонтирует процесс автоматически. Какие файлы будут
модифицированы? Все ли из этих файлов перечислены в таблице 2?
* Предположим, в данный момент на скомпрометированной системе
смонтирован неизвестный носитель. Тогда необходимо предварительно
размонтировать этот носитель. Как сделать размонтирование наиболее
безопасным? Могу предложить два решения. Мы можем воспользоваться
небезопасным вариантом - командой umount или мы можем поместить
<<безопасную>> команду umount на флоппи диск. Следующий шаг - мы
используем небезопасную команду mount для монтирования флоппи и
затем запускаем <<безопасную>> umount команду. Это немного
запутано, но эффективно. В этом случае мы используем только одну
небезопасную команду "mount".
* Администратор не вошел в систему или даже хуже, пароль
администратора изменён взломщиком. К каким файлам будет
осуществлён доступ, или какие файлы будут изменены во время
процесса входа в систему? Какие будут созданы дополнительные
процессы? Если пароль администратора был изменён, какие еще
учетные записи присутствуют в системе? Какие подверженные
изменениям данные могут быть собраны без доступа к оболочке?
Открытые TCP/UDP порты, текущие соединения, что ещё?
* Какие еще непредвиденные проблемы могут возникнуть?
Шаг 2: Монтирование носителя
Давайте начнём и смонтируем наш носитель, в данном случае CD-ROM с
нашими утилитами.
# mount -n /mnt/cdrom
Если процесс монтирования прошёл успешно, мы можем перейти к наиболее
важной стадии сбора данных. Запомните все результаты, сгенерированные
доверенными командами, которые должны быть отправлены на удалённый
хост. Для этого я использую утилиту netcat и pipe метод. Для того
чтобы понять, какие задачи выполняются на удаленном хосте, все
запущенные команды на уязвимой системе должны идти с приставкой
"compromised", а команды, запущенные на удаленном хосте, с приставкой
"remote". Рассмотрим следующий пример.
Для отправки информации о реальной дате скомпрометированной системы на
удаленную систему (IP-адрес удалённого хоста, в данном случае,
192.168.1.100), на удаленном хосте нам необходимо открыть TCP порт
следующим образом:
(remote host)# nc -l -p 8888 > date_compromised
Далее, выполняем следующее на скомпрометированном хосте:
Результат представлен в UTC формате (Coordinated Universal Time)
(remote)# nc -l -p port > date_compromised
(compromised)# /mnt/cdrom/date -u | /mnt/cdrom/nc (remote) port
(remote)# md5sum date_compromised > date_compromised.md5
Step 4: Кэшируемые таблицы
Первым делом мы должны собрать информацию из кэшируемых таблиц, так
как время жизни этой информации очень короткое. Я соберу информацию из
таблиц arp и routing.
Mac address cache table:
(remote)# nc -l -p port > arp_compromised
(compromised)# /mnt/cdrom/arp -an | /mnt/cdrom/nc (remote) port
(remote)# md5sum arp_compromised > arp_compromised.md5
Kernel route cache table:
(remote)# nc -l -p port > route_compromised
(compromised) # /mnt/cdrom/route -Cn | /mnt/cdrom/nc (remote) port
(remote)#md5sum route_compromised > route_compromised.md5
Шаг 5: Текущие и находящиеся в очереди соединения и открытые TCP/UDP порты.
Далее собираем информацию о текущих соединениях и открытых TCP/UDP
портах. Информация о всех активных сырых сокетов будет собрана в
восьмом шаге.
(remote)#nc -l -p port > connections_compromised
(compromised)# /mnt/cdrom/netstat -an | /mnt/cdrom/nc (remote) port
(remote)#md5sum connections_compromised > connections_compromised.md5
В нашем случае мы можем использовать команду cat, вместо команды
netstat. Информация об открытых портах храниться в /proc псевдо
файловой системе (/proc/net/tcp и /proc/net/udp файлы).
Информация о текущих соединениях расположена в /proc/net/netstat
файле. Все данные в этих файлах представлены в hex формате.
Для примера: 0100007F:0401 in decimal is 127.0.0.1:1025.
Как упоминалось до этого, текущие соединения могут быть обнаружены и
проанализированы в записанном трафике. Исследование записанного
трафика может помочь в обнаружении руткита, загруженного в память
ядра, который прячет открытый порт. Мы должны удалённо просканировать
скомпрометированный хост и сравнить обнаруженные открытые порты с
нашим результатом, полученным посредством команды netstat. Но данный
способ чреват большими повреждениями и мы снова меняем содержимое
скомпрометированной системы, в шаге семь я представлю альтернативный
метод обнаружения LKM руткитов.
В завершении первой части
Далее мы предпримем несколько дополнительных шагов на
скомпрометированной машине до того, как выключим ее. Во второй части
данной статьи мы исследуем способы обнаружения злонамеренного кода
путём сбора большего количества данных, отправленных на удалённый
хост. Также мы обсудим некоторые виды поиска, который может быть
произведен в безопасном окружении.
311 Прочтений • [Анализ инцидента на работающей Linux системе (security linux test mount file connect)] [08.05.2012] [Комментариев: 0]
Vova
