21.12.2004

Windows под прицелом

Однажды, просматривая журналы своей Honeypot, я обнаружил, что сервер начал себя «вести». Межсетевой экран фиксировал исходящие и входящие TCP соединения, совершенно не соответствующие «должностным обязанностям» сервера, система обнаружения атак идентифицировала в одном из соединений признаки приглашения интерпретатора командной строки. Просканировав взломанную машину, я обнаружил на нем IRC и FTP серверы, которых не устанавливал. Каково же было мое удивление, когда при запуске netstat, я не обнаружил открытых портов, соответствующих результатам сканирования. Так началось мое знакомство с rootkits для Windows.

(с) coded by offtopic@mail.ru 2004

«Ты видишь суслика? Нет. И я не вижу. А все-таки он есть!».

Художественный фильм ДМБ.

 

Однажды, просматривая журналы своей Honeypot, я обнаружил, что сервер начал себя «вести». Межсетевой экран фиксировал исходящие и входящие TCP соединения, совершенно не соответствующие «должностным обязанностям» сервера, система обнаружения атак идентифицировала в одном из соединений признаки приглашения интерпретатора командной строки. Просканировав взломанную машину, я обнаружил на нем IRC и FTP серверы, которых не устанавливал. Каково же было мое удивление, когда при запуске netstat, я не обнаружил открытых портов, соответствующих результатам сканирования. Так началось мое знакомство с rootkits для Windows.

Кольца всевластия

Термин rootkit пришел из мира Unix и изначально им обозначался набор инструментов, необходимый злоумышленнику после того, как он получил права суперпользователя (root) в атакуемой системе. В процессе развития rootkits претерпели ряд модификаций, и их основной задачей стало сокрытие деятельности взломщика от администратора системы.

Первые rootkit для Windows появились в конце прошлого века. Классиком этого направления считается Greg Hoglund, автор NT Rootkit [1], поддерживающий сервер www.rootkit.com.

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

Кроме того, rootkits могут скрывать сетевую активность путем модификации стека протоколов TCP/IP. Так, например rootkit «Hacker Defender» [2] перехватывает вызовы Winsock и может обрабатывать сетевой трафик до того как он будет передан приложению. Т.е. если в системе установлен Web сервер, и соответственно открыт 80й порт, rootkit может использовать его для взаимодействия с взломщиком, в то время как другие пользователи будут без проблем работать по протоколу HTTP.

Темная сторона силы

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

Прежде всего, в память системы загружаются код программы и используемые ею функции из системных библиотек. После этого программа вызывает функцию API, ответственную за выдачу списка процессов в системе (например, NtQuerySystemInformation из библиотеки Ntdll.dll). Функция  NtQuerySystemInformation  по сути заглушка, которая вызывает соответствующую функцию уровня ядра (ZwQuerySystemInformation), используя прерывание Windows (int 0x2E). Данная функция, работая уже в режиме ядра, напрямую обращается к памяти ядра и получает из структуры PsActiveProcessList список активных процессов, который отображается на экране.

Rootkit может вмешаться в работу системы на любом из этих этапов.

Рисунок 1. Hacker Defender in action

Классическую идею с подменой системных утилит, таких как netstat в мире Windows оказалось довольно сложно реализовать. Видимо, это связанно с отсутствием исходных кодов, недостаточным описанием внутреннего устройства системы, а так же с наличием встроенных механизмов контроля целостности.  Или, возможно, с тем, что многие системные администраторы Windows не знают о netstat, а о чем не знаешь, в том и не нуждаешься.

Хотя некоторые отголоски этой идеи можно встретить и сейчас. Так, например, для запуска некоторых rootkit файл explorer.exe модифицируется таким образом, что бы считывать список автоматически исполняемых при загрузке программ из ключа отличного от HKCU[HKLM]\Software\Microsoft\Windows\CurrentVersion\Run [3]. Естественно такая операция требует отключения системы Windows File Protection, но, имея права администратора в системе, это несложно осуществить даже без перезагрузки системы [4].

В мире Windows в основе работы rootkits лежит модификация данных и кода программы в памяти операционной системы. В зависимости от того, с какой областью памяти работает rootkit их можно подразделить на системы пользовательского уровня (User Level) и уровня ядра (Kernel Level, так же называемые KLT) [5]. В зависимости от метода реализации – основанные на модификации пути исполнения (см. Рисунок 1) и манипулирующие только данными.

Рисунок 2. Классификация Rootkits

Наиболее распространенными являются rootkit уровня пользователя, реализующие метод модификации пути исполнения. К подобным программам относятся Hacker Defender, Vanquish, AFX Rootkit. Менее распространены программы, модифицирующие пути исполнения на уровне ядра (например, He4Hook). И, наконец, rootkits, манипулирующие объектами ядра, пока, насколько мне известно, существуют в качестве PoC утилит, таких как Fu, PHIDE [7]. Этот подход называется Direct Kernel Object Manipulation (DKOM), не путать с DCOM.

Давайте подробнее рассмотрим различные методы реализации Rootkit.

Козни Сарумана

Этот популярный подход очень хорошо разработан и документирован. Дело в том, что его, наряду с внедрением DLL часто используется для отладки и профилирования процессов. Т.е. первоначально он был разработан далеко не для создания вредоносных программ. Не так давно мне попался документ 1999 года, где исследователи Microsoft подробно рассказывают о реализации этого метода и даже предлагают инструментарий для перехвата API [8].

Однако, наша статья посвящена rootkits, так что давайте рассмотрим, как это реализовано в Hacker Defender. После запуска программа перечисляет все доступные для неё процессы в системе, после чего пытается перехватить определенные вызовы API [9]. Перехват заключается в замене первых байт кода функции на безусловный переход к новому коду функции, предварительно сохраненному в адресном пространстве программы. Для этого выясняется адрес необходимой функции,  затем в памяти программы отводится место под код нового варианта функции и её первоначального кода, который сохраняется для дальнейшего использования. Таким образом, когда пользовательская программа вызывает функцию API, например NtQuerySystemInformation, вызов передается функции предобработки данных, которая затем может вызвать исходную функцию, которая, в свою очередь, вернет результаты функции постобработки. Функция постобработки модифицирует данные, которые вернула исходная функция, например, удаляя некоторые записи.

Рисунок 3. Перехват вызовов API.

Таким образом, программы, которые будут использовать перехваченные вызовы API, получат информацию не о реальном положении дел в системе, но уже обработанные Rootkit данные.  Также Hacker Defender перехватывает функции запуска новых процессов, что позволяет ему заражать новые программы, запускаемые пользователем.

Двумя кольцами ниже…

Идея модификации пути исполнения может быть реализована и на уровне ядра. При переходе в нулевое кольцо защиты функции API уровня пользователя вызывают прерывание 0x2E, которому в качестве параметра передается индекс необходимой функции. По данному индексу находится адрес соответствующего вызова API уровня ядра. Он хранится в структуре System Services Dispatch Table (SSDT) в виде упорядоченного списка адресов «низкоуровневых» функций (ZwCreateFile, ZwQuerySystemInformation и т.д.) [10]. Эта таблица загружается в память операционной системы при старте микроядра ntoskrnl.exe.

Некоторые rootkit модифицируют адрес, содержащийся в SSDT таким образом, чтобы он указывал на  адрес обработчика, созданного им. Для этого может использоваться либо драйвер, либо user-land приложение, манипулирующее устройством \dev\physicalmemory, позволяющим (при наличии соответствующих полномочий, естественно) напрямую работать с памятью ядра. Новая функция Native API содержит предобработчик, вызов оригинальной функции и постобработчик, удаляющий ненужные данные из результатов работы функции.

Кстати, этим же занимаются многие средства защиты, для обнаружения «нехорошего» поведения программ.

Потоки - Назгулы

Зачем изменять функцию, если она манипулирует данными, которые могут быть так же изменены? Именно так работают DKOM rootkits. Например, FU модифицирует список PsActiveProcessList, содержащий список активных процессов, информацию из которого получает ZwQuerySystemInformation. При этом процесс остается существовать в качестве «свободного» потока и будет нормально функционировать, поскольку распределение процессорного времени в Windows основано на потоках, а не процессах.

Список PsActiveProcessList содержит набор структур EPROCESS, каждая из которых кроме  информации о процессе содержит ссылки на предыдущий и последующие процессы в списке (ActiveProcessLinks). Программа, реализующая DKOM, изменяет значение ActiveProcessLinks предыдущего и последующего процесса в списке, так, чтобы перечисление шло в обход скрываемой программы (см. Рисунок 4)

Рисунок 4. Список активных процессов до (1) и после (2)

Кроме скрытия процессов KLT реализующие DKOM могут манипулировать маркерами доступа для повышения привилегий процессов, например, добавляя в него хорошо известный SID, или срывать открытые порты [11].

Светлая сторона силы

Далее рассматриваются детективные средства защиты от rootkits.

Кольчуга из мифрила?

Многие антивирусы просто «не видят» rootkit. Некоторые из них устанавливают системный драйвер и, работая в режиме мониторинга, имеют возможность обнаружить активность rootkit уровня пользователя.  Однако ситуация усложняется тем обстоятельством, что большинство rootkits доступно в исходных кодах и можно легко создать собственную модификацию rootkit, которая не будет обнаруживаться антивирусами [12].

С персональными межсетевыми экранами и системами обнаружения атак уровня узла ситуация не лучше.  Например, мой любимый персональный межсетевой экран Agnitum Outpost версии 2.1 вообще не замечал присутствия rootkit на машине и соответствующей сетевой активности. Outpost версии 2.5 перехватывает «небезопасные» вызовы API, и в ответ на запуск Hacker Defender начал бурно прекращать сетевую активность «модифицированных» приложений. Однако, после того  как обнаружил что «посчитали» и его, крепко обиделся и завис (по крайней мере, GUI). После перезагрузки Outpost уже не вспоминал об этом досадном инциденте, решив оставить Rootkit в покое и не обращать внимания на его сетевую активность (если конечно, она проходит через разрешенные сетевые приложения).

Рисунок 5. …. Опоссума

Определять Rootkit по сетевой активности с помощью межсетевых экранов и систем обнаружения/предотвращения атак несложно. Несанкционированные TCP/Telnet/SSH/FTP сессии вполне могут свидетельствовать о наличии в системе rootkit. Например, Hacker Defender, несмотря на используемый в нем механизм кодирования трафика можно обнаруживать с помощью следующей сигнатуры для NIDS Snort.

# (C)oded by offtopic@mail.ru, 2003

#

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Rootkit Hacker Defender 1.0 connection attempt"; flow:to_server,established; content:"|01 9a 8c 66 af c0 4a 11 9e 3f 40 88 12 2c 3a 4a 84 65 38 b0 b4 08 0b af db ce 02 94 34 5f 22 00|"; rev:1;)

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

Поможет ли здесь Палантир?

Зачастую rootkit только маскирует действия троянской программы, соответственно для его обнаружения достаточно просканировать машину с помощью nmap. Если на машине существуют лишние открытые порты – значит дело нечисто.

Существует ряд специализированных утилит, обнаруживающих rootkit. Например, сетевой сканер rkdscan [13] обнаруживает троянский компонент Hacker Defender, работающий через открытый другим приложением порт. Для этого используются уязвимость уровня проектирования, которая на языке специалистов по безопасности звучит как «слабая аутентификация клиента».

Утилита RKDetect [14] использует аномальный подход для обнаружения системных служб, скрытых rootkits уровня пользователя. Для этого с удаленной машины запрашивается список системных служб через WMI, а затем службы перечисляются с помощью Service Manager (SC). Эти списки различаются, поскольку WMI работает на уровне пользователя и подвержен влиянию rootkit, а SC – нет. После сравнения списков утилита выводит дополнительную информацию о «подозрительной» службе (см. Рисунок 6).

Рисунок 6. Обнаружение rootkit с помощью RKDetect

Подобный модуль в ближайшее время будет встроен в сканер безопасности XSpider (www.xspider.ru).

На склонах Огненной Горы

Как и в деле создания rootkits, так и в деле борьбы с ними есть свои лидеры. Признанной руткитоборкой первой степени является Joanna Rutkowska, чей новый сервер http://www.invisiblethings.org я настоятельно советую посетить. Её перу принадлежат такие утилиты как Patchfinder и Klister. Первая из них направлена на обнаружения rootkit, модифицирующих пути исполнения, в кто время как Klister помогает обнаруживать DKOM KLT.

Утилита Patchfinder [5] использует оригинальную идею измерения количества инструкций процессора необходимых для выполнения тех или иных операций в нормальном режиме и сравнения этих результатов с текущими показателями системы.

Для определения количества инструкций процессор переводится в пошаговый режим (single stepping mode), в котором при выполнении каждой инструкции вызывается отладочная исключительная ситуация. Количество таких вызовов подсчитывается и сохраняется.

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

Утилита Klister [15], направлена на обнаружение DKOM KLT и позволяет получать список всех процессов в системе, используя прямой доступ к памяти ядра.

Ещё один интересный и развивающийся проект, это RKDetector, не путать с RKDetect [16]. В ближайшее время автор планирует встроить в него собственный драйвер файловой системы для обнаружения «спрятанных» файлов.

Для обнаружения различных rootkits, использующих метод модификации пути исполнения можно воспользоваться утилитой VICE [17]. Перед её использованием настоятельно советую ознакомиться с документацией, что бы не запутаться в «ложных срабатываниях».

Да пребудет с вами сила!

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

«Пардон, а что это такое? :) Почему-то мне это словосочетание ничего не говорит, не попадалось на горизонте.» (Цитата. Источник: http://www.securitylab.ru/forum/forum_posts.asp?TID=11074&PN=0&TPN=4).

Ещё одна моя любимая фраза: «Кроме того, обладание этими кодами дает возможность внедрять вредоносные программы на самый глубокий уровень операционной системы, по сути делая их частью Windows. В частности, становится возможным создание нового поколения вирусов-невидимок, контролирующих взаимодействие с антивирусами и межсетевыми экранами для сокрытия своего присутствия» (http://www.kaspersky.ru/news.html?id=145667021).

Последней каплей стало фундаментальное исследование г-на Adam Gaydosh [18], по сей день пребывающего в счастливой уверенности, что user-mode rootkit изменяют образы исполняемых файлов на диске.

Надеюсь, данная статья поможет специалистам в области безопасности получить достаточную вводную информацию о rootkit для Windows, тем более атаки с использованием данных программ случаются все чаще и чаще. И да пребудет с вами сила!

  1. Greg Hoglund, «A *REAL* NT Rootkit, patching the NT Kernel», Phrack Magazine, Vol. 9, Issue 55. http://www.phrack.org/show.php?p=55&a=5.
  2. Holy Father, Hacker Defender Home, http://rootkit.host.sk
  3. nec, “Create New Autorun By Patching Explorer.exe”, http://www.rootkit.com/newsread.php?newsid=118
  4. Ntoskrnl, “Windows File Protection: How To Disable It On The Fly” http://www.rootkit.com/newsread.php?newsid=212.
  5. Jan Krzysztof Rutkowski, Advanced Windows 2000 Rootkit Detection   http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-rutkowski/bh-us-03-rutkowski-paper.pdf
  6. AFX Windows Rootkit. http://www.iamaphex.net/
  7. FU rootkit. http://www.rootkit.com/project.php?id=12
  8. Detours, http://research.microsoft.com/sn/detours/
  9. Holy Father, «Как стать невидимым в Windows NT» , http://rootkit.host.sk/knowhow/hidingru.txt
  10. Chew Keong TANG, “Defeating Kernel Native API Hookers”, http://www.security.org.sg/code/SIG2_DefeatingNativeAPIHookers.pdf
  11. Jamie Butler, DKOM, http://blackhat.com/presentations/win-usa-04/bh-win-04-butler.pdf
  12. Служба защиты от антивирусов, http://rootkit.host.sk/antidetection.php
  13. Andres Tarasko, “Remote Rootkit Scanner for Windows”, http://seclists.org/lists/fulldisclosure/2004/Oct/0701.html
  14. offtopic, RKDetect, http://www.security.nnov.ru/files/rkdetect.zip
  15. Joanna Rutkowska, Klister, http://www.rootkit.com/project.php?id=14
  16. Andres Tarasko, RKDetector, http://3wdesign.es/security/
  17. fuzen_op, VICE 2.0, http://www.rootkit.com/project.php?id=20
  18. Adam Gaydosh, “Windows Rootkit”,  http://www.giac.org/practical/GSEC/Adam_Gaydosh_GSEC.pdf
или введите имя

CAPTCHA