Sebek 3: как отследить злоумышленника, часть 1

Автор: Raul Siles, GSE, перевод Logos

Профессионалам в области компьютерной безопасности приходится постоянно разрабатывать и внедрять новые механизмы обнаружения подозрительной активности, чтобы своевременно отследить и поймать потенциального злоумышленника. Сети Honeynet третьего поколения (GenIII) предоставляют все необходимые средства для сбора подобного рода информации на самом глубоком уровне. Sebek является основным инструментом сбора данных для третьего поколения сетей Honeynet.

В первой части нашей статьи мы рассмотрим, что такое Sebek, и чем он так привлекает специалистов по компьютерной безопасности. Мы начнем с рассмотрения возможностей последней, третьей, версии Sebek, спецификаций протокола Sebek и того, как этот инструмент интегрируется с сетями Honeynet. Вторая часть статьи кратко обсудит установку Sebek на ОС Windows и Linux. В конце мы рассмотрим патч (заплатку, исправление), написанный автором этой статьи, позволяющий не только наблюдать то, что пишет злоумышленник, но и то, что он получает в ответ.

Sebek - инструмент сбора информации, работающий в режиме ядра

После выхода в свет третьего поколения технологий проекта Honeynet (с мая 2005 года), сети Honeynet заметно улучшили свою функциональность. Это последнее поколение основано на новой версии Honeywall, именуемой Roo, и новой, третьей версии, Sebek.

Sebek (http://www.honeynet.org/tools/sebek/) является самым продвинутым и самым сложным инструментом сбора информации в проекте Honeynet. Это open-source приложение, цель которого - получить как можно больше информации об активности злоумышленника. Эту информацию Sebek получает от honeypot’ов посредством перехвата на уровне ядра специфических системных вызовов.

Sebek основан на архитектуре клиент-сервер. Клиент устанавливается на компьютерах-honeypot, а сервер располагается на Honeywall, т.е. на шлюзе, через который проходит весь honeynet-трафик. Клиент использует технологии, сравнимые с теми, которые используют руткиты уровня ядра. Sebek распространяется в виде модуля ядра Linux (LKM), в виде системного драйвера Windows и в виде патча ядра для различных *BSD-систем. Серверный модуль содержит инструменты, позволяющие собирать и отображать захваченную клиентами информацию.

Первый клиент Sebek версии 3 (3.0.3) был выпущен для Linux с версиями ядра 2.4 в мае 2005. Эта версия также содержала сервер Sebek (3.0.3). В октябре 2005 были выпущены клиенты для таких ОС, как Windows (3.0.3), Linux с ядрами 2.6 (3.1.2b) и *BSD (3.0).

Цель этой статьи – обсудить возможности новой, третьей, версии Sebek.

Новые возможности Sebek

Перехват трафика остается традиционным способом сбора информации о злоумышленнике. Однако, этот способ бесполезен, если злоумышленник шифрует передаваемые данные, и ключ шифра неизвестен.

Первая версия Sebek перехватывала все системные вызовы “read” длиной в 1 байт, что позволяло перехватывать все нажатые злоумышленником клавиши, до того как они будут зашифрованы. Эта изначальная способность Sebek была доработана во 2й версии для перехвата всех “read” вызовов. Также вторая версия позволяла восстанавливать файлы, переписанные с помощью SCP, и сообщения, отправленные по IRC или почте.

Третья версия расширяет эти возможности, перехватывая целый набор системных вызовов. Sebek также восстанавливает идентификатор родительского процесса и inode при любых действиях с файлами. Кроме стандартного перехвата системного вызова “read”, новая версия перехватывает дополнительные вызовы “read”, системный вызов “socket”, системный вызов “open”, а также вызовы “fork” и “clone”. В качестве ссылок мы будем использовать Linux версию Sebek. Эти же принципы относятся и к Windows версии.

Предыдущие версии Sebek перехватывали стандартный вызов “NR_read”. Текущая версия также перехватывает “NR_readv” и “NR_pread” вызовы, что позволяет перехватывать всю “read” активность в системе и противодействовать программам типа “sebekill” (http://ilja.netric.org/files/sebekill.c).

Системный вызов “socket” (NR_socket) отображает сетевую активность по отношению к действующим процессам. Поэтому, Sebek может собирать информацию о любых соединениях и установить их отношения с процессами на honeypot. Эта информация также поможет сопоставить данные, полученные Sebek, с трафиком, перехваченным с помощью Honeywall.

Системный вызов ”open” (NR_open) сопоставляет любые “read” действия с именами файлов и их inode. Это позволяет определить все файлы, к которым обращался злоумышленник. Запись inode требуется для обхода “dup2”-обфускации, используемой в “sepabek” (http://www.secdev.org/c/sepabek.c).

“Fork” (NR_fork и NR_vfork) и “clone” (NR_clone) вызовы следят за идентификаторами процессов (PID) и идентификаторами родительских процессов (PPID). Мониторинг создаваемых процессов позволяет определить взаимодействие между системными процессами и восстановить дерево процессов.

В ответ на появление программ, типа “NoSEBrEaK” (http://md.hudora.de/publications/2004-NoSEBrEaK.pdf), новая версия Sebek пытается предотвратить извлечение своего внутреннего состояния, инициализируя структурные блоки случайными значениями. Также, чтобы не дать удалить себя из системы, Sebek отключает функцию очистки, когда не работает в тестовом режиме.

Windows-версия Sebek использует почти те же приёмы, что и Linux-версия. Новая версия прячет себя из списка запущенных модулей, запросов к файловой системе и реестру. Она обходит некоторые методы обнаружения, используемые “KprocCheck” (http://www.security.org.sg/vuln/sebek215.html, http://www.security.org.sg/code/kproccheck.html).

Windows-модуль также записывает все действия с сокетами, включая такие системные вызовы, как “open”, “accept” и “bind”. Новая версия следит за PPID и PID каждого процесса. Наконец, предыдущие версии Sebek перехватывали только активность в командной строке “cmd.exe”. Текущая версия записывает ввод/вывод всех консольных приложений, даже тех, которые определяют сокет для stdin, stdout или stderr. Одним из главных преимуществ Windows-версий перед Linux-версиями является то, что они переживают перезагрузку системы.

Недостатки Sebek

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

Присутствие модуля Sebek в ОС Linux можно легко определить. Текущий метод сокрытия Sebek отсоединяет модуль из списка присоединенных ядерных модулей. На Рис. 1 показан модуль “module_hunter”, обнаруживающий модуль Sebek по его имени.

# insmod ./module_hunter.o
# cat /proc/showmodules
address                         module

0xc880d000            scsi_mod size: 0x1a278
0xc8827000                   * size: 0x12
0xc8829000              sd_mod size: 0x348c
0xc882e000            BusLogic size: 0x189bc
0xc8848000                 jbd size: 0xcab4
0xc8856000                ext3 size: 0x11480
0xc888a000               cdrom size: 0x83c0
0xc8894000              ide-cd size: 0x8b7c
0xc889e000            ide-scsi size: 0x2fb0
0xc88a2000              sr_mod size: 0x46d8
0xc88a6000                 net size: 0x219
0xc88a8000                  sg size: 0x8eac
0xc88b2000           ip_tables size: 0x3af8
0xc88b7000      iptable_filter size: 0x96c
0xc88bb000                 mii size: 0xf88
0xc88bd000       module_hunter size: 0x5ec
0xc88bf000          ipt_REJECT size: 0xf58
0xc88c1000             pcnet32 size: 0x4740
0xc88c7000              autofs size: 0x33d4
0xc88cc000               sebek size: 0x5e50
#

Рис. 1. Определение Sebek Linux 3.0.3 - module_hunter.

Sebek можно обнаружить и в Windows, посмотрев на перехватываемые native API. Этот метод осуществляется следующим образом: "KprocCheck -t". На Рис. 2 показаны перехватываемые записи в SDT (Service Descriptor Table), владельцем которых является неизвестный модуль, в нашем случае Sebek.

C:\>KProcCheck.exe -t
KProcCheck Version 0.2-beta2 Proof-of-Concept by SIG^2 (www.security.org.sg)

Checks SDT for Hooked Native APIs

KeServiceDescriptorTable                80559B80
KeServiceDescriptorTable.ServiceTable   804E2D20
KeServiceDescriptorTable.ServiceLimit   284

Entry  19 - [hooked by unknown at FA881498]
Entry  25 - [hooked by unknown at FA881E16]
Entry  29 - [hooked by unknown at FA882266]
Entry  35 - [hooked by unknown at FA880F8E]
Entry  47 - [hooked by unknown at FA882360]
Entry  49 - [hooked by unknown at FA881EDE]
Entry  74 - [hooked by unknown at FA881D6C]
Entry  77 - [hooked by unknown at FA8822E2]
Entry  91 - [hooked by unknown at FA881924]
Entry  AD - [hooked by unknown at FA881A4A]
Entry  B7 - [hooked by unknown at FA8810EE]
Entry  C8 - [hooked by unknown at FA881310]
Entry  D2 - [hooked by unknown at FA8813EA]
Entry 112 - [hooked by unknown at FA881146]

Number of Service Table entries hooked = 14

C:\>

Рис. 2. Определение Sebek Windows 3.0.3 - KProcCheck.

Другие методы используют заданное по умолчанию имя драйвера в Windows, sebek.sys, чтобы определить присутствие Sebek. Этого можно избежать, изменив имя драйвера. Инсталлятор Sebek можно запустить с ключом “/N=NAME”, где NAME – имя драйвера без расширения “.sys”.В Linux можно определить изменения в таблице системных вызовов. К тому же, можно перезаписать указатели на эти вызовы, отключая тем самым Sebek.Windows версия Sebek может быть отключена подобным образом, основанным на восстановлении записей таблицы сервисов (ServiceTable) в SDT. Этот метод используется инструментом SDTrestore и показан на Рис. 3:

C:\>SDTrestore.exe
SDTrestore Version 0.2 Proof-of-Concept by SIG^2 G-TEC (www.security.org.sg)

KeServiceDescriptorTable                80559B80
KeServiceDecriptorTable.ServiceTable    804E2D20
KeServiceDescriptorTable.ServiceLimit   284

ZwClose                    19 --[hooked by unknown at FA881498]--
ZwCreateFile               25 --[hooked by unknown at FA881E16]--
ZwCreateKey                29 --[hooked by unknown at FA882266]--
ZwCreateThread             35 --[hooked by unknown at FA880F8E]--
ZwEnumerateKey             47 --[hooked by unknown at FA882360]--
ZwEnumerateValueKey        49 --[hooked by unknown at FA881EDE]--
ZwOpenFile                 74 --[hooked by unknown at FA881D6C]--
ZwOpenKey                  77 --[hooked by unknown at FA8822E2]--
ZwQueryDirectoryFile       91 --[hooked by unknown at FA881924]--
ZwQuerySystemInformation   AD --[hooked by unknown at FA881A4A]--
ZwReadFile                 B7 --[hooked by unknown at FA8810EE]--
ZwRequestWaitReplyPort     C8 --[hooked by unknown at FA881310]--
ZwSecureConnectPort        D2 --[hooked by unknown at FA8813EA]--
ZwWriteFile               112 --[hooked by unknown at FA881146]--

Number of Service Table entries hooked = 14

WARNING:  THIS IS EXPERIMENTAL CODE.  FIXING THE SDT MAY HAVE GRAVE
CONSEQUENCES, SUCH AS SYSTEM CRASH, DATA LOSS OR SYSTEM CORRUPTION.
PROCEED AT YOUR OWN RISK.  YOU HAVE BEEN WARNED.

Fix SDT Entries (Y/N)? : Y

[+] Patched SDT entry 19 to 805675D9
[+] Patched SDT entry 25 to 8057164C
[+] Patched SDT entry 29 to 8056F063
[+] Patched SDT entry 35 to 8057F262
[+] Patched SDT entry 47 to 8056F76A
[+] Patched SDT entry 49 to 805801FE
[+] Patched SDT entry 74 to 805715E7
[+] Patched SDT entry 77 to 805684D5
[+] Patched SDT entry 91 to 80574DAD
[+] Patched SDT entry AD to 8057CC27
[+] Patched SDT entry B7 to 80571B30
[+] Patched SDT entry C8 to 8057860F
[+] Patched SDT entry D2 to 80585D7D
[+] Patched SDT entry 112 to 8057A125

C:\>

Рис. 3. Отключение Sebek Windows 3.0.3- SDTrestore.·         Данные, доступ к которым осуществляется через системный вызов “mmap”, не могут быть записаны Sebek.·         Linux версия Sebek не переживает перезагрузки системы.

Некоторые вышеописанные недостатки (например, выживание после перезагрузки и отключение Sebek через таблицу системных вызовов) могут быть решены внедрением Sebek как патча ядра. Однако выбор LKM против патча ядра является лишь вопросом удобства установки. LKM или драйвер гораздо легче установить. Для honeypot’ов был бы надёжнее патч ядра как средство установки Sebek.

Sebek является open-source приложением, так что каждый может настроить его под свои нужды. Настроенный вручную Sebek снизит вероятность обнаружения в отличие от распространяемого публично.

Спецификации протокола Sebek

Кроме возможностей перехвата данных, Sebek также содержит продвинутые механизмы составления отчетов. Данные, перехваченные на уровне ядра, передаются серверу Sebek с использованием тайного UDP канала. Sebek использует свою реализацию RawSocket интерфейса на уровне ядра.

Новая версия Sebek использует переделанную спецификацию протокола Sebek, которая несовместима с предыдущими версиями. Поэтому для третьего поколения Honeynet требуется третья версия Sebek на Roo Honeywall и на всех honeypot’ах. Рис. 4 показывает формат данных протокола Sebek. Каждая запись содержит 56-байтовый заголовок.

Рис. 4. Заголовок пакета протокола Sebek 3 версии.

Заголовок нового протокола размещает дополнительную информацию, собранную на уровне ядра, включая идентификатор родительского процесса (PPID) и inode файловой системы. Это два 32-битных поля, дополняющие поля предыдущей версии протокола. К тому же, значение поля “version” теперь равно трём, а поле “type” поддерживает новые системные вызовы: read(0), write(1), socket(2) и open(3).

Вся эта информация используется новыми инструментами анализа информации новой версии Honeywall, чтобы следить и сопоставлять действия злоумышленника на honeypot.

Ethereal с версии 0.10.0 включает специальный анализатор протокола Sebek. Этот анализатор способен просматривать пакеты протокола Sebek версии 1, но для текущей, третьей версии, такого анализатора не существует.

Интеграция Sebek и Honeynet GenIII

Сети Honeynet GenIII используют новую модель данных, независимую от источника данных. Эта модель устанавливает отношения между 4 разными концептуальными объектами: хосты, представляющие honeypot’ы, процессы, программы, выполняемые на хостах, файлы, представляющие данные, находящиеся на жестком диске, и сетевые потоки, представляющие соединения между хостами.
Данные Sebek позволяют связать эти разные объекты. Процессы определяются системными вызовами. Вызовы “read”, “write” и “open” связывают процессы с файлами, вызов “socket” связывает процессы с сетевыми потоками, а “fork” и “clone” связывают процессы с другими процессами.

Данные Sebek сопоставляются с данными, перехваченными из сетевого трафика. Сетевая активность собирается Honeywall’ом с использованием снифера tcpdump. Эта активность обрабатывается различными инструментами: IDS Snort выявляет злонамеренный трафик, программа p0f определяет ОС, а Argus контролирует потоки. Данные из всех этих источников объединяются и сопоставляются в реляционной бае данных.

Графический Web-интерфейс Roo, также известный как Walleye, отображает и анализирует все перехваченные данные. Обычно незаконное вторжение обнаруживается через подозрительную сетевую активность. Рис. 5 показывает возможности Walleye.

Рис 5. Сетевые потоки Walleye - системный вызов Sebek "socket".

Обработчик событий должен начать расследование с анализа сетевого трафика. В нашем примере обнаружена некоторая активность между 192.168.100.66 (злоумышленник) и honeypot’ом 192.168.100.150. Этот сетевой поток соответствует TCP трафику с исходным портом 1135 и портом назначения 45295. Произошел обмен несколькими пакетами и сгенерированный трафик вызвал 2 тревожных вызова IDS Snort. Видно, что трафик имеет отношение к процессу 2340 на honeypot’е.

Рис. 6 показывает уровень детализации, предоставляемый сетями Honeynet GenIII и Sebek, демонстрируя поток системных процессов, связанных с предыдущим сетевым потоком.

Рис. 6. Уменьшенная версия диаграммы потока процессов Walleye – системный вызов Sebek “fork”.

Этот пример показывает honeypot с ОС Linux, скомпрометированный через “trans2open” переполнение буфера в Samba. Первый процесс, “init” (PID=1), вызвал демон Samba, “smbd” (PID=1525), который в ответ вызвал дочерний процесс (PID от 2320 до 2339) для каждого нового соединения. Каждое соединение соответствовало попытке удаленного переполнения буфера, попытке эксплуатировать упомянутую выше уязвимость в Samba. Наконец, эта уязвимость была удачно эксплуатирована соединением, связанным с процессом 2340. Этот процесс создал два разных процесса, “sh” (PID 2341 и 2342). Вторая оболочка была использована злоумышленником для выполнения нескольких команд (процессов) в системе, таких как “id”, “uname”, “cat”, “ls” и “passwd”.

Вся информация, необходимая для создания диаграммы потока, предоставляется Sebek. Интерфейс Walleye также позволяет получить дополнительные сведения о процессах, собранные Sebek. Используя эти сведения, можно узнать, к каким файлам обращался злоумышленник и какие именно команды он выполнял. Рис. 7 показывает активность, связанную с процессом 2342. Этот процесс открыл некоторые библиотечные файлы, например, "/etc/ld.so.cache" или "lib/libtermcap.so.2.0.8", и выполнил несколько команд, набранных злоумышленником и перехваченных Sebek через системный вызов “read”, например “uname –a”, “id”, “cat /etc/passwd” и “ls –l /”.

Рис. 7. Данные о процессах Walleye – вызовы “read” и “open” Sebek.

Заключение

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