Примечание к первым частям:
перед переносом цифровых данных со
взломанной машины необходимо запустить «правильный»
шелл, которому можно доверять. Так что
необходимо скомпилить например bash и
записать его на диск, а потом на машине
делать так:

(compromised)# /mnt/cdrom/bash

6. Память

Один из шагов, которых нужно предпринять
для сохранения данных — сделать полный дамп
памяти. Можно получить доступ к физической
памяти просто скопировав устройство /dev/mem
или файл kcore (его можно найти в
смонтированной /proc директории). Размер
файла точно соответствует физической
памяти + 4 Кб. Преимущество kcore заключается в
том, что файл  представлен в ELF формате,
так что его можно потом будет просмотреть gdb
(неплохая утилита для анализа кода или
памяти). Однако для первичного анализа
предлагаю использовать более
универсальные утилиты, например текстовые
или hex редакторы.

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

Вот пример того, как скопировать память
используя /proc:

(remote)#nc -l -p port > kcore_compromised
(compromised)#/mnt/cdrom/dd < /proc/kcore | /mnt/cdrom/nc (remote) port
(remote)#md5sum kcore_compromised > kcore_compromised.md5

В данном случае мы копируем всю память,
целиком. Дальше попытаемся сделать все по
уму, но пока оставим все как есть, так как
там есть и свои подводные камни.

7. Список модулей ядра

(remote)# nc -l -p port > lkms_compromised
(compromised)#/mnt/cdrom/cat /proc/modules | /mnt/cdrom/nc (remote) port
(remote)# nc -l -p port > lkms_compromised.md5
(compromised)# /mnt/cdrom/md5sum /proc/modules | /mnt/cdrom/nc (remote) port

К сожалению, некоторые модули невозможно
увидеть. Для подтверждения информации,
полученной из /proc/modules,  я использую метод,
описанный в последнем Phrackе: «Finding hidden kernel
modules (the extrem way)». Для этого используется
тулза hunter:

(compromised)#/mnt/cdrom/insmod -f /mnt/cdrom/hunter.o

Ключ -f  в данном случае использовался
из-за несовпадения версий ядра
скомпрометированной системы и той, на
которой hunter компилировался. если известна
версия ядра, то конечно лучше скачать
правильные исходники и перекомпилировать
утилиту. Продолжим:

(remote)#nc -l -p port > modules_hunter_compromised
(compromised)#/mnt/cdrom/cat /proc/showmodules && /mnt/cdrom/dmesg | /mnt/cdrom/nc
(remote) port
(remote)#md5sum modules_hunter_compromised > modules_hunter_compromised.md5

Теперь можно сравнить результаты, обратив
внимание на размеры модулей — в некоторых
случаях вредоносный код может «приклеиваться»
к совершенно законному модулю.

Ну и последняя вещь — скопировать
экспортные переменные. Анализируя файл ksyms
иногда можно обнаружить присутствие
взломщика в системе:

(remote)#nc -l -p port > ksyms_compromised
(compromised)#/mnt/cdrom/cat /proc/ksyms | /mnt/cdrom/nc (remote) port
(remote)# nc -l -p port > ksyms_compromised.md5
(compromised)#/mnt/cdrom/md5sum /proc/ksyms | /mnt/cdrom/nc (remote) port

Конечно, можно использовать и другие
утилиты для поиска «ненужных» модулей,
такие как например kstat или kern_check, однако все
они использую System.map файл. Этот файл
генерится при компиляции ядра, так что
если нет его копии или контрольной суммы, то
доверия ему мало. В общем говоря даже если
даже он правильный, то хакер может
использовать иные методы сокрытия
вредоносного кода в памяти ядра.

8. Список активных процессов

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

(remote)#nc -l -p port > lsof_compromised
(compromised)#/mnt/cdrom/lsof -n -P -l | /mnt/cdrom/nc (remote) port
(remote)#md5sum lsof_compromised > lsof_compromised.md5

Можно проанализировать полученные данные.
Если какой-либо из процессов кажется
подозрительным, то самое время скопировать
его. К тому же, если мы увидим, что программа,
инициализировавшая процесс была удалена
взломщиком, есть шанс восстановить ее. Об
этом поговорим позже. 

Вот примеры подозрительных вещей:

  • Процесс, слушающий на нетипичном TCP/UDP
    порту или открывший raw socket
  • Процесс, имеющий активное соединение с
    удаленным хостом. 
  • Программа, которая была запущена, а
    потом удалена
  • Файл, открытый процессом, удален (например
    log файл)
  • Процесс со странным именем
  • Процесс, инициированный несуществующим
    или непривилегированным пользователем

9  Сбор данных о подозрительных
процессах

Я использую pcat для копирования всей
памяти процесса.

(remote)#nc -l -p port > proc_id_compromised
(compromised)#/mnt/cdrom/pcat proc_id | /mnt/cdrom/nc (remote) port
(remote)#md5 proc_ip_compromised > proc_ip_compromised.md5

10. Полезная информация

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

Команда Описание
/mnt/cdrom/cat /proc/version Версия ОС
/mnt/cdrom/cat /proc/sys/kernel/name Имя хоста
/mnt/cdrom/cat /proc/sys/kernel/domainame Имя домена
/mnt/cdrom/cat /proc/cpuinfo Информация о железе
/mnt/cdrom/cat /proc/swaps Все swap партиции
mnt/cdrom/cat /proc/partitions Все локальные партиции
/mnt/cdrom/cat /proc/self/mounts Смонтированные файловые системы
mnt/cdrom/cat /proc/uptime Время работы

11. Время

(remote)#nc -l -p port > end_time
(compromised)# /mnt/cdrom/date | /mnt/cdrom/nc (remote) port

Наконец мы подошли к той точке, когда уже
можно выключить взломанную систему. Нельзя
выключать ее при помощи shutdown или init, просто
выдергивайте питание.

Оставить мнение

Check Also

Espruino Pico. Учимся программировать USB-микроконтроллер на JavaScript и делаем из него токен авторизации

Несмотря на огромное количество устройств на базе микроконтроллеров, созданных на волне ус…