Исследование взломанной Linux системы №4

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

Анализ

Вернемся ненадолго к пункту 8 и рассмотрим
его более подробно, пару проблемных
ситуаций. 

Первый пример: Программа, инициировавшая
процесс, удалена.

В этом случае файл Linux, запустивший
процесс, по прежнему находится в памяти. Для
восстановления необходимо знать его ID
процесса. В /proc/ директории мы можем найти
исполняемый файл. Это копия удаленного, его
и необходимо скинуть на наш хост, где
собирается вся информация. после получения
файла необходимо понять что он делает и
зачем. тут есть два варианта:
дизассемблировать или запустить в
контролируемой среде.

Пример второй: Файл, открытый одним из
активных процессов, удален (например лог-файл).

Пример работы lsof:

Для восстановления этого файла
необходимо просмотреть содержание
поддиректории fd (файловые дескрипторы) из /proc/3137.

(remote)# nc -l -p port > ls_from_proc_3137
(compromised)# /mnt/cdrom/ls -la /proc/3137/fd/ | /mnt/cdrom/nc (remote) port
(remote)# more ls_from_proc_3137

l-wx------ 1 root root 64 Aug 10 21:03 12 -> /var/log/httpd/access_log (deleted)
...

Как можно видеть первый дескриптор удален.
Все что надо сделать - скопировать.

(remote)# nc -l -p port > deleted_access_log
(compromised)# /mnt/cdrom/cat /proc/3137/fd/1 | /mnt/cdrom/nc (remote) port

Поиск ключевых слов

тут я попробую описать один из методов
анализа процессов и памяти. Напомню, что
анализ надо производить на взломанном
хосте после снятия всей информации. Главное
преимущество этого метода - в отсутствиии
необходимости знать язык низкого уровня. Я
использую следующие инстурменты для поиска
следов взломщика:

• strings
• less
• grep

Мы соберем все печатные символы из
целевого файла. Установки по умолчанию
позволяют видеть последовательности
минимум 4 символа подряд. Для задания
смещения от начала файла используем ключик
-t.

$ strings -t d kcore > kcore_strings
$ md5sum kcore_strings > kcore_strings.md5

Утилита grep и регулярные выражения - важная
часть этой стадии. Всего за несколько минут
мы сможем найти присутствие хакера. Прежде
необходимо понять, какие следы следует
искать - команды, IP адреса, пароли и ли код...

Ниже примеры ключевых слов которые я
искал:

• Имя хоста или префикс взломанной
  системы


$ grep "root@manhunt" kcore_strings
$ grep "]#" kcore_strings
11921096 [root@manhunt]#
16643784 [root@manhunt root]#
30692969 ]#]#
Обнаружив следы надо взять текстовый
редактор и перепрыгнуть к той позиции, где
собственно присутствие и обнаружено. Если
особо повезет (как показано ниже), то можно в обнаруженном
районе найти и другие следы хакера.
Следует помнить, что страницы виртуально
памяти в физической и место под swap пишутся
неупорядоченно.

$ less kcore_strings
/11921096

11921096 [root@manhunt]#
11921192 /usr/bin/perl
11921288 perl apache_mod_exploit.pl
...

• Имена файлов и директорий
  
  $ grep -e "\/proc\/" -e "\/bin\/" -e "\/bin\/.*?sh"
  kcore_strings
  $ grep -e "ftp" -e "root" kcore_strings
  $ grep -e "rm -" kcore_strings
  $ grep -e ".tgz" kcore_strings
• IP адреса и доменные имена
  $ grep -e "[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+" kcore_strings
  $ grep -e "\.pl" kcore_strings

Углубленный анализ

В заключительной главе я покажу как
анализировать скопированный kcore файл при
помощи gdb. Для начала - проверка,
соответствуют ли адреса системных вызовов
таблице syscall. Изменение адресов - простейший
метод внедрения LKM.

Для начал анализа нужна следующая
информация:

• образ памяти в ELF формате (шаг 6)
• образ скомпилированного ядра (необходимо
  смонтировать файловую систему на
  взломанной машине и скопировать файл
  vmlinux-* из директории /boot)
• список экспортных "символов" (System.map
  из /boot или ksyms из 7 шага)
• исходники ядра, используемого на машине

Время запустить gdb как показано ниже:

#gdb vmlinux kcore
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...

warning: core file may not match specified executable file.
Core was generated by `ro root=/dev/sda2 hdc=ide-scsi'.
#0 0x00000000 in ?? ()
(gdb)

Теперь мы полностью готовы для анализа.