Свободные утилиты forensic::Журнал СА 4.2004
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1944
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1974
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1530
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1118
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1693
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

Электронка - 2020!

 Свободные утилиты forensic

Архив номеров / 2004 / Выпуск №4 (17) / Свободные утилиты forensic

Рубрика: Безопасность /  Угрозы

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

Свободные утилиты forensic

Компьютеры и Интернет продолжают проникать и вторгаться в нашу жизнь, увеличивая тем самым вероятность оказаться жертвой компьютерного преступления. Как ни прискорбно замечать, несмотря на обилие и разнообразие средств защиты, с каждым годом количество взломов увеличивается. Оказавшись жертвой взлома, некоторые, бывает, и теряются, что порой приводит к неправильным решениям. Наверное, одна из самых распространенных ошибок состоит в немедленном удалении всех данных и восстановлении системы из резервных архивов и продолжении работы как ни в чем не бывало (хотя настаивать на своем мнении не буду, бывают разные ситуации). Почему так? Во-первых, не всегда можно сразу точно узнать, когда произошел взлом, и в архиве могут быть уже «зараженные» тем же rootkits файлы; во-вторых, если повезло с первым случаем, то где вероятность того, что злоумышленник не воспользуется тем же способом, что и ранее, для повторного проникновения, и в результате время будет потрачено зря, и в-третьих, иногда трудно сказать, произошел ли взлом вообще, и чтобы доказать это, требуется собрать максимальное количество информации, т.к. простой сервера ведет к финансовым потерям (а еще и имидж, и пр.), и кто-то должен отвечать за это.

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

Если на компьютере установлена одна из систем контроля целостности вроде tripwire (http://www.tripwire.org) или AIDE – Advanced Intrusion Detection Environment (http://sourceforge.net/projects/aide), а также система обнаружения вторжения наподобие Snort (http://www.snort.org), плюс средство аудита системы вроде того же Snare (http://www.intersectalliance.com/projects/Snare), то у вас будут ответы на основные вопросы – когда и где происходило событие, как все произошло, сколько времени и на какие файлы воздействовали в системе. Теперь осталось осторожно извлечь чужое и проанализировать подробнее.

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

The Coroner’s Toolkit (TCT)

Разработанный Dan Farmer и Wietse Venema, это один из самых первых и самых известных и свободных инструментов, предназначенных для сбора данных на скомпрометированной системе (http://www.fish.com/tct). Работает с файловыми системами FFS (FreeBSD, OpenBSD, BSD/OS, Solaris) и EXT2/3FS, также при помощи патча, доступного на сайте, можно заставить работать со второй версией FFS (FreeBSD 5.x), что касается и всех остальных утилит, участвующих в обзоре, к глубокому сожалению, с новыми ФС под Linux – ReiserFS, XFS и JFS они не работают. Одной из особенностей этой и подобных утилит является максимальный отказ от утилит исследуемой операционной системы и максимальное протоколирование всех своих действий. Так, даже вместо системного командного интерпретатора используется свой. Установка заключается в получении архива, его распаковки и ввода команды make. После чего здесь же, в подкаталоге bin, появятся несколько исполняемых файлов.

По назначению их можно условно поделить на четыре группы:

  • grave-robber – предназначена для захвата данных, включая даже удаленные с диска, но еще открытые и находящиеся в памяти.
  • pcat, ils, icat, file – предназначены для записи и анализа процессов и данных, содержащихся на диске.
  • unrm и lazarus – для восстановления и анализа освобожденных дисковых блоков файловой системы.
  • mactime – Perl-скрипт, предназначенный для сбора информации о времени последнего обращения, изменения и время создания (mtimes, atimes и сtimes или лучше modification, access или change – так запомнить легче) файлов и каталогов, при этом не изменяя их.

Теперь поподробней.

Некоторые утилиты могут работать как с «живой» файловой системой, так и с образом, созданным при помощи команды dd.

#dd if=/dev/hda9 of=./system.img

4321416+0 records in

4321416+0 records out

Для создания «мгновенного» снимка системы предназначена утилита grave-robber. По умолчанию grave-robber фиксирует информацию о процессах и состоянии сетевых соединений, выясняет все, что может, относительно конфигурации аппаратных средств, особенно обращая внимание на диски и дисковые разделы, и исследует состояние критических файлов (конфигурационные файлы, журналы и пр.). Список исследуемых каталогов программа берет в файле conf/look@first и основные настройки берет из файла grave-robber.cf.

Вывод выглядит так:

# ./grave-robber

Starting preprocessing paths and filenames on grinder...

Processing $PATH elements...

/usr/sbin

/bin

/usr/bin

/sbin

/usr/X11R6/bin

        Processing dir /home/work/forensic/tct-1.14/bin

        Processing dir /etc

        Processing dir /bin

        Processing dir /sbin

        Processing dir /dev

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

# ./grave-robber -c /data1 -o LINUX2

Из других параметров, разделенных на три группы (general, micro data collection и macro data collection), особо интересными, по моему мнению, являются (по умолчанию собирается максимальное количество данных, что занимает довольно много времени):

  •  -l – на живой системе перед сбором информации вызывает lstat();
  • -P – выполняет на живой системе команды ps, lsof, icat для того, чтобы получить данные о выполняемых процессах и делает копии их исполняемых файлов. Icat-команда требует привилегий и используется только на системах, где к исполняемому файлу нельзя обращаться через /proc файловую систему;
  • -s – на живой системе при помощи netstat, df собирает информацию о состоянии хоста и сетевых соединениях;
  • -t – собирает информацию от hosts.equiv, .rhosts, and xhost;
  • -M – собирает контрольную сумму MD5 для файлов;
  • -v – вывод подробных данных.

В результате работы утилиты в подкаталоге data/hostname_time (его можно изменить при помощи опции -d), образуется несколько файлов и каталогов.

../data/grinder_2004_02_02_10:48:40_+0200:

.  ..  body  body.S  command_out  conf_vault  MD5_all  MD5_all.md5   proc  trust  user_vault

В body содержится MAC-база времени, body.S тоже, но описаны файлы с установленным SUID; command_out – вывод программ, которые выполняются, с контрольными суммами и временными метками; conf_vault – программы, которые утилита нашла интересными, в основном критические и конфигурационные файлы; proc – копии исполняемых файлов запущенных процессов с контрольными суммами. Может быть еще каталог deleted_files, содержащий удаленные, но еще открытые файлы.

Если необходимо просто просмотреть, изменялось ли MAC-время доступа к файлам, начиная с определенного времени (или промежуток при задании двух значений), то запускаем утилиту mactime, в результате получим колонку, состоящую из значений [date time size MAC (т.е. изменившееся поле) perms owner group file]. Давайте посмотрим, какие файлы изменились с 10 января 2004 г. (формат: месяц/дата/год).

#./mactime 1/10/2004

Feb 02 04 10:12:57    8 m.c lrwxrwxrwx root     root     /data1/dnsdomainname -> hostname

                 4916 ..c -rwxr-xr-x root     root     /data1/deallocvt

                  4 m.c lrwxrwxrwx root     root     /data1/csh -> tcsh

...

                9 m.c lrwxrwxrwx root     root     /data1/psfgettable -> psfxtable

               5044 ..c -rwxr-xr-x root     root     /data1/setkeycodes

Feb 02 04 10:38:35    16384 .a. drwx------ root     root     /data1/lost+found

То есть с указаного времени изменялся inode (..с) файла deallocvt, если файл недавно копировался или создавался другим способом, то это не должно вызывать подозрений, но если операционная система стоит не один день, а файл находится в неизменяемой обычно области (/bin, /sbin и т. д.), то это должно вызвать подозрения. Хотя, как вы понимаете, все эти времена можно без проблем изменить. Далее все, думаю, понятно по аналогии. Из интересных опций следует отметить -s, показывающую файлы с установленным SUID/SGID другим цветом, ее необходимо использовать совместно с -h, устанавливающую вывод в виде html.

Просмотреть, чем сейчас занимается тот или иной процесс, найденный при помощи ps, netstat, или lsof, можно, запустив команду pcat, которая копирует содержание его памяти в стандартный вывод.

./pcat 881 | strings | less

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

Теперь попробуем найти потерянные или спрятанные файлы. Для этого воспользуемся утилитой ils (inode list), которая открывает названное устройство и перечисляет inode. По умолчанию ils выводит inodes только удаленных файлов.

Опций много, наиболее интересные следующие: опция -е выводит список всех inode; -o – выводит список всех inodes удаленных файлов, но таких, которые являются еще открытыми или выполняются; -r выводит список удаленных файлов.

# ./ils  -or /dev/hda9

class|host|device|start_time

ils|mgrinder|/dev/hda9|1075713057

st_ino|st_alloc|st_uid|st_gid|st_mtime  |st_atime  |st_ctime  |st_dtime  |st_mode|st_nlink|st_size|st_block0|st_block1

1     |a       |0     |0     |1075576270|1075576270|1075576270|0         |0      |0       |0      |0        |0

28    |f       |0     |0     |1075713004|1075711733|1075713004|1075713004|100755 |0       |0      |0        |0

94    |f       |0     |0     |1075713026|1075711735|1075713026|1075713026|100755 |0       |0      |0        |0

107   |f       |0     |0     |1075713032|1075711736|1075713032|1075713032|100755 |0       |0      |0        |0

111   |f       |0     |0     |1075713040|1075711734|1075713040|1075713040|100755 |0       |0      |0        |0

Если запустить ее с опцией -о, то будет выведен только inode с номером 1.

Поле st_alloc принимает два значения; «a2» – для allocated inode и «f» – для free inode.

В первом столбце даны значения inodes удаленных, т.е. не прописанных ни в одном каталоге файлов. Теперь при помощи icat, позволяющей копировать файл, обращаясь к нему не по имени, а по номеру inodes, попробуем скопировать удаленный файл.

# ./icat

./icat: usage: ./icat [-f fstype] [-h (no holes)] [-H (keep holes)] [-vV] device inum...

# ./icat /dev/hda9 107 > /tmp/delete_file

Чтобы определить, что за файл находится перед нами, применяется утилита file, которая при помощи трех тестов (filesystem tests, magic number tests и language tests) пытается дать ответ.

Первый тест пытается выяснить, является файл двоичным (программа или данные в каком-то формате) или содержит ASCII-текст. На втором этапе при помощи системного вызова stat пытается определить тип (описаны в sys/stat.h). И наконец, пытается определить magic number, сохраненный в определенном месте файла и найти соответствующий известному типу файла (например, исполняемый elf или a.out).

 # ./file /tmp/delete_file 

/tmp/delete_file: ELF 32-bit LSB executable, Intel 80386, version 1, stripped

Все, по-моему, понятно без комментариев. От себя добавлю, что вовремя спасенная таким образом программа без проблем открывалась и выполнялась.

Применив такую конструкцию, можно попытаться восстановить все удаленные файлы.

# ./ils -rf ext2fs /dev/hda9 | awk -F "|" "($2=="f") {print $1}" | while read i; do /usr/local/tct-1.14/bin/icat /dev/hda9 $i > /tmp/deleted/$i; done

Но для сохранения данных, содержащихся во всех свободных inodes файловой системы, в отдельный файл для последующего анализа предназначена другая утилита – unrm. При ее использовании необходимо помнить две вещи: записывать результат нужно в другой раздел жесткого диска, иначе потеряете все, и в этом разделе должно быть достаточно места для сохранения данных. Например, если создать образ файловой системы размером 10 Гб, заполненной на 3 Гб при помощи утилиты dd, то он займет 10 Гб, а если при помощи unrm, то места потребуется 7 Гб (10 – 3), плюс столько же для последующего анализа. Если не доверяете системной команде dd, то, запустив unrm с опцией -e, можно создать полный образ раздела:

# ./unrm /dev/hda9 > /home/hda9_urm.res

или если извлечь неиспользованные inodes из предварительно созданного dd образа.

# ./unrm /image/system.img > /home/system_urm.res

В результате можем получить файл довольно приличных размеров, который перебрать вручную довольно хлопотное дело. И не надо. Для этого есть специально обученная утилита lazarus, анализирующая поблочно весь файл и пытающаяся определить, что за информация находится в этих блоках, а также связать разрозненные блоки между собой. При этом lazarus понимает кроме FFS, EXT2/3 и NTFS с FAT32. Утилита читает данные порциями размером 1 Кб (значение можно изменить в lazarus.cf в переменной $BLOCK_SIZE), определяет по 10 % блока, что за данные (текст, двоичные, неизвестные) находятся в нем. Если текст, то, используя регулярные выражения, пытается прочитать их, в двоичных пытается определить формат.

# ./lazarus -h /home/hda9_urm.res

XxxxxTtt...Xxxx!!!!Ttt...Xxxx!!!!!!!!!Tt.T..XXxxxx!!!!!Xx!!!!!!!!!!!!!!!!!T...T

 ttt.................!!!!!!!!!!!!!!!!!!!!!

Вывод утилиты – набор символов (если опция -h, то и HTML-файл, рис. 1), соответствующие распознанным типам блоков, которых lazarus смог определить. Кроме того, в каталоге blocks (определен в переменной $blocks в файле lazaruz.cf или, возможно, переопределить, использовав флаг -D) создаются файлы, которые содержат данные, найденные в блоках. Последовательные блоки того же самого типа считаются одним и тем же файлом и записываются в тот же самый выходной файл $blocks/*. Расшифровка выдаваемых значений видна на рис. 1.

Рисунок 1

Рисунок 1

Так, буква «T» означает текстовый файл, «M» – почтовый, «C» – код на Cи, точка «.» – файл неопределен. Хотя, бывает, утилита и ошибается. Далее процесс восстановления описан в документе help-recovering-file и lazarus.README, которые лежат в подкаталоге doc. Например, текстовые файлы с определенными словами можно попробовать найти при помощи grep:

# egrep -l "keyword1|keyword2|..." blocks/*.txt > allfiles

Вы видите, насколько мощные и удобные инструменты имеются в TCT, но все же их возможностей явно не достаточно. Так, нельзя обеспечить анализ по имени файла, провести соответствие inodes с блоками, просмотреть информацию, находящуюся в отдельных блоках. Поэтому был разработан еще один комплект инструментов, дополняющих TCT, названный TCTUtils (http://www.cerias.purdue.edu/homes/carrier/forensics) и использующий его библиотеки. Принцип работы прост и основывается на том, что информация при удалении файла фактически сохраняется в записях каталога. Выглядит это в общем приблизительно так (некоторые подробности работы ext2 смотрите в [1]. Каталог имеет для каждого файла четыре существенные записи: номер inode, длина записи в байтах rec_len, округленная до 4, имя файла (name) и длина имени файла (nam_len). При удалении файла в целях экономии времени запись о нем не удаляется, просто к значению rec_len предыдущего файла добавляется длина удаляемого, т.е. фактически утилиты теперь проскакивают над записью удаленного файла. И теперь утилиты из TCTUtils, анализируя поля, определяют, у которого поле rec_len больше требуемого, и таким образом находят спрятанный файл.

Для компиляции TCTUtils потребуется наличие установленного TCT, путь к каталогу которого необходимо указать в файле src/Makefile в переменной TCT_DIR. После этого в подкаталоге bin появятся несколько исполняемых файлов.

# ls bin 

bcat        blockcalc   find_file   find_inode  fls     istat

Разберем подробнее. В предыдущих примерах мы нашли несколько удаленных файлов и даже успели их спасти. Но кроме номера inode, о файлах не известно больше ничего. Пробуем при помощи утилиты istat извлечь остальную «спрятанную» информацию.

./istat /dev/hda9 107

inode: 107

Not Allocated

uid / gid: 0 / 0

mode: rwxr-xr-x

size: 572712

num of links: 0

Modified:       09.23.2003 20:10:02     (EET+0)

Accessed:       02.02.2004 10:48:56     (EET+0)

Changed:        02.02.2004 12:38:27     (EET+0)

Deleted:        02.02.2004 12:38:27     (EET+0)

Direct Blocks:

  9364 9365 9366 9367 9368 9369 9370 9371

  ....................................................

  9493 9494 9495 9496 9497 9498 9499 9500

  9501 9502 9503 9504

Indirect Blocks:

  9376

Как видите, теперь, кроме номера inode, стала известна информация о размере файла, владельце, режимах доступа, МАС-временах, и главное, номера дисковых блоков, в которых записано тело файла. Чтобы заглянуть внутрь блока, используем другую утилиту bcat, которая может выводить информацию как сырой raw, текст ASCII (опция -а), hexdump (-h), html (-w), выводить статистику (-s), просматривать свап (-f swap).

# ./bcat -h /dev/hda9 9364 512

0       7f454c46 01010100 00000000 00000000     .ELF .... .... ....

16      02000300 01000000 e0800408 34000000     .... .... .... 4...

32      e0b90800 00000000 34002000 03002800     .... .... 4. . ..(.

48      15001400 01000000 00000000 00800408     .... .... .... ....

64      00800408 2c5e0800 2c5e0800 05000000     .... ,^.. ,^.. ....

80      00100000 01000000 00600800 00e00c08     .... .... .`.. ....

96      00e00c08 10320000 40570000 06000000     .... .2.. @W.. ....

112     00100000 04000000 94000000 94800408     .... .... .... ....

128     94800408 20000000 20000000 04000000     ....  ...  ... ....

144     04000000 04000000 10000000 01000000     .... .... .... ....

160     474e5500 00000000 02000000 02000000     GNU. .... .... ....

176     05000000 5589e583 ec08e845 000000e8     .... U... ...E ....

192     cc000000 e847c106 00c9c300 00000000     .... .G.. .... ....

208     00000000 00000000 00000000 00000000     .... .... .... ....

224     31ed5e89 e183e4f0 50545268 c0e00508     1.^. .... PTRh ....

240     6860e005 08515668 f0810408 e81f5c01     h`.. .QVh .... ...

256     00f49090 5589e553 e8000000 005b81c3     .... U..S .... .[..

272     d7900800 528b8328 00000085 c07402ff     .... R..( .... .t..

288     d0585bc9 c3909090 90909090 90909090     .X[. .... .... ....

304     5589e550 50803d20 120d0800 7547a108     U..P P.=  .... uG..

320     e00c088b 1085d274 1c8db426 00000000     .... ...t ...& ....

336     83c004a3 08e00c08 ffd2a108 e00c088b     .... .... .... ....

352     1085d275 ebb80000 000085c0 741083ec     ...u .... .... t...

368     0c680c02 0d08e885 7efbf783 c410c605     .h.. .... ~... ....

384     20120d08 01c9c389 f68dbc27 00000000      ... .... ..." ....

400     55b80000 000089e5 e8000000 005a81c2     U... .... .... .Z..

416     47900800 5185c051 7415526a 00682412     G... Q..Q t.Rj .h$.

432     0d08680c 020d08e8 447efbf7 83c4108b     ..h. .... D~.. ....

448     15e0110d 0885d274 19b80000 000085c0     .... ...t .... ....

464     741083ec 0c68e011 0d08e821 7efbf783     t... .h.. ...! ~...

480     c410c9c3 90909090 90909090 90909090     .... .... .... ....

496     5589e557 565381ec 1c040000 c785d8fb     U..W VS.. .... ....

Возможен и обратный поиск, т.е. известен номер блока и требуется найти номер inode, за которым данный блок закреплен.

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

# ./find_inode /dev/hda9 9364

107

# ./find_inode /image/system.img 12345

No inode or potential fragment base was found

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

Из опций утилиты стоит отметить:

  • -a – отображает имена файлов, начинающиеся с точки, которые любят использовать взломщики;
  • -d – вывод только удаленных файлов (-u – только не удаленных);
  • -l – вывод подробной информации о файле;
  • -r – рекурсивный обход всех директорий (но не может следовать за удаленными каталогами).

# ./fls -rd /dev/hda9

? * 0:  /date

r * 28: /dd

? * 0:  /deallocvt

? * 0:  /kbd_mode

? * 0:  /lsmod.old

? * 0:  /lsmod.static

? * 0:  /mapscrn

? * 0:  /mknod

? * 0:  /rescan-scsi-bus.sh

r * 91: /rm

r * 107:        /sort

r * 111:        /tar

r * 95426:      /var/lib/rpm/__db.Packages

d * :    /dir1

Как видите, удалось определить, что за файл скрывался в inode под номером 107, который теперь благополучно можно восстановить при помощи icat. Но если под Linux такой номер проходит, то в Solaris можно вообще не получить никакой информации.

Удаленные файлы и каталоги помечаются знаком *. Первая буква показывает, что за файл, т.е. r-egular, d-irectory, l-ink, s-ocket или неопределен (?).

Найти имя файла или каталога по известному inode можно при помощи утилиты find_file. В man не сказано, что означают те или иные опции, поэтому пришлось поначалу запустить ее со всеми сразу.

#./find_file -adu /dev/hda9 107

-d and -u must not be used together

usage: ./find_file [-adu] image inode

        -a: Find all occurrences

        -d: Find deleted entries ONLY

        -u: Find undeleted entries ONLY

Пробуем.

# ./find_file -a /dev/hda9 107

* /sort

Хотя программы по-прежнему нет в списке.

# ls -al /data1/sort

/bin/ls: /data1/sort: No such file or directory

И последняя утилита blockcalc из комплекта TCTUtils предназначена для отображения соответствия между номером блока в образах, созданных при помощи dd и unrm.

./blockcalc [-du] block dd_image

Slowly calculates the opposite block number

        One of the following must be given:

        -d: The given block number is the "dd" block num

        -u: The given block number is the "unrm" block num

# ./blockcalc -u 9364 /image/system.img

19496

Не знаю, что послужило причиной, но TCT и TCTUtils не развиваются уже с 2001 года (но это не значит, что их нельзя использовать и я зря о них рассказывал). Вместо них Brian Carrier выпускает единый комплект утилит, названный Sleuth Kit (http://www.sleuthkit.org/sleuthkit), основанный на их коде, объединяющий основные функциональные возможности и работающий с файловыми системами NTFS, FAT, FFS, EXT2FS и EXT3FS. Последняя на момент написания статьи версия 1.67 от 6 января 2004 года. Для удобства, чтобы легче было ориентироваться, названия утилит изменены и начинаются на букву, соответствующую тому уровню, на котором они работают. Их несколько: File System Layer – работа с файловой системой; Content Layer (буква d – data) – фактическое содержание блоков, кластеров, фрагментов; Meta Data Layer (inode) – описывает файл или каталог, т.е. все, что можно извлечь из inode; Human Interface Layer (file) – более удобный уровень взаимодействия с файлами, чем при использовании метаданных. Во многих утилитах были добавлены новые опции, например, -m, позволяющая выводить одновременно информацию и о MAC-временах; -z – для указания временного пояса; обязательной стала опция -f, предназначенная для указания файловой системы. После компиляции в подкаталоге bin вы найдете 18 утилит.

/home/work/forensic/sleuthkit-1.67/bin # ./

dcalc    dls      ffind    fls      hfind    ifind    istat    md5      sha1

dcat     dstat    file     fsstat   icat     ils      mactime  mmls     sorter

С назначением утилит file, icat, ils, mactime, istat, fls мы уже знакомы. Утилита ifind является новой версией find_inode, ffind пришел на замену find_file, dcalc – blockcalc, соответственно, dcat – bcat, dls назывался когда-то unrm, утилиты md5 и sha1 предназначены для работы с контрольными суммами в одноименных алгоритмах. Остались незнакомыми только hfind, dstat, fsstat, mmls и sorter.

Появившаяся в Sleuth Kit v1.63 утилита mmls предназначена для вывода таблицы разделов. Ее применение может помочь в поиске «спрятанных» данных, т.к. показывает, какие сектора не используются.

# ./mmls -?

./mmls [-o offset] [-v] -t mmtype disk

        -t mmtype: media type

        [-o offset]: sector offset to start reading from

        -v: verbose output

        -V: print the version

Supported media types:

        dos (DOS-based partitions [Windows, Linux, etc.])

        mac (MAC partitions)

        bsd (BSD Disklabels [FreeBSD, OpenBSD, NetBSD])

        sun (Sun Volume Table of Contents (Solaris))

т.е. команда для запуска выглядит так:

# ./mmls -t dos /image/system.img

Для выдачи информации о состоянии конкретного блока или сектора dstat используется утилита dstat.

# ./dstat

       usage: ./dstat [-vV] -f fstype] image addr

-v: Verbose output to stderr

        -V: Print version

        -f fstype: Image file system type

Supported file system types:

        bsdi (BSDi FFS)

        fat (auto-detect FAT)

        fat12 (FAT12)

        fat16 (FAT16)

        fat32 (FAT32)

        freebsd (FreeBSD FFS)

        linux-ext2 (Linux EXT2FS)

        linux-ext3 (Linux EXT3FS)

        netbsd (NetBSD FFS)

        ntfs (NTFS)

        openbsd (OpenBSD FFS)

        solaris (Solaris FFS)

# ./dstat -f  linux-ext3 /image/system.img 9364

Fragment: 9364

Allocated

Group: 0

Или для выдачи более подробной информации:

# ./dstat -v -f linux-ext3 /image/system.img 19496

File system has sparse super blocks

First data block is 0

inodes 270368 root ino 2 blocks 540177 blocks/group 32768

fs_read_random: read offs 4096 len 32 (group descriptor)

        group 0: 22635/15780 free blocks/inodes

fs_read_random: read offs 8192 len 4096 (block bitmap)

group 0 dbase 0 bmap +2 imap +3 inos +4..500

fs_read_block: read block 19496 offs 79855616 len 4096 (data block)

Fragment: 19496

Not Allocated

Group: 0

Утилита fsstat отображает подробности, связанные с файловой системой.

# ./fsstat -f linux-ext3 /data2/bin.img

FILE SYSTEM INFORMATION

--------------------------------------------

File System Type: EXT2FS

Volume Name:

Last Mount: Mon Feb  210:11:59 2004

Last Write: Mon Feb  210:11:59 2004

Last Check: Sat Jan 3121:11:09 2004

Unmounted properly

Last mounted on:

Operating System: Linux

Dynamic Structure

Compat Features: Journal,

InCompat Features: Filetype, Recover,

Read Only Compat Features: Sparse Super,

 

META-DATA INFORMATION

--------------------------------------------

Inode Range: 1 - 270368

Root Directory: 2

 

CONTENT-DATA INFORMATION

--------------------------------------------

Fragment Range: 0 - 540176

Block Size: 4096

Fragment Size: 4096

 

BLOCK GROUP INFORMATION

--------------------------------------------

Number of Block Groups: 17

Inodes per group: 15904

Blocks per group: 32768

Fragments per group: 32768

 

Group: 0:

  Inode Range: 1 - 15904

  Block Range: 0 - 32767

    Super Block: 0 - 0

    Group Descriptor Table: 1 - 1

    Data bitmap: 2 - 2

    Inode bitmap: 3 - 3

    Inode Table: 4 - 500

    Data Blocks: 501 - 32767

...

Group: 16:

  Inode Range: 254465 - 270368

  Block Range: 524288 - 540176

    Data bitmap: 524288 - 524288

    Inode bitmap: 524289 - 524289

    Inode Table: 524290 - 524786

    Data Blocks: 524290 - 524289, 524787 - 540176

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

Утилита hfind как раз и предназначена для поиска хеш-функций в предварительно созданной базе. Для сравнения может использоваться предварительно созданная база, тогда ее работа в чем-то напоминает Tripwire. Но наибольшая эффективность от применения будет достигнута при использовании National Software Reference Library (NSRL), которую можно найти на http://www.nsrl.nist.gov. Проект поддержан Национальным Институтом Американского Министерства юстиции (NIJ, http://www.ojp.usdoj.gov/nij/sciencetech/ecrime.htm), Национальным Институтом Стандартов и Технологии (NIST) и другими подобными организациями, и предназначен для того, чтобы эффективно использовать компьютерные технологии в расследовании преступлений, инструментом которых является компьютер. NSRL разработана, чтобы собрать программное обеспечение из различных источников и включить профили файлов в справочный информационный набор Reference Data Set (RDS).

На декабрь 2003 года NSRL обеспечил профили и цифровые сигнатуры для 17 909 964 файлов. Использовав NSRL, возможно идентифицировать критические системные файлы, которые были изменены, одним из назначений этой библиотеки является поиск программ при расследовании преступлений, направленных против интеллектуальной собственности. Hfind проверяет значения хеш-функции в базе данных, используя двоичный алгоритм поиска. Это быстрее, чем grep, но требует создания индексного файла (опция -i).

# ./hfind –h

./hfind: invalid option -- h

 

hfind [-eqV] [-f lookup_file] [-i db_type] db_file [hashes]

        -e: Extended mode - where values other than just the name are printed

        -q: Quick mode - where a 1 is printed if it is found, else 0

        -V: Print version to STDOUT

        -f lookup_file: File with one hash per line to lookup

        -i db_type: Create index file for a given hash/data2/bin.img database type

        db_file: The location of the original hash database

        [hashes]: hashes to lookup (STDIN is used otherwise)

 

        Supported types: nsrl-md5, nsrl-sha1, md5sum, hk

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

Сначала создаем базу данных, используя md5sum.

#  md5sum /bin/* /sbin/* /usr/bin/* /usr/bin/* /usr/local/bin/* /usr/local/sbin/* > system.md5

Теперь создаем из полученной базы индексный файл.

#  ./hfind -i md5sum system.md5

Extracting Data from Database (system.md5)

  Valid Database Entries: 6048

  Invalid Database Entries (headers or errors): 0

  Index File Entries (optimized): 5819

Sorting Index (system.md5-md5.idx)

Теперь в текущем каталоге будут находиться два файла.

# ls

. .. system.md5   system.md5-md5.idx

Проверяем, что происходит в /bin.

# md5sum  /bin/* > bin.md5

# ./hfind -f bin.md5 system.md5

77d2e316bbbdb94c05682d9c9d85bccb  /bin/arch

61a02b69433f0358f56d942f3f529b2e  /bin/ash     

70f87cc4a6ebfe5dfea3ab380f3f213a  /bin/umount   Invalid Hash Value

Как видите, с /bin/umount что-то случилось после создания базы данных, и его контрольная сумма не совпадает. И наконец, скрипт на Perl – sorter, который анализирует образ при помощи fls и icat, находит файлы, в том числе и скрытые, для найденного файла запускает команду file, для того чтобы его распознать. При использовании библиотеки NSRL возможно отделение плохих файлов от хороших. Список плохих тут же попадет в файл alert.txt. Опция -s позволяет сохранить в указанном каталоге фактическое содержание файла, но для этого необходимо указать при помощи опции -С файл конфигурации, некоторые шаблоны можно найти в каталоге sorter/sort, этот файл позволяет задать соответствие между расширением и типом файла.

В каждом файле имеются поля шаблонов (конечно же, можно добавить и свои), например:

ext            jpg,jpeg,jpe       JPEG image data     

ext            gif            GIF image data

В общем же случае работа утилиты выглядит так:

#mkdir data

# ./sorter -d data -f linux-ext3 /image/system.img

 

Analyzing /data2/bin.img

  Loading Allocated File Listing

  Processing 117 Allocated Files and Directories

  100%

 

  Loading Unallocated File Listing

  Processing 4 Unallocated meta-data structures

  100%

 

All files have been saved to: data

Теперь в подкаталоге data появятся до тринадцати файлов, количество которых зависит от типов данных, и файл sorter.sum, в котором содержится суммарная информация о найденных файлах.

# ls data

.  .. archive.txt compress.txt documents.txt exec.txt sorter.sum

Например, exec.txt содержит рассортированный по алфавиту список исполняемых файлов, найденных в образе.

sort

  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),

  for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped

  Image: /image/system.img  Inode: 107

...

unicode_start

  Bourne shell script text executable

  Image: /image/system.img Inode: 118

А sorter.sum выглядит так.

Images

- /image/system.img

 

Files (121)

- Allocated (117)

- Unallocated (4)

 

Files Skipped (19)

- Non-Files (19)

- "ignore" category (0)

 

Extensions

- Extension Mismatches (0)

 

Categories (110)

- archive (2)

- audio (0)

- compress (1)

- crypto (0)

- data (0)

- disk (0)

- documents (5)

- exec (102)

- images (0)

- system (0)

- text (0)

- unknown (0)

- video (0)

Как видите, утилит предостаточно, еще больше у них опций, что, согласитесь, может запутать новичка или человека, не привыкшего к командной строке, что требует некоторое время на освоение и сужает круг пользователей. Поэтому дополнительно к Sleuth Kit был создан инструмент визуализации Autopsy Forensic Browser (http://www.sleuthkit.org/autopsy/index.php).

После распаковки архива и запуска команды make, в ходе работы которой необходимо ответить на вопросы расположения Sleuth Kit, необходимости закачки библиотек NSRL и пути (Evidence Locker), куда будут складываться файлы отчетов, логи и данные. Последние могут потребовать довольно много свободного места, поэтому укажите на раздел посвободнее. После чего запускаем, опционально можно указать порт.

# ./autopsy

============================================================

                       Autopsy Forensic Browser

                  http://www.sleuthkit.org/autopsy/

                             ver 1.75

============================================================

 

Evidence Locker: /home/work/

Start Time: Sat Feb  7 20:42:11 2004

Remote Host: localhost

Local Port: 9999

 

Open an HTML browser on the remote host and paste this URL in it:

 

        http://localhost:9999/4614372704092601581/autopsy

 

Keep this process running and use to exit

Вставив строку с URL в браузер, попадаем в окно (см. рис. 2), заметьте, доступна помощь (рис. 3).

Рисунок 2

Рисунок 2

Рисунок 3

Рисунок 3

Первоначально требуется создать базу данных образов, взятых с различных компьютеров командой dd или dls (unrm), на которых будут проводиться исследования. Указываем на образ, с которым будем работать. Для этого жмем на New Case и заполняем пункты, здесь необходимо ввести название и короткое описание, чтобы затем можно было без проблем найти нужный образ.

После чего заполняем пункт Adding a New Host, в котором указываем имя компьютера (будет затем создан подкаталог с этим именем в Evidence Locker), его короткое описание, временной пояс и опционально расхождение времени и путь к базам NSRL. И наконец, в Adding a New Image (рис. 4) заполняем данные на исследуемый образ. Обратите внимание, что после ввода пути к образу можно выбрать вариант копирования в папку Evidence Locker, перемещение или вариант по умолчанию – создание симлинка. Здесь же указываем файловую систему и точку монтирования, с которой снимался образ, если известна MD5-сумма, то ее можно указать, по умолчанию она будет высчитана заново, после чего будет выдан итог (рис. 5).

Рисунок 4

Рисунок 4

Рисунок 5

Рисунок 5

Нажав Add Image, можно добавить следующий образ к базе данных. Если не нужно, то теперь можно начинать работать с образом. Например, во вкладке Image Details можно сразу извлечь все строки или удаленные файлы в отдельный файл (рис. 6). А переходя к нужному пункту, можно получить всю необходимую информацию о данных, содержащихся в тех или иных блоках (рис. 8, 8а), причем обратите внимание, доступен вывод информации в нескольких видах (ASCII, Hex, String), добавление комментария к интересному блоку, последовательный просмотр блоков, экспорт блока в отдельный файл. Аналогично можно вывести список файлов (рис. 9), данные о состоянии дисковых inode (рис. 10, 11) и другую информацию, которую можно получить при помощи утилит Sleuth Kit.

Рисунок 6

Рисунок 6

Рисунок 7

Рисунок 7

Рисунок 8

Рисунок 8

Рисунок 8a

Рисунок 8a

Рисунок 9

Рисунок 9

Рисунок 10

Рисунок 10

Рисунок 11

Рисунок 11

Если первоначальная возня с образами мне не очень понравилась, зато последующая работа оставила приятное впечатление, все-таки намного удобнее пользоваться Autopsy Forensic Browser, по крайней мере возможность выбора меня всегда радует.

Описанные выше утилиты относятся к так называемым forensic, т.е. применяются для поиска доказательств взлома, которые затем могут быть представлены в суде. Поэтому одним из требований к ним является особо бережное отношение к данным и протоколирование всех действий. Также, чтобы затем не замучили адвокаты, подобные утилиты проходят тщательное тестирование на предмет соответствия поставленной задаче. Для нас подобные разбирательства скорее исключение, чем правило, хотя, правда, это не значит, что хакеры у нас не водятся. Водятся, и в больших количествах.

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

Литература

  1. Мешков В. Архитектура файловой системы ext2. – Журнал «Системный администратор». №11(12), ноябрь 2003 г., – 26-32с.

Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru