11.05.2005

Противодействие Honeypots: Системные вопросы, часть первая

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

Торстен Хольц и Фредерик Рейнел, перевод Владимир Куксенок

Введение

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

Эта статья описывает методы обнаружения и атаки на honeypot. Мы опишем несколько известных техник (или возможно неизвестных) и расскажем о некоторых утилитах, помогающих хакерам обнаруживать и атаковать электронную приманку. Аудитория статьи – группы и отдельные личности, которые хотели бы установить или усилить существующие, основанные на дезинформации, линии защиты, но в настоящее время ограничены в возможности самостоятельного исследования honeypot-технологий. После краткого теоретического введения, мы представим несколько примеров использования различных техник. Эта статья, состоящая из двух частей, фокусируется на уровне системы и приложений, в отличии от первой статьи “Противодействие Honeypots: Сетевые вопросы” [ссылка 1], в которой рассматривался сетевой уровень.

Электронные приманки и Стеганография

Перед тем как двигаться дальше, мы скажем пару слов о стеганографии. Ее предназначение состоит в скрытие наличия канала связи для всех, кроме получателя сообщения. Как искусство и науку стеганографию стали признавать несколько лет назад, когда Симонс обозначил классическую “проблему заключенных” [ссылка 2]. Предполагается, что два заключенных находятся в различных камерах. Сообщения от одного к другому переправляет надзиратель. Если сообщения будет зашифровано, что означает, что надзиратель не сможет понять содержание сообщения, у него появятся подозрения и канал связи будет закрыт. Но если заключенные договорились о каком-либо коде (например, красное солнце на картинке означает одно, а желтое - другое), скрытое сообщение не будет замечено надзирателем, и заключенные будут иметь шанс тайно составить план побега.

Если мы настроим honeypot с высокой степенью взаимодействия, мы будем надеяться получить как можно больше информации о деятельности атакующего. Даже если он поймет, что атакует приманку, его действия после этого также будут ценной информацией. Итак, электронная ловушка должны быть скрытой, но не обязательно скрытой на 100%.

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

С тех пор как электронные приманки стали устанавливать в Интернете, все больше и больше утилит стали включать в себя автоматизированных средства опознавания подозрительных сред. Одной из первых такая техника была применена в сетевом черве AgoBot (также известном как Gaobot) [ссылка 3].

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

Утилиты

Многие утилиты позволяют создать honeypot с высокой степенью взаимодействия. Мы рассмотрим самые известные и покажем вам, из чего состоит Матрица.

User Mode Linux (UML)

Некоторые люди пытаются использовать UML [ссылка 4] в качестве электронной приманки, но чтобы оценить его эффективность, нам нужно вначале понять, что представляет из себя UML. Если кратко, то UML позволяет использовать Linux-систему, запущенную внутри другой Linux-системы. Назовем основное ядро Linux host kernel (или host OS), а систему, запускаемую по команде linux, будем называть guest OS. Она запускается “под” основным ядром в адресном пространстве пользователя. Обратите внимание, UML это всего лишь модифицированное ядро Linux, способное работать в режиме пользователя. Таким образом, вам нужно только предоставить файловую систему, содержащую нужные вам приложения.

По умолчанию UML запускается в режиме TT (Tracing Thread). Один главный поток ptrace()-ит каждый новый процесс, запущенный в guest OS. В host OS вы можете увидеть это с помощью утилиты ps:
host$ ps a
[...]
 1039 pts/6    S      0:00 linux [(tracing thread)]
 1044 pts/6    S      0:00 linux [(kernel thread)]
 1049 pts/6    S      0:00 linux [(kernel thread)]
 1051 pts/6    S      0:00 linux [(kernel thread)]
 1053 pts/6    S      0:00 linux [(kernel thread)]
 1055 pts/6    S      0:00 linux [(kernel thread)]
 1057 pts/6    S      0:00 linux [(kernel thread)]
 1059 pts/6    S      0:00 linux [(kernel thread)]
 1061 pts/6    S      0:00 linux [(kernel thread)]
 1063 pts/6    S      0:00 linux [(kernel thread)]
 1064 pts/6    S      0:00 linux [(kernel thread)]
 1065 pts/6    S      0:00 linux [(kernel thread)]
 1066 pts/6    S      0:00 linux [(kernel thread)]
 1068 pts/6    S      0:00 linux [/sbin/init]
 1268 pts/6    S      0:00 linux [ile]
 1272 pts/6    S      0:00 linux [/bin/sh]
 1348 pts/6    S      0:00 linux [dd]
[...]
Выше вы можете увидеть главный поток (PID 1039) и несколько потоков, которые он ptrace()-ит: несколько потоков ядра (PID 1044-1066), init (PID 1068), ile (PID 1268), командный интерпретатор (PID 1272) и dd (PID 1348).

Вы можете быстро обнаружить, что по умолчанию UML не спроектирован для скрытой работы.

<
uml$ dmesg
Linux version 2.6.10-rc2 (wstearns@sparrow.stearns.org) 
(gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)) #1 Tue Nov 16 01:43:27 EST 2004
On node 0 totalpages: 8192
...
Kernel command line: ubd0=/home/raynal/MISC/uml/FS/debian.ext3 
					 eth0=tuntap,tap0
root=98:0
PID hash table entries: 256 (order: 8, 4096 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
...
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...missing
Checking that host ptys support output SIGIO...Yes
Checking that host ptys support SIGIO on close...No, enabling workaround
Checking for /dev/anon on the host...Not available 
(open failed with errno 2)

NET: Registered protocol family 16
mconsole (version 2) initialized on /home/raynal/.uml/Es5BHO/mconsole
UML Audio Relay (host dsp = /dev/sound/dsp, host mixer = /dev/sound/mixer)
Netdevice 0 : TUN/TAP backend -
divert: allocating divert_blk for eth0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Coda Kernel/Venus communications, v6.0.0, coda@cs.cmu.edu
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
...
Initializing software serial port version 1
 /dev/ubd/disc0: unknown partition table

Initializing stdio console driver
...
Красные строки характерны для UML в режиме по умолчанию. Также обратите внимание, что сетевое устройство 0 использует TUN/TAP (отмечено синим цветом), что являлось бы необычным на реальной системе.

Одна из больших проблем UML – использования виртуального устройства ubd*, вместо реального жесткого диска. Если вы посмотрите на /etc/fstab, выполните команду mount или проверите директорию /dev/ubd, вы поймете, что находитесь в UML-системе. Чтобы скрыть эту информацию, можно запустить UML с параметрами fake_ide и fakehd. Но не забывайте, что на самом деле корневой раздел UML будет иметь тип 98 (0x62).

Также UML может быть легко идентифицирован после просмотра /proc. Большинство файлов этой директории при детальном осмотре будут указывать на UML:
$ cat /proc/cpuinfo
processor      : 0
vendor_id      : User Mode Linux
model name     : UML
mode           : tt
[...]

$ cat /proc/devices
[...]
Block devices:
[...]
 60 cow
 90 ubd

$ cat /proc/filesystems
[...]
nodev   hostfs

$ egrep -i "uml|honey" /proc/ksysms
a02eb408 uml_physmem
a02ed688 honeypot
Кроме этого, подозрительно выглядят iomem, ioports, interrupts и многие другие файлы. Для противодействия этому способу идентификации UML вы можете использовать hppfs (Honeypot procfs [ссылка 5]) и настраивать содержимое директории /proc.

Еще один способ идентификации UML – адресное пространство процесса. На host OS адресное пространство выглядит следующим образом:

host$ cat /proc/self/maps
08048000-0804c000 r-xp 00000000 03:01 1058722   /bin/cat
0804c000-0804d000 rw-p 00003000 03:01 1058722  /bin/cat
0804d000-0806e000 rw-p 0804d000 00:00 0
b7ca9000-b7ea9000 r--p 00000000 03:01 171     /usr/lib/locale/locale-archive
b7ea9000-b7eaa000 rw-p b7ea9000 00:00 0
b7eaa000-b7fd3000 r-xp 00000000 03:01 781848  /lib/tls/i686/cmov/libc-2.3.2.so
b7fd3000-b7fdb000 rw-p 00129000 03:01 781848  /lib/tls/i686/cmov/libc-2.3.2.so
b7fdb000-b7fde000 rw-p b7fdb000 00:00 0
b7fe9000-b7fea000 rw-p b7fe9000 00:00 0
b7fea000-b8000000 r-xp 00000000 03:01 782112  /lib/ld-2.3.2.so
b8000000-b8001000 rw-p 00015000 03:01 782112  /lib/ld-2.3.2.so
bfffe000-c0000000 rw-p bfffe000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
Для сравнения, адресное пространство guest OS выглядит примерно так:
uml:~# cat /proc/self/maps
08048000-0804c000 r-xp 00000000 62:00 9957    /bin/cat
0804c000-0804d000 rw-p 00003000 62:00 9957    /bin/cat
0804d000-0806e000 rw-p 0804d000 00:00 0
40000000-40016000 r-xp 00000000 62:00 13907   /lib/ld-2.3.2.so
40016000-40017000 rw-p 00015000 62:00 13907   /lib/ld-2.3.2.so
40017000-40018000 rw-p 40017000 00:00 0
4001b000-4014b000 r-xp 00000000 62:00 21846   /lib/tls/libc-2.3.2.so
4014b000-40154000 rw-p 0012f000 62:00 21846   /lib/tls/libc-2.3.2.so
40154000-40156000 rw-p 40154000 00:00 0
9ffff000-a0000000 rw-p 9ffff000 00:00 0
beffe000-befff000 ---p 00000000 00:00 0
Нужно обратить внимание на верхний адрес, указывающий на конец стека (забудьте об отображении динамических библиотек). В зависимости от объема памяти на вашем компьютере, этот адрес обычно имеет значении 0xc0000000. Однако, на UML он равен 0xbefff000. Фактически адресное пространство между 0xbefff000 и 0xc0000000 это отображение ядра UML в памяти. Это означает, что любой процесс может иметь доступ, изменять и делать с ядром UML все, что пожелает.

Для устранения большинства этих проблем вы можете запустить UML с параметром honeypot [ссылка 6, ссылка 7] или в режиме skas (Separate Kernel Address Space) [ссылка 8]. Однако, в режиме skas ядро ведет себя нестабильно (приостановки процессов и многое другое, что ведет к перезагрузке).

VMware

VMware очень эффективная виртуальная машина, эмулирующая x86-систему. Таким образом, вы можете установить почти любую ОС, от Linux или Windows до Solaris 10.

Первым шагом обнаружения VMware будет анализ аппаратных средства, которые виртуальная машина пытается эмулировать. До версии 4.5 некоторые части эмулируемого аппаратного обеспечения были не настраиваемыми:
  • Видео карта: VMware Inc [VMware SVGA II] PCI Display Adapter,
  • Сетевая карта: Advanced Micro Devices [AMD] 79c970 [PCnet 32 LANCE] (rev 10),
  • Имена IDE и SCSI устройств: VMware Virtual IDE Hard Drive, NECVMWar VMware IDE CDR10, VMware SCSI Controller.
Однако, есть патч для исполняемого файла VMware, изменяющий эти стандартные значения. Костя Корчинский (Kostya Kortchinsky) из французского проекта Honeynet написал такой патч, способный устанавливать некоторые другие значения этим параметрам. Этот патч публично доступен [ссылка 9].

Кроме того, исполняемый файл VMware имеет встроенное средство управления через порты ввода/вывода (I/O backdoor), используемое для настройки VMware в процессе работы. Следующие инструкции используются для вызова функций управления:

MOV EAX, 564D5868h                    ; Magic Number
MOV EBX, COMMAND_SPECIFIC_PARAMETER
MOV ECX, BACKDOOR_COMMAND_NUMBER
MOV DX, 5658h                         ; Port Number

IN EAX, DX
Вначале в регистр EAX помещается “магическое” число, которое используется для аутентификации команд. В регистре EBX хранятся параметры команд. Сами команды загружаются в ECX. В следующей таблице дан краткий обзор некоторых команд:

Номер
команды
Описание
00h..03h ?
04h Получить текущее положение курсора
05h Установить текущее положение курсора
06h Получить объем данных в буфере обмена хоста
07h Прочитать данные из буфера обмена хоста
08h Установить объем данных, отсылаемый в буфер обмена хоста
09h Отправить данные в буфер обмена хоста
0Ah Получить версию VMware
0Bh Получить информацию об устройстве

Всего поддерживается как минимум 15 команд. В регистре DX содержится номер порта ввода/вывода и с помощью инструкции IN команда исполняется. Ясно, что с помощью VMware I/O backdoor можно вмешиваться в работу запущенного VMware.

С помощью патча Кости Корчинского вы можете изменить “магическое” число и таким образом скрыть возможность управления VMware через порты ввода/вывода от атакующего. Также доступна более подробная информация о VMware backdoor [ссылка 10].

Обнаружение дополнительных линий защиты: chroot и jails

Утилита chroot() никогда не разрабатывалась для решения задач безопасности, но она часто необходима для защиты важных серверов. Обнаружение, что вы находитесь в chroot-окружении, или обход его, является не сложной задачей.

Если chroot-директория находится на определенном разделе и не помещена в его начало, номера inode не такие, какие должны быть у реального корневого каталога:
# ls -ial /
2 drwxr-xr-x  24 root root   4096 2004-11-30 08:14 .

2 drwxr-xr-x  24 root root   4096 2004-11-30 08:14 ..
...
Здесь inode директорий . и .. одинаковые и равны 2 (что является нормальным значением для корневой директории раздела). Для текущей директории мы получили следующие результаты:
# ls -ail .
1553552 drwxr-xr-x   6 raynal users   4096 2004-12-14 13:58 .
6657574 drwxr-xr-x   6 raynal raynal  4096 2004-12-12 16:25 ..
Затем, когда мы выполнили команду chroot для текущей директории, мы получаем те же самые inode-номера:
# chroot . /bin/busybox
BusyBox v0.60.5 (2004.10.29-22:08+0000) multi-call binary
# ls -ial

1553552 drwxr-xr-x    6 1000     100          4096 Dec 14 12:58 .
1553552 drwxr-xr-x    6 1000     100          4096 Dec 14 12:58 ..
Несмотря на то что .. был изменена на соответствие директории . , значения inodes все еще не соответствуют ожидаемым.

Заметьте, существует намного больше способов идентификации нахождения в chroot. Например, вы можете послать сигналы любому процессу вне chroot или подключиться к внешним процессам с помощью ptrace(). С тех пор как ptrace() может быть вызван из chroot для любого процесса вне chroot, атакующий получил простой способ внедрения чего-либо на хост. Подобные проблемы присутствуют в mount(), fchdir(), sysctl() и многих других функциях [ссылка 11].

Когда мы размышляем о виртуальных средах и безопасности, становится ясно, что chroot() это не то, на что можно положиться. Другой вариант создания ограничений, присутствующий в FreeBSD, базирующийся на chroot(), но более надежный, это jail(). Этот инструмент позволяет создавать виртуальные хосты, привязанные к IP адресу, с собственными утилитами, пользователями и т.д. Данный механизм очень удобен для создания виртуального хостинга, но также может использоваться для построения электронных приманок.

Однако, несмотря на то, что jail() во FreeBSD более надежен, это не значит, что его применение сложнее обнаружить. Есть несколько приемов, позволяющих определить, находитесь ли вы в jail.

  • Все процессы в jail имеют специфичный флаг ‘J’, как показано ниже:
    jail# ps
    PID  TT  STAT      TIME COMMAND
    6908  p0  SJ     0:00.02 /bin/sh
    6910  p0  R+J    0:00.00 ps
    

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

  • Номер inode не равен 2, как должно было бы быть.
  • По умолчанию, создание “сырых” сокетов запрещено, как это показано ниже:
    
    jail# ping -c 3 miscmag.com
    ping: socket: Operation not permitted
    

    Имейте в виду, что в последних версиях FreeBSD этот параметр стал настраиваемым.

  • Сбор (sniffing) пакетов в jail позволяет перехватывать весь трафик, идущий через устройство. Это нормально, так как при создании jail используется псевдоним (alias) реального устройства.
  • Существуют еще несколько методов, которые здесь рассматриваться не будут.
В этом разделе мы сосредоточились на обнаружении сред, созданных с помощью chroot() и jail(). Но, именно они ли создают главные проблемы для хакера в honeypot? Знание того, что он находится на хосте с ограниченными правами не так важно, если система находится в интернет. Реальная угроза здесь – возможность использования honeypot-системы для противоправных действий против других пользователей сети. В настоящее время есть очень немного систем (если вообще есть), сочетающих ограничение потенциально опасных действий и сокрытие истинной цели электронной приманки.

Завершение первой части

В первой части этой серии из двух статей мы сравнили электронные приманки – honeypots со стеганографией и рассмотрели три стандартных способа создания виртуального honeypot. Мы рассмотрели слабые места каждого из этих способов (UML, VMware и chroot/jail), которые могут использоваться для их обнаружения. Ясно, что, несмотря на конкретные преимущества отдельных способов, все они могут быть легко обнаружены подготовленным хакером.

В следующей части мы продолжим обзор утилит для создания виртуальных электронных приманок, обсудив утилиту сбора данных Sebek, упомянув также способы ее обнаружения. Затем мы рассмотрим некоторые другие техники идентификации honeypot, например анализ, основанный на специфике архитектуры x86, или локальном значении времени.

Ссылки

или введите имя

CAPTCHA