Выявляем остаточную информацию, чтобы восстановить картину взлома системы

Не смотря на разнообразие средств защиты, с каждым годом количество взломов все возрастает. После того, как был выявлен факт компрометации системы, можно, конечно, сразу отформатировать диски и восстановить ее с нуля, но где гарантия, что атака не повторится, а в бэкапе нет закладок? Чтобы в последствии избежать проблем, следует досконально выяснить, что и как произошло. Forensic инструменты помогут нам в этом.

Первые шаги

Самой распространенной ошибкой при обнаружении взлома является немедленное удаление всех (в том числе скомпрометированных) данных и восстановление работоспособности при помощи резервных копий. Сначала необходимо собрать наиболее полную информацию об инциденте. Кроме системных журналов, в поиске проблемы очень помогают системы аудита (auditd, SNARE), контроля целостности файлов (tripwire, AIDE, Afick), IPS, вроде Snort, и пакеты, захваченные tcpdump. С помощью этих средств можно узнать, когда и где происходило нужное событие, как все произошло, на какие файлы воздействовали и т.п. Следующий шаг — осторожно извлекаем подозрительную информацию и анализируем. Исследователя интересуют файлы, к которым мог иметь доступ взломщик, процессы и сетевые соединения. Непосредственно файлы могут быть доступны и в оффлайн режиме (например, загружаемся с Live диска и проводим исследование), а информацию о процессах и сети можно получить только на живой системе.
Стандартные инструментальные средства, полагающиеся на API или системные команды, не подходят для подобного рода исследований, поскольку они могут быть запросто обмануты руткитом. Специальные решения позволяют увидеть и восстановить удаленные или спрятанные файлы, исследовать процессы и состояние ОЗУ. В настоящее время разработано множество средств для анализа остаточных данных (Forensic Analysis), конкретный выбор в первую очередь зависит от используемой ОС и личных предпочтений. Удобно применять готовые дистрибутивы на базе *nix, авторы которых предлагают полный набор специфических утилит «из коробки» и специальные режимы загрузки ОС, обеспечивающие неприкосновенность файлов и минимизацию влияния на имеющиеся носители (блокируется работа с блочными устройствами, отключается создание раздела подкачки, автоопределение LVM, RAID, проверяются контрольные суммы для файлов на загрузочном CD).

Анализируем файловую систему

Для поиска спрятанных данных на харде наиболее популярны утилита foremost (foremost.sourceforge.net) и комплект The Sleuth Kit (TSK, sleuthkit.org/sleuthkit). Последний состоит из 27 утилит и позволяет анализировать диски напрямую или через снимки. Поддерживает все популярные файловые системы: NTFS, FAT, UFS1/2, EXT2/3/4, HFS, ISO 9660 и YAFFS2. Большим плюсом TSK является наличие интерфейса Autopsy, позволяющего производить все операции в удобной среде. Стоит отметить, этот комплект интегрирован в некоторые другие forensic инструменты — Scripts4CF (scripts4cf.sf.net), Allin1 (netmon.ch/allin1.html), revealertoolkit (code.google.com/p/revealertoolkit), SFDUMPER (sfdumper.sf.net).
Утилит много, но запутаться в их назначении сложно. Чтобы легче было ориентироваться, первая буква в названии указывает, на каком уровне они работают:

• f — работа с файловой системой
• blk — фактическое содержание блоков, кластеров, фрагментов
• i — inode
• mm — media management
• h — более удобный уровень взаимодействия с файлами, чем при использовании метаданных
• j — журнал

В спецдистрибутивах все они уже рассортированы по разделам меню, поэтому найти их легко.
Снять образ файловой системы можно при помощи утилиты dd, которая входит в стандартную поставку всех *nix. Но лучше использовать специализированные утилиты. Например, патченую версию dd — dc3dd (dc3dd.sf.net), умеющую вычислять на лету хэш-функции, соединять выходные файлы, проверять файлы, зачищать место и многое другое.

$ dc3dd progress=on if=/dev/sda of=fs.img

Теперь данные никуда не денутся, и их можно исследовать. Утилита mmls позволяет вывести таблицу разделов и найти неиспользованные сектора, которые не показывает `fdisk -l`. Они могут появляться как в следствие атак, так и в случае ошибок работы программ разметки диска.

$ mmls -t dos fs.img

Смотрим статистику по образу и файловым системам, занятым и свободным блокам:

$ img_stat fs.img
$ fsstat fs.img

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

$ ils fs.img

Теперь приступаем к исследованию. При помощи утилиты mactime нам нужно узнать, какие inode изменялись с определенного времени или в интересующем нас интервале. На вход необходимо подать файл, созданный при помощи `ils -m` или `fls -m`.

$ ils fs.img -m > macfile
$ mactime 2013-10-20 -b macfile

Для удобства просмотра и отбора можно использовать GUI к mactime (blog.devilzgsa.com/mactime-frontend-gui). Полученные данные потребуют дальнейшего анализа, но если в требуемый период изменен системный файл, то это должно вызвать как минимум подозрение. Его можно, например, сравнить с аналогичным «чистым» файлом, взятым с другого компьютера.

Спасаем файлы

На данный момент обладаем информацией о подозрительных inodes. Используя icat, можем скопировать файл по номеру inode.

$ icat -i raw -rf ext3 fs.img 100 > delete_file

Теперь при помощи команды `file delete_file` узнаем, что это за файл. При удачном стечении обстоятельств, восстановленный таким образом бинарник без проблем выполняется. Натравив grep, можем попробовать найти нужные ключевые слова (вроде password, login). Кстати, команда `img_cat fs.img` позволяет вывести контент всего диска или определенной части (оставив метаданные), преобразовав его из raw, правда, искать в этой куче очень тяжело.
Написав небольшой скрипт, можно попытаться восстановить все удаленные файлы.

ils fs.img | awk -F '|' '($2=="f") {print $1}' | while read i; do icat -r fs.img $i > ./deleted/$i; done

Итак, мы нашли и спасли несколько удаленных файлов, чтобы получить больше информации, используем istat.

$ istat fs.img 100

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

$ blstat -f ext3 fs.img 1000
Fragment: 1000
Allocated (Meta)
Group: 0

Теперь при помощи blkcat мы можем прочитать, что записано в этом блоке или секторе. Поддерживается несколько форматов вывода: raw, текст ASCII (-а), hexdump (-h), выводить статистику (-s), просматривать файл подкачки (-f swap), HTML (-w) и другие.

$ blkcat -h fs.img 10200

Если известен номер блока и требуется найти номер inode, за которым данный блок «закреплен», используем ifind. Имя файла по известному inode определяется при помощи ffind.

Искать вручную каждый файл долго, здесь проще использовать утилиту fls, которая выведет имена файлов, в том числе удаленных. Она имеет множество полезных параметров. Так ‘-a’ выведет имена файлов, начинающиеся с точки, ‘-d’ и ‘-D’ — вывод только удаленных файлов и каталогов, ‘-l’ (long) — подробная информация, ‘-r’ — рекурсивный обход.

$ fls -rdl fs.img

Все удаленные файлы и каталоги помечаются знаком *. Первая буква показывает, что это за файл, т.е. r-egular, d-irectory, l-ink, s-ocket или не определен (?).
Возможности утилиты foremost в чем-то повторяют TSK, особенно она удобна в том случае, если действительно знаешь, что искать. Параметры работы настраиваются в /etc/foremost.conf, но после установки там можно пока ничего не трогать. Например, нам нужны все удаленные файлы в образе (параметр ‘-T’ позволяет автоматически создать выходной каталог):

$ foremost -Tt all -o ./output -i fs.img

В output найдем восстановленные файлы и отчет.

Анализируем данные

Анализ собранной информации целиком возлагается на плечи исследователя, и, чтобы найти в гигабайтах информации что-то полезное, необходим опыт и время. Здесь может помочь утилита hfind, сравнивающая хэш-функции файлов с базой библиотеки софта NSRL (National Software Reference Library, www.nsrl.nist.gov), в которой содержатся профили известного ПО.
Cкрипт sorter из состава TSK анализирует образ, запуская fls и icat, находит любые файлы, определяя их тип при помощи file, и сравнивает их с библиотекой NSRL, позволяя распознать потенциально опасные.

$ sorter -d output -f ext3 fs.img

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

Специальные дистрибутивы
Самой простой способ приступить к исследованию — воспользоваться одним из специализированных дистрибутивов, в которых собраны все необходимые утилиты. Выбор здесь очень большой: DEFT Linux (deftlinux.net), CAINE (Computer Aided INvestigative Environment, caine-live.net), SMART Linux (goo.gl/H3JCfD), Kali (ранее BackTrack, kali.org), SIFT (SANS Investigate Forensic Toolkit, computer-forensics.sans.org), (PLAC, Portable Linux Auditing CD, plac.sf.net), REMnux (zeltser.com/remnux) и базирующийся на FreeBSD Snarl (snarl.eecue.com). Каждый из них имеет свои особенности.
Например, REMnux, построенный на пакетной базе Ubuntu и обладающий интерфейсом Enlightenment, предназначен для изучения и обратного инжиниринга кода вредоносных программ. Он позволяет создать изолированное окружение, в котором можно эмулировать работу атакуемого сетевого сервиса и изучать поведение вредоносного ПО, например поведение вредоносных вставок на веб-сайтах, реализованных на JavaScript, Java или Flash. В комплекте полная подборка инструментов для анализа вредоносного ПО, утилит для проведения обратного инжиниринга кода, программ для изучения модифицированных злоумышленниками PDF и офисных документов, средств мониторинга активности в системе.

Kali Linux имеет специальный режим загрузки

 

Собираем информацию о состоянии ОЗУ

Найти крошечный зловред на терабайтном харде это все равно, что иголку в стогу сена. Оперативная память компьютера на порядок меньше по объему, и ее анализ может значительно сократить время исследования. Например, некоторые типы вирусов живут только в ОЗУ, а тело на диске нередко шифруют, поэтому данные можно найти только на живой системе. В Linux стандартные утилиты ps, netstat и lsof позволяют собрать общую информацию о процессах и сетевых соединениях, но ее не всегда достаточно, поскольку зловред может скрывать от них свое присутствие.
Модуль ядра fmem (hysteria.sk/~niekt0/fmem/) создает псевдоустройство /dev/fmem, через которое можно получить доступ к содержимому ОЗУ. Кроме того, есть memfetch (lcamtuf.coredump.cx), memgrep (hick.org) и LiME (Linux Memory Extractor, code.google.com/p/lime-forensics), позволяющие легко сбросить дамп всех запущенных процессов.
В дистрибутивах вроде Kali предлагается фреймворк Volatility (volatilesystems.com/default/volatility), заменяющий, по сути, целый набор инструментов для исследования «артефактов» в ОЗУ. Volatility позволяет получить информацию о процессах, идентификаторах, переменных, открытых сокетах, библиотеках, состоянии памяти каждого процесса, таблицы системных вызовов, хэши LM/NTLM и многое другое.
Изначально Volatility работал только в Windows, но сегодня поддерживает и Linux. Захват производится через псевдоустройство /dev/pmem, которое создается путем активации модуля ядра pmem.ko. Хотя собрать модуль в современных дистрибутивах не всегда получается. Кроме того, сами разработчики в документации проекта рекомендуют для дампа использовать модуль LiME.
Каждая версия ОС Windows и ядра Linux по разному работает с памятью, поэтому для упрощения анализа в Volatility используются профили. Для Win XP-7 профили обычно идут в комплекте. Профиль для Linux состоит из System.map (соответствует текущему ядру) и отладочной информации modules.dwarf, извлекаемой при помощи dwarfdump. При самостоятельной сборке Volatility они создаются автоматически.
В Kali и других специальных дистрибутивах нужный пакет уже есть. В Ubuntu следует подключить репозитарий security, после чего установить python-volatility и volatility-extras. Все файлы обычно находятся в /usr/share/volatility, в том числе и сам скрипт vol.py (для удобства создается /usr/bin/vol, содержащий команду для запуска). Но профиль и модуль не собираются.

$ sudo apt-get install linux-headers-`uname -r`
$ cd volatility/tools/linux
$ make

Получаем файл module.dwarf. Создаем профиль.

$ sudo zip ../volatility/plugins/overlays/linux/Ubuntu1310.zip module.dwarf /boot/System.map

Чтобы проверить все доступные профили и модули, достаточно просмотреть вывод `vol —info` и `vol -?`.
Получаем информацию о дампе и смотрим список открытых сокетов, процессов, команд и параметров реестра Windows, найденных в ОЗУ виртуальной машины VMware:

$ vol imageinfo -f ./win.vmem
$ vol sockets -f ./win.vmem
$ vol psxview -f ./win.vmem
$ vol cmdscan -f ./win.vmem
$ vol hivelist -f ./win.vmem

Альтернативы Volatility
К сожалению, Volatility будет работать только на x86 совместимых устройствах (Linux и Windows), на платформах, в которых отсутствует функция «page_is_ram» (например ARM Android), запуск приведет к ошибке. Для Android разработан специальный инструмент LiME (Linux Memory Extractor, code.google.com/p/lime-forensics), который может быть использован и для снятия дампа в Linux. В качестве альтернативы анализа содержимого подойдет скрипт Draugr (code.google.com/p/draugr), исследующий /dev/(k)mem и дамп ОЗУ на наличие совпадений с паттернами. Проект fmem предлагает и свою утилиту foriana (hysteria.sk/~niekt0/foriana), способную, используя логические связи, извлечь списки процессов и состояние ОЗУ.
Но наиболее популярная и известная альтернатива Volatility — Volatilitux (code.google.com/p/volatilitux), появившийся в те времена, когда Volatility работал только под Windows. Сам Volatilitux работает не только в Linux, но и Android (ARM), что позволяет использовать его для исследований на смартфонах и планшетах. По функциям он не достает до всех возможностей Volatility, поддерживает всего 5 параметров: filedmp (дамп открытого файла), filelist (вывод списка файлов, открытых процессом), memdmp (дамп памяти процесса), memmap (вывод карты памяти процесса) и pslist (список процессов). Хотя у Volatilitux есть свои особенности, которых не хватает Volatility. Это способность автоматически обнаруживать структуры ядра, без использования профилей. А в случае неудачи такого исследования создается файл, содержащий информацию о разметке памяти. Инструмент очень прост в использовании. Например, чтобы получить список процессов из дампа, вводим команду «volatilitux.py -f mem.dd pslist».

Заключение

Конечно, исследование скомпрометированной системы — дело очень кропотливое, требующее подготовки, времени и должного внимания, но при некотором везении можно найти источник проблем и даже самостоятельно создать сигнатуру для антивируса ClamAV или правило для IPS Snort.

http://www.tux.in.ua/articles/3628