Следующая новость
Предыдущая новость

Опасный тренд. Как утилита Trend Micro для борьбы с руткитами позволила устанавливать руткиты

19.05.2020 17:32
Опасный тренд. Как утилита Trend Micro для борьбы с руткитами позволила устанавливать руткиты

Содержание статьи

  • Установка
  • Драйвер tmcomm.sys
  • Класс TrueApi
  • Класс XrayApi
  • Запросы IOCTL
  • IoControlCode == 9000402Bh
  • IoControlCode == 90004027h
  • Эксплоит
  • IoControlCode == 90004033h
  • IoControlCode == 900040DFh
  • IoControlCode == 900040E7h
  • Обход сертификации Microsoft WHQL
  • Устанавливаем свой руткит с помощью RootkitBuster

18 мая 2020 года восемнадцатилетний исследователь Билл Демиркапи опубликовал в своем блоге объемное исследование, посвященное очень любопытной теме. Автору удалось установить в Windows собственный руткит с помощью утилиты RootkitBuster компании Trend Micro. Рассказ о том, как молодой исследователь пришел к успеху, — в сегодняшней статье.

Изучая методы обнаружения руткитов, Билл Демиркапи наткнулся на бесплатную утилиту RootkitBuster компании Trend Micro. Разработчик позиционирует ее как сканер скрытых файлов, записей реестра и master boot record (MBR), предназначенный для идентификации и удаления руткитов. Описание программы гласило, что RootkitBuster способен выявлять несколько методов проникновения руткитов и закрепления их в системе. Это заинтересовало исследователя, и он решил выяснить, что у RootkitBuster спрятано под капотом. Пристальное изучение программы позволило обнаружить примечательную дыру в коде, с помощью которой можно использовать тулзу не только для поиска прячущихся в глубинах Windows вредоносов, но и для установки в систему собственных руткитов.

WWW

Эта статья опирается на оригинальный текст исследования Билла Демиркапи. Если ты в достаточной степени владеешь английским языком, то можешь ознакомиться с ней в его блоге.

Установка

Сразу после запуска инсталлятора RootkitBuster Билл обратил внимание на предупреждение Resource Hacker о том, что софтина пытается установить в его систему файл tmcomm.sys — драйвер, используемый некоторыми приложениями Trend Micro.

Опасный тренд. Как утилита Trend Micro для борьбы с руткитами позволила устанавливать руткиты
RootkitBuster устанавливает драйвер до того, как пользователь примет условия лицензионного соглашения (здесь и далее иллюстрации из блога Билла Демиркапи)

Примечательно, что драйвер и сам исполняемый файл сканера были распакованы на диск в папку %TEMP%RootkitBuster еще до того, как на экране Билла появился текст лицензионного соглашения. Оно, в частности, гласило, что пользователь RootkitBuster обязуется «не пытаться перепроектировать, модифицировать, дизассемблировать, декомпилировать, исследовать исходный код или создавать производные произведения на основе этой программы».

Поэтому Билл взял и завершил процесс инсталлятора с помощью пункта «Закрыть окно» контекстного меню, так и не приняв условия лицензии. Что позволило ему с чистой совестью «дизассемблировать, декомпилировать» и делать с этим продуктом Trend Micro другие вещи, о которых в приличном обществе не принято говорить вслух. Отличный трюк для обхода юридических сложностей!

Драйвер tmcomm.sys

Этот драйвер, обозначенный как Common Module Trend Micro, способен принимать сообщения от привилегированных приложений пользовательского режима и может выполнять функции, специфичные не только для утилиты RootkitBuster. Иными словами, он используется многими другими программами Trend Micro.

В числе первых действий драйвер создает устройство по адресу DeviceTmComm для приема сообщений IOCTL из пользовательского режима. Для этого устройства создается символическая ссылка по адресу DosDevicesTmComm (которая доступна через \.GlobalTmComm). Точка входа инициализирует значительное количество используемых в драйвере классов и структур, однако для целей исследования — выполнения кода ядра — нет необходимости подробно рассматривать каждый из них.

Опасный тренд. Как утилита Trend Micro для борьбы с руткитами позволила устанавливать руткиты
Создание устройства в драйвере tmcomm.sys

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

Класс TrueApi

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

struct TrueApi {     BYTE Initialized;     PVOID ZwQuerySystemInformation;     PVOID ZwCreateFile;     PVOID unk1; // Initialized as NULL     PVOID ZwQueryDirectoryFile;     PVOID ZwClose;     PVOID ZwOpenDirectoryObjectWrapper;     PVOID ZwQueryDirectoryObject;     PVOID ZwDuplicateObject;     PVOID unk2; // Initialized as NULL     PVOID ZwOpenKey;     PVOID ZwEnumerateKey;     PVOID ZwEnumerateValueKey;     PVOID ZwCreateKey;     PVOID ZwQueryValueKey;     PVOID ZwQueryKey;     PVOID ZwDeleteKey;     PVOID ZwTerminateProcess;     PVOID ZwOpenProcess;     PVOID ZwSetValueKey;     PVOID ZwDeleteValueKey;     PVOID ZwCreateSection;     PVOID ZwQueryInformationFile;     PVOID ZwSetInformationFile;     PVOID ZwMapViewOfSection;     PVOID ZwUnmapViewOfSection;     PVOID ZwReadFile;     PVOID ZwWriteFile;     PVOID ZwQuerySecurityObject;     PVOID unk3; // Initialized as NULL     PVOID unk4; // Initialized as NULL     PVOID ZwSetSecurityObject; }; 

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

Класс XrayApi

В драйвере имеется еще один важный класс под названием XrayApi. Он используется для доступа к нескольким низкоуровневым устройствам и непосредственного взаимодействия с файловой системой. Этот класс содержит структуру XrayConfig, в которой сосредоточена его основная конфигурация:

struct XrayConfigData {     WORD Size;     CHAR pad1[2];     DWORD SystemBuildNumber;     DWORD UnkOffset1;     DWORD UnkOffset2;     DWORD UnkOffset3;     CHAR pad2[4];     PVOID NotificationEntryIdentifier;     PVOID NtoskrnlBase;     PVOID IopRootDeviceNode;     PVOID PpDevNodeLockTree;     PVOID ExInitializeNPagedLookasideListInternal;     PVOID ExDeleteNPagedLookasideList;     CHAR unkpad3[16];     PVOID KeAcquireInStackQueuedSpinLockAtDpcLevel;     PVOID KeReleaseInStackQueuedSpinLockFromDpcLevel;     ... }; 

В этой структуре среди прочего есть информация о расположении таких внутренних и недокументированных переменных в ядре Windows, как ExInitializeNPagedLookasideListInternal, IopRootDeviceNode, ExDeleteNPagedLookasideList и PpDevNodeLockTree. Исследователь предположил, что предназначение этого класса — получение прямого доступа к низкоуровневым устройствам в обход документированных (а следовательно, широко известных вирусописателям) методов.

Запросы IOCTL

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

struct TmIoctlRequest {     DWORD InputSize;     DWORD OutputSize;     PVOID UserInputBuffer;     PVOID UserOutputBuffer;     PVOID Unused;     DWORD_PTR* BytesWritten; }; 

Таким образом, отправка запросов IOCTL в драйвере tmcomm.sys реализована с помощью своеобразных «таблиц диспетчеризации», при этом «базовая таблица» содержит код IOCTL и соответствующую вспомогательную функцию. Например, если необходимо отправить IOCTL-запрос с кодом 0xDEADBEEF, драйвер сравнивает запрос с каждой строкой базовой таблицы диспетчеризации и передает его только в том случае, если найдет совпадение. Каждая запись в такой таблице имеет структуру, подобную представленной ниже:

typedef NTSTATUS (__fastcall *DispatchFunction_t)(TmIoctlRequest *IoctlRequest);  struct BaseDispatchTableEntry {     DWORD_PTR IOCode;     DispatchFunction_t DispatchFunction; }; 

После вызова функции DispatchFunction обычно верифицируются передаваемые данные — начиная с проверки nullptr и заканчивая проверкой входных и выходных буферов. Эти «функции вспомогательной диспетчеризации» затем выполняют другой поиск на основе кода, переданного в пользовательском буфере ввода, с целью найти соответствующую запись во вспомогательной таблице. Такие записи используют структуру следующего вида:

typedef NTSTATUS (__fastcall *OperationFunction_t)(PVOID InputBuffer, PVOID OutputBuffer);  struct SubDispatchTableEntry {     DWORD64 OperationCode;     OperationFunction_t PrimaryRoutine;     OperationFunction_t ValidatorRoutine; }; 

Непосредственно перед вызовом модуля PrimaryRoutine, который выполняет запрошенное действие, функция SubDispatchTableEntry вызывает ValidatorRoutine. Эта подпрограмма проверяет входной буфер, то есть проверяет данные, которые будут впоследствии использоваться PrimaryRoutine. Этот основной код выполняется только в том случае, если ValidatorRoutine успешно завершит проверку.

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

IoControlCode == 9000402Bh

Первая из рассмотренных Биллом таблиц отвечает за взаимодействие с файловой системой. Код для этой вспомогательной таблицы диспетчеризации получается путем разыменования DWORD из начала входного буфера. То есть, чтобы определить, какую запись вспомогательной таблицы следует выполнить, в начале входного буфера нужно поместить DWORD, соответствующий определенному опкоду. Для упрощения задачи исследователя разработчики из Trend Micro оставили в коде драйвера много отладочных строк, с использованием которых Билл Демиркапи составил таблицу функций PrimaryRoutine, хранящихся во вспомогательной таблице диспетчеризации, и описал их назначение.

Опкод Функция PrimaryRoutine Описание
2713h IoControlCreateFile Вызывает NtCreateFile, все параметры определяются запросом
2711h IoControlFindNextFile Возвращает STATUS_NOT_SUPPORTED
2710h IoControlFindFirstFile Ничего не делает, всегда возвращает STATUS_SUCCESS
2712h IoControlFindCloseFile Вызывает ZwClose, все параметры определяются запросом
2714h IoControlCreateFileIRP Создает новый FileObject и связывает с ним DeviceObject для запрошенного диска
2715h IoControlReadFileIRPNoCache Ссылается на FileObject, используя HANDLE из запроса. Вызывает IofCallDriver и читает результат
2716h IoControlDeleteFileIRP Удаляет файл, отправляя запрос IRP_MJ_SET_INFORMATION
2717h IoControlGetFileSizeIRP Запрашивает размер файла, отправляя запрос IRP_MJ_QUERY_INFORMATION
2718h IoControlSetFilePosIRP Устанавливает метаданные файла, отправляя запрос IRP_MJ_SET_INFORMATION
2719h IoControlFindFirstFileIRP Возвращает STATUS_NOT_SUPPORTED
271Ah IoControlFindNextFileIRP Возвращает STATUS_NOT_SUPPORTED
2720h IoControlQueryFile Вызывает NtQueryInformationFile, все параметры определяются запросом
2721h IoControlSetInformationFile Вызывает NtSetInformationFile, все параметры определяются запросом
2722h IoControlCreateFileOplock Создает Oplock с помощью IoCreateFileEx и другого API файловой системы
2723h IoControlGetFileSecurity Вызывает NtCreateFile, а затем ZwQuerySecurityObject. Все параметры определяются запросом
2724h IoControlSetFileSecurity Вызывает NtCreateFile, а затем ZwSetSecurityObject. Все параметры определяются запросом
2725h IoControlQueryExclusiveHandle Проверяет дескриптор файла и параметры его использования
2726h IoControlCloseExclusiveHandle Принудительно закрывает дескриптор файла

IoControlCode == 90004027h

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

Опкод Функция PrimaryRoutine Описание
C350h GetProcessesAllMethods Поиск процессов с использованием ZwQuerySystemInformation и WorkingSetExpansionLinks
C351h DeleteTaskResults * Удаляет результаты, полученные с помощью других функций, таких как GetProcessesAllMethods
C358h GetTaskBasicResults * Используется для получения результатов анализа, выполненного с помощью других функций, таких как GetProcessesAllMethods
C35Dh GetTaskFullResults * Используется для получения полных результатов анализа, выполненного с помощью других функций, таких как GetProcessesAllMethods
C360h IsSupportedSystem Возвращает TRUE, если система «поддерживается» (независимо от того, имеются ли жестко заданные смещения для текущего билда)
C361h TryToStopTmComm Пытается остановить драйвер
C362h GetProcessesViaMethod Выполняет поиск процессов с использованием заданного метода
C371h CheckDeviceStackIntegrity Проверяет device tampering для устройств, связанных с физическими дисками
C375h ShouldRequireOplock Возвращает TRUE, если для определенных операций сканирования необходимо использовать блокировку

Все эти функции используют несколько структур, которые исследователь назвал MicroTask и MicroScan. Вот как они выглядят в дизассемблированном виде.

struct MicroTaskVtable {     PVOID Constructor;     PVOID NewNode;     PVOID DeleteNode;     PVOID Insert;     PVOID InsertAfter;     PVOID InsertBefore;     PVOID First;     PVOID Next;     PVOID Remove;     PVOID RemoveHead;     PVOID RemoveTail;     PVOID unk2;     PVOID IsEmpty; };  struct MicroTask {     MicroTaskVtable* vtable;     PVOID self1; // ptr to itself     PVOID self2; // ptr to itself     DWORD_PTR unk1;     PVOID MemoryAllocator;     PVOID CurrentListItem;     PVOID PreviousListItem;     DWORD ListSize;     DWORD unk4; // Initialized as NULL     char ListName[50]; };  struct MicroScanVtable {     PVOID Constructor;     PVOID GetTask; };  struct MicroScan {     MicroScanVtable* vtable;     DWORD Tag; // Always 'PANS'     char pad1[4];     DWORD64 TasksSize;     MicroTask Tasks[4]; }; 

Для большинства запросов IOCTL в этой вспомогательной таблице структура MicroScan заполняется на стороне клиента, который вызывает драйвер. Именно эту особенность Демиркапи решил использовать для эксплуатации возможной уязвимости.

Эксплоит

Билл Демиркапи признается, что во время реверсинга функций, хранящихся в этой вспомогательной таблице диспетчеризации, он был совершенно сбит с толку. В итоге оказалось, что указатель ядра MicroScan, возвращаемый такими функциями, как GetProcessesAllMethods, напрямую передавался другим функциям, например DeleteTaskResults, на стороне клиента. Эти функции принимают такой недоверенный указатель ядра и практически без проверки вызывают функции в таблице виртуальных функций, описанной в классе.

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

1 год

7690 р.

1 месяц

720 р.

Я уже участник «Xakep.ru»

Источник

Последние новости