18 мая 2020 года восемнадцатилетний исследователь Билл Демиркапи опубликовал в своем блоге объемное исследование, посвященное очень любопытной теме. Автору удалось установить в Windows собственный руткит с помощью утилиты RootkitBuster компании Trend Micro. Рассказ о том, как молодой исследователь пришел к успеху, — в сегодняшней статье.
Изучая методы обнаружения руткитов, Билл Демиркапи наткнулся на бесплатную утилиту RootkitBuster компании Trend Micro. Разработчик позиционирует ее как сканер скрытых файлов, записей реестра и master boot record (MBR), предназначенный для идентификации и удаления руткитов. Описание программы гласило, что RootkitBuster способен выявлять несколько методов проникновения руткитов и закрепления их в системе. Это заинтересовало исследователя, и он решил выяснить, что у RootkitBuster спрятано под капотом. Пристальное изучение программы позволило обнаружить примечательную дыру в коде, с помощью которой можно использовать тулзу не только для поиска прячущихся в глубинах Windows вредоносов, но и для установки в систему собственных руткитов.
Установка
Сразу после запуска инсталлятора RootkitBuster Билл обратил внимание на предупреждение Resource Hacker о том, что софтина пытается установить в его систему файл tmcomm.sys — драйвер, используемый некоторыми приложениями Trend Micro.
RootkitBuster устанавливает драйвер до того, как пользователь примет условия лицензионного соглашения (здесь и далее иллюстрации из блога Билла Демиркапи)
Примечательно, что драйвер и сам исполняемый файл сканера были распакованы на диск в папку %TEMP%\RootkitBuster еще до того, как на экране Билла появился текст лицензионного соглашения. Оно, в частности, гласило, что пользователь RootkitBuster обязуется «не пытаться перепроектировать, модифицировать, дизассемблировать, декомпилировать, исследовать исходный код или создавать производные произведения на основе этой программы».
Поэтому Билл взял и завершил процесс инсталлятора с помощью пункта «Закрыть окно» контекстного меню, так и не приняв условия лицензии. Что позволило ему с чистой совестью «дизассемблировать, декомпилировать» и делать с этим продуктом Trend Micro другие вещи, о которых в приличном обществе не принято говорить вслух. Отличный трюк для обхода юридических сложностей!
Драйвер tmcomm.sys
Этот драйвер, обозначенный как Common Module Trend Micro, способен принимать сообщения от привилегированных приложений пользовательского режима и может выполнять функции, специфичные не только для утилиты RootkitBuster. Иными словами, он используется многими другими программами Trend Micro.
В числе первых действий драйвер создает устройство по адресу \Device\TmComm для приема сообщений IOCTL из пользовательского режима. Для этого устройства создается символическая ссылка по адресу \DosDevices\TmComm (которая доступна через \\.\Global\TmComm). Точка входа инициализирует значительное количество используемых в драйвере классов и структур, однако для целей исследования — выполнения кода ядра — нет необходимости подробно рассматривать каждый из них.
Создание устройства в драйвере tmcomm.sys
Билл обратил внимание на то обстоятельство, что для использования созданного драйвером виртуального устройства необходимо обладать привилегиями SYSTEM, то есть как минимум иметь в системе права администратора. Это значительно сужает возможности использования потенциальных уязвимостей в драйвере, но не исключает их.
Класс TrueApi
Один из наиболее значимых компонентов драйвера — класс TrueApi, который создается в точке входа и содержит указатели на импортируемые функции, используемые драйвером. Структура этого класса выглядит следующим образом:
Если взглянуть на эту структуру внимательно, становится очевидно, что она используется в качестве альтернативы прямому вызову функций. Билл предположил, что программы Trend Micro кешируют эти импортируемые функции в момент инициализации, чтобы избежать перехватов таблицы отложенного импорта. При отложенном импорте прилинкованная DLL загружается только тогда, когда приложение обращается к одной из содержащихся в ней функций. Если в системе поселился руткит, способный перехватывать таблицу импорта в момент загрузки драйвера, необходимо предусмотреть соответствующий защитный механизм.
Класс XrayApi
В драйвере имеется еще один важный класс под названием XrayApi. Он используется для доступа к нескольким низкоуровневым устройствам и непосредственного взаимодействия с файловой системой. Этот класс содержит структуру XrayConfig, в которой сосредоточена его основная конфигурация:
В этой структуре среди прочего есть информация о расположении таких внутренних и недокументированных переменных в ядре Windows, как ExInitializeNPagedLookasideListInternal, IopRootDeviceNode, ExDeleteNPagedLookasideList и PpDevNodeLockTree. Исследователь предположил, что предназначение этого класса — получение прямого доступа к низкоуровневым устройствам в обход документированных (а следовательно, широко известных вирусописателям) методов.
Запросы IOCTL
Перед изучением возможностей и функций драйвера Билл Демиркапи уделил внимание механизму обработки запросов IOCTL. Это специфичные для отдельных (преимущественно низкоуровневых) устройств системные вызовы ввода-вывода, которые не могут быть реализованы с использованием регулярных вызовов. В основной функции диспетчеризации драйвер Trend Micro преобразует данные вместе с запросом IRP_MJ_DEVICE_CONTROL в собственную структуру, которую исследователь назвал TmIoctlRequest:
Таким образом, отправка запросов IOCTL в драйвере tmcomm.sys реализована с помощью своеобразных «таблиц диспетчеризации», при этом «базовая таблица» содержит код IOCTL и соответствующую вспомогательную функцию. Например, если необходимо отправить IOCTL-запрос с кодом 0xDEADBEEF, драйвер сравнивает запрос с каждой строкой базовой таблицы диспетчеризации и передает его только в том случае, если найдет совпадение. Каждая запись в такой таблице имеет структуру, подобную представленной ниже:
После вызова функции DispatchFunction обычно верифицируются передаваемые данные — начиная с проверки nullptr и заканчивая проверкой входных и выходных буферов. Эти «функции вспомогательной диспетчеризации» затем выполняют другой поиск на основе кода, переданного в пользовательском буфере ввода, с целью найти соответствующую запись во вспомогательной таблице. Такие записи используют структуру следующего вида:
Непосредственно перед вызовом модуля PrimaryRoutine, который выполняет запрошенное действие, функция SubDispatchTableEntry вызывает ValidatorRoutine. Эта подпрограмма проверяет входной буфер, то есть проверяет данные, которые будут впоследствии использоваться PrimaryRoutine. Этот основной код выполняется только в том случае, если ValidatorRoutine успешно завершит проверку.
Изучая механизмы обработки запросов IOCTL, Билл Демиркапи внимательно рассмотрел каждую запись базовой таблицы диспетчеризации и хранящиеся там функции. Это, в свою очередь, позволило определить назначение вспомогательных таблиц диспетчеризации.
IoControlCode == 9000402Bh
Первая из рассмотренных Биллом таблиц отвечает за взаимодействие с файловой системой. Код для этой вспомогательной таблицы диспетчеризации получается путем разыменования DWORD из начала входного буфера. То есть, чтобы определить, какую запись вспомогательной таблицы следует выполнить, в начале входного буфера нужно поместить DWORD, соответствующий определенному опкоду. Для упрощения задачи исследователя разработчики из Trend Micro оставили в коде драйвера много отладочных строк, с использованием которых Билл Демиркапи составил таблицу функций PrimaryRoutine, хранящихся во вспомогательной таблице диспетчеризации, и описал их назначение.
IoControlCode == 90004027h
Эта таблица диспетчеризации преимущественно используется для управления сканером процессов. Многие функции в ней используют отдельный поток сканирования для синхронного поиска процессов с помощью различных методов, как документированных, так и недокументированных. Билл Демиркапи также собрал описания основных функций указанной таблицы.
Все эти функции используют несколько структур, которые исследователь назвал MicroTask и MicroScan. Вот как они выглядят в дизассемблированном виде.
Для большинства запросов IOCTL в этой вспомогательной таблице структура MicroScan заполняется на стороне клиента, который вызывает драйвер. Именно эту особенность Демиркапи решил использовать для эксплуатации возможной уязвимости.
Эксплоит
Билл Демиркапи признается, что во время реверсинга функций, хранящихся в этой вспомогательной таблице диспетчеризации, он был совершенно сбит с толку. В итоге оказалось, что указатель ядра MicroScan, возвращаемый такими функциями, как GetProcessesAllMethods, напрямую передавался другим функциям, например DeleteTaskResults, на стороне клиента. Эти функции принимают такой недоверенный указатель ядра и практически без проверки вызывают функции в таблице виртуальных функций, описанной в классе.
Если внимательно посмотреть на «подпрограмму проверки» функции вспомогательной таблицы диспетчеризации DeleteTaskResults, то можно увидеть, что для экземпляра MicroScan, указанного во входном буфере + 0x10, проверка фактически одна: убедиться, что он содержит действительный адрес в памяти ядра.
Проверка экземпляра MicroScan
В DeleteTaskResults используется еще одна простая проверка.
Проверка Tag в экземпляре MicroScan
Далее функция DeleteTaskResults вызывает конструктор, указанный в таблице виртуальных функций экземпляра MicroScan. Чтобы вызвать таким образом произвольную функцию ядра, необходимо выполнить следующие условия.
Исследователь пишет, что правильное решение в поисках способа выделения и управления памятью ядра из пользовательского режима ему подсказал его наставник Алекс Ионеску. В журнале Hack In The Box от 2010 года была опубликована статья Мэтью Юрчика «Резервные объекты в Windows 7». Идея статьи заключается в том, что можно специальным образом сформировать очередь Apc для Apc Reserve Object, а затем использовать NtQuerySystemInformation для поиска нужного Apc Reserve Object в памяти ядра. Это позволяет приложению пользовательского режима аллоцировать и контролировать до 32 байт в памяти ядра (в 64-битной среде) и определять расположение этой памяти.
Такой прием все еще работает в Windows 10, а это означает, что мы можем соблюсти все требования. Используя резервный объект Apc, мы можем выделить как минимум 10 байт для структуры MicroScan и полностью обойти упомянутые выше проверки. В результате появляется возможность вызывать произвольные указатели ядра.
Вызов произвольных указателей ядра с использованием резервных объектов Apc
Билл Демиркапи пришел к выводу, что подобная уязвимость характерна не только для функции DeleteTaskResults, но и для всех функций диспетчеризации, помеченных в таблице звездочкой. Все они доверяют переданному клиентом указателю ядра и вызывают конструктор из таблицы виртуальных функций экземпляра MicroScan без дополнительных проверок.
IoControlCode == 90004033h
Эта таблица диспетчеризации управляет классом TrueApi и включает следующие функции.
Функция IoControlRegisterUnloadNotify привлекла внимание Билла Демиркапи прежде всего потому, что ее упоминание встречалось в отладочных строках. Используя эту функцию из вспомогательной таблицы диспетчеризации, «недоверенный клиент» может зарегистрировать до 16 произвольных процедур, которые вызываются при выгрузке драйвера.
Валидатор данной функции проверяет правильность этого указателя из буфера на стороне клиента. Если вызывающий объект работает в режиме пользователя, средство проверки вызывает указатель ProbeForRead. Если вызывающая сторона находится в режиме ядра, валидатор проверяет, содержит ли указатель действительный адрес памяти ядра.
Эта функция не может непосредственно использоваться в эксплоите из пользовательского режима. Проблема в том, что, если мы используем вызов из режима пользователя, мы должны предоставить указатель пользовательского режима, поскольку валидатор использует ProbeForRead. При выгрузке драйвера вызывается этот указатель пользовательского режима, но он мало что делает из-за ограничений, накладываемых SMEP — механизмом защиты страниц памяти. Позже мы вспомним про эту особенность.
IoControlCode == 900040DFh
Эта вспомогательная таблица диспетчеризации применяется для взаимодействия с Xray API. Хотя Xray API обычно используется при сканировании, реализованном в ядре, функции из этой таблицы предоставляют ограниченный доступ для взаимодействия клиента с физическими дисками.
IoControlCode == 900040E7h
Последняя изученная исследователем таблица диспетчеризации предназначена для поиска в различных структурах системы хуков, которые могут использовать различные руткиты. В ней перечислены проверки, которые выполняет ПО Trend Micro для поиска перехвата вызовов функций и прочих хуков.
Перед подробным анализом функции TMXMSCheckSystemObjectByName2 Билл Демиркапи приводит дизассемблированный листинг нескольких структур, используемых этой функцией:
Функция TMXMSCheckSystemObjectByName2 принимает на вход указатель источника, указатель назначения и размер в байтах. Вызываемый для TMXMSCheckSystemObjectByName2 валидатор проверяет следующее:
Функция TMXMSCheckSystemObjectByName2
Цикл for может показаться пугающим, но все, что он содержит, — оптимизированный метод проверки диапазона памяти ядра. Для каждой страницы памяти в диапазоне от Src до Src + Size функция вызывает MmIsAddressValid. По-настоящему страшны следующие операции.
Копирование Size в указатель Dst
Эти строки принимают недостоверный указатель Src и копируют байты Size в недостоверный указатель Dst. Мы можем использовать операции memmove для чтения произвольного указателя ядра, но как насчет записи в произвольный указатель ядра? Проблема заключается в том, что средство проверки TMXMSCheckSystemObjectByName2 требует, чтобы местом назначения была память пользовательского режима. К счастью, Билл Демиркапи обнаружил в коде еще одну ошибку.
Строка *params->OutSize = Size; берет объект Size из нашей структуры и помещает его в указатель, определяемый OutSize. На что указывает OutSize, не проверяется, поэтому мы можем записывать в DWORD любой вызов IOCTL. Одно предостережение: указатель Src должен указывать на действительную память ядра длиной в байтах, соответствующей значению Size байтов. Чтобы удовлетворить этому требованию, Демиркапи просто передал базу модуля ntoskrnl в качестве источника.
Используя этот произвольный шаблон записи, мы можем использовать ранее найденный трюк выгрузки для выполнения произвольного кода. Хотя процедура валидации не позволяет нам передавать указатель ядра, если вызов выполняется из пользовательского режима, на самом деле нет никакой необходимости проходить через валидатор. Вместо этого с использованием нашего шаблона записи мы можем поместить тот указатель, который мы хотим, в массив процедуры выгрузки, расположенный внутри секции .data драйвера.
Обход сертификации Microsoft WHQL
Пока что мы рассмотрели методы чтения и записи произвольной памяти ядра, но для установки нашего собственного руткита не хватает одного шага. Хотя можно выполнить шелл-код ядра только с использованием примитива чтения/записи, Билл Демиркапи предложил пойти по пути наименьшего сопротивления. Поскольку речь идет о драйвере стороннего производителя, скорее всего, он использует выделенную память NonPagedPool, которую мы можем задействовать для размещения и выполнения нашего вредоносного шелл-кода.
Давай посмотрим, как Trend Micro распределяет память. В самом начале точки входа драйвера программа проверяет, поддерживается ли система, определяя версию и номер сборки ОС. Trend Micro делает это потому, что в программе жестко закодировано несколько смещений, которые отличаются в разных редакциях Windows.
К счастью, глобальная переменная PoolType, которая используется для выделения невыгружаемой памяти NonPagedPool, по умолчанию установлена в 0. Билл Демиркапи заметил, что, хотя изначально это значение равнялось 0, переменная все еще находилась в секции .data, то есть ее можно изменить. Когда исследователь посмотрел на то, что записано в переменной, он увидел, что функция, отвечающая за проверку версии операционной системы, также в некоторых случаях устанавливала значение переменной PoolType.
Установка значения переменной PoolType
Если на компьютере установлена Windows 10 или более новая версия Windows, драйвер предпочитает использовать NonPagedPoolNx. Хорошо с точки зрения безопасности, но плохо для нас. Чтобы использовать уязвимость, нужно найти запасной элемент ExAllocatePoolWithTag c жестко определенным аргументом NonPagedPool, иначе мы не сможем использовать выделенную память драйвера в Windows 10. Но это не так просто. Как насчет функции MysteriousCheck()?
Функция MysteriousCheck()
Функция MysteriousCheck() проверяет, был ли включен Microsoft Driver Verifier. Вместо того чтобы просто использовать функцию NonPagedPoolNx, которая работает в Windows 8 и выше, Trend Micro выполняет явную проверку, чтобы использовать только безопасное распределение памяти.
Драйвер Trend Micro сертифицирован WHQL, а для получения этого сертификата необходима проверка драйверов. В Windows 10 драйверы не выделяют исполняемую память, это гарантирует Driver Verifier. Компания Trend Micro решила не обращать внимания на требования безопасности и разработала драйвер таким образом, чтобы он работал в любой среде тестирования или отладки, которая обнаружит такие нарушения.
Драйвер Trend Micro сертифицирован WHQL
Trend Micro мог просто оставить стандартную проверку Windows 10, зачем вообще создавать явную проверку для Driver Verifier? Единственная рабочая теория, которую и предложил Билл Демиркапи, заключается в том, что по какой-то причине большинство их драйверов несовместимы с NonPagedPoolNx (совместима только их точка входа), в противном случае подобные ухищрения теряют всякий смысл.
Устанавливаем свой руткит с помощью RootkitBuster
Итак, как все-таки можно использовать RootkitBuster для установки в систему собственного руткита? Для этого нужно выполнить всего лишь три несложных шага.
Изучая методы обнаружения руткитов, Билл Демиркапи наткнулся на бесплатную утилиту RootkitBuster компании Trend Micro. Разработчик позиционирует ее как сканер скрытых файлов, записей реестра и master boot record (MBR), предназначенный для идентификации и удаления руткитов. Описание программы гласило, что RootkitBuster способен выявлять несколько методов проникновения руткитов и закрепления их в системе. Это заинтересовало исследователя, и он решил выяснить, что у RootkitBuster спрятано под капотом. Пристальное изучение программы позволило обнаружить примечательную дыру в коде, с помощью которой можно использовать тулзу не только для поиска прячущихся в глубинах Windows вредоносов, но и для установки в систему собственных руткитов.
Установка
Сразу после запуска инсталлятора RootkitBuster Билл обратил внимание на предупреждение Resource Hacker о том, что софтина пытается установить в его систему файл tmcomm.sys — драйвер, используемый некоторыми приложениями Trend Micro.
RootkitBuster устанавливает драйвер до того, как пользователь примет условия лицензионного соглашения (здесь и далее иллюстрации из блога Билла Демиркапи)
Примечательно, что драйвер и сам исполняемый файл сканера были распакованы на диск в папку %TEMP%\RootkitBuster еще до того, как на экране Билла появился текст лицензионного соглашения. Оно, в частности, гласило, что пользователь RootkitBuster обязуется «не пытаться перепроектировать, модифицировать, дизассемблировать, декомпилировать, исследовать исходный код или создавать производные произведения на основе этой программы».
Поэтому Билл взял и завершил процесс инсталлятора с помощью пункта «Закрыть окно» контекстного меню, так и не приняв условия лицензии. Что позволило ему с чистой совестью «дизассемблировать, декомпилировать» и делать с этим продуктом Trend Micro другие вещи, о которых в приличном обществе не принято говорить вслух. Отличный трюк для обхода юридических сложностей!
Драйвер tmcomm.sys
Этот драйвер, обозначенный как Common Module Trend Micro, способен принимать сообщения от привилегированных приложений пользовательского режима и может выполнять функции, специфичные не только для утилиты RootkitBuster. Иными словами, он используется многими другими программами Trend Micro.
В числе первых действий драйвер создает устройство по адресу \Device\TmComm для приема сообщений IOCTL из пользовательского режима. Для этого устройства создается символическая ссылка по адресу \DosDevices\TmComm (которая доступна через \\.\Global\TmComm). Точка входа инициализирует значительное количество используемых в драйвере классов и структур, однако для целей исследования — выполнения кода ядра — нет необходимости подробно рассматривать каждый из них.
Создание устройства в драйвере tmcomm.sys
Билл обратил внимание на то обстоятельство, что для использования созданного драйвером виртуального устройства необходимо обладать привилегиями SYSTEM, то есть как минимум иметь в системе права администратора. Это значительно сужает возможности использования потенциальных уязвимостей в драйвере, но не исключает их.
Класс TrueApi
Один из наиболее значимых компонентов драйвера — класс TrueApi, который создается в точке входа и содержит указатели на импортируемые функции, используемые драйвером. Структура этого класса выглядит следующим образом:
C:
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, в которой сосредоточена его основная конфигурация:
C:
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:
C:
struct TmIoctlRequest
{
DWORD InputSize;
DWORD OutputSize;
PVOID UserInputBuffer;
PVOID UserOutputBuffer;
PVOID Unused;
DWORD_PTR* BytesWritten;
};Таким образом, отправка запросов IOCTL в драйвере tmcomm.sys реализована с помощью своеобразных «таблиц диспетчеризации», при этом «базовая таблица» содержит код IOCTL и соответствующую вспомогательную функцию. Например, если необходимо отправить IOCTL-запрос с кодом 0xDEADBEEF, драйвер сравнивает запрос с каждой строкой базовой таблицы диспетчеризации и передает его только в том случае, если найдет совпадение. Каждая запись в такой таблице имеет структуру, подобную представленной ниже:
C:
typedef NTSTATUS (__fastcall *DispatchFunction_t)(TmIoctlRequest *IoctlRequest);
struct BaseDispatchTableEntry
{
DWORD_PTR IOCode;
DispatchFunction_t DispatchFunction;
};После вызова функции DispatchFunction обычно верифицируются передаваемые данные — начиная с проверки nullptr и заканчивая проверкой входных и выходных буферов. Эти «функции вспомогательной диспетчеризации» затем выполняют другой поиск на основе кода, переданного в пользовательском буфере ввода, с целью найти соответствующую запись во вспомогательной таблице. Такие записи используют структуру следующего вида:
C:
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. Вот как они выглядят в дизассемблированном виде.
C:
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, на стороне клиента. Эти функции принимают такой недоверенный указатель ядра и практически без проверки вызывают функции в таблице виртуальных функций, описанной в классе.
Если внимательно посмотреть на «подпрограмму проверки» функции вспомогательной таблицы диспетчеризации DeleteTaskResults, то можно увидеть, что для экземпляра MicroScan, указанного во входном буфере + 0x10, проверка фактически одна: убедиться, что он содержит действительный адрес в памяти ядра.
Проверка экземпляра MicroScan
В DeleteTaskResults используется еще одна простая проверка.
Проверка Tag в экземпляре MicroScan
Далее функция DeleteTaskResults вызывает конструктор, указанный в таблице виртуальных функций экземпляра MicroScan. Чтобы вызвать таким образом произвольную функцию ядра, необходимо выполнить следующие условия.
- Выделить как минимум 10 байт памяти ядра (для vtable и tag).
- Управлять выделенной памятью ядра, чтобы установить указатель таблицы виртуальных функций и параметр tag.
- Научиться определять адрес этой памяти ядра из пользовательского режима.
Исследователь пишет, что правильное решение в поисках способа выделения и управления памятью ядра из пользовательского режима ему подсказал его наставник Алекс Ионеску. В журнале Hack In The Box от 2010 года была опубликована статья Мэтью Юрчика «Резервные объекты в Windows 7». Идея статьи заключается в том, что можно специальным образом сформировать очередь Apc для Apc Reserve Object, а затем использовать NtQuerySystemInformation для поиска нужного Apc Reserve Object в памяти ядра. Это позволяет приложению пользовательского режима аллоцировать и контролировать до 32 байт в памяти ядра (в 64-битной среде) и определять расположение этой памяти.
Такой прием все еще работает в Windows 10, а это означает, что мы можем соблюсти все требования. Используя резервный объект Apc, мы можем выделить как минимум 10 байт для структуры MicroScan и полностью обойти упомянутые выше проверки. В результате появляется возможность вызывать произвольные указатели ядра.
Вызов произвольных указателей ядра с использованием резервных объектов Apc
Билл Демиркапи пришел к выводу, что подобная уязвимость характерна не только для функции DeleteTaskResults, но и для всех функций диспетчеризации, помеченных в таблице звездочкой. Все они доверяют переданному клиентом указателю ядра и вызывают конструктор из таблицы виртуальных функций экземпляра MicroScan без дополнительных проверок.
IoControlCode == 90004033h
Эта таблица диспетчеризации управляет классом TrueApi и включает следующие функции.
| Опкод | Функция PrimaryRoutine | Описание |
|---|---|---|
| EA60h | IoControlGetTrueAPIPointer | Получает указатели функций в классе TrueApi |
| EA61h | IoControlGetUtilityAPIPointer | Получает указатели служебных функций драйвера |
| EA62h | IoControlRegisterUnloadNotify * | Регистрирует функцию, которая вызывается при выгрузке |
| EA63h | IoControlUnRegisterUnloadNotify | Выгружает ранее зарегистрированную функцию выгрузки |
Функция IoControlRegisterUnloadNotify привлекла внимание Билла Демиркапи прежде всего потому, что ее упоминание встречалось в отладочных строках. Используя эту функцию из вспомогательной таблицы диспетчеризации, «недоверенный клиент» может зарегистрировать до 16 произвольных процедур, которые вызываются при выгрузке драйвера.
Валидатор данной функции проверяет правильность этого указателя из буфера на стороне клиента. Если вызывающий объект работает в режиме пользователя, средство проверки вызывает указатель ProbeForRead. Если вызывающая сторона находится в режиме ядра, валидатор проверяет, содержит ли указатель действительный адрес памяти ядра.
Эта функция не может непосредственно использоваться в эксплоите из пользовательского режима. Проблема в том, что, если мы используем вызов из режима пользователя, мы должны предоставить указатель пользовательского режима, поскольку валидатор использует ProbeForRead. При выгрузке драйвера вызывается этот указатель пользовательского режима, но он мало что делает из-за ограничений, накладываемых SMEP — механизмом защиты страниц памяти. Позже мы вспомним про эту особенность.
IoControlCode == 900040DFh
Эта вспомогательная таблица диспетчеризации применяется для взаимодействия с Xray API. Хотя Xray API обычно используется при сканировании, реализованном в ядре, функции из этой таблицы предоставляют ограниченный доступ для взаимодействия клиента с физическими дисками.
| Опкод | Функция PrimaryRoutine | Описание |
|---|---|---|
| 15F90h | IoControlReadFile | Читает файл прямо с диска |
| 15F91h | IoControlUpdateCoreList | Обновляет указатели ядра, используемые Xray API |
| 15F92h | IoControlGetDRxMapTable | Получает таблицу дисков, сопоставленных с соответствующими им устройствами |
IoControlCode == 900040E7h
Последняя изученная исследователем таблица диспетчеризации предназначена для поиска в различных структурах системы хуков, которые могут использовать различные руткиты. В ней перечислены проверки, которые выполняет ПО Trend Micro для поиска перехвата вызовов функций и прочих хуков.
| Опкод | Функция PrimaryRoutine | Описание |
|---|---|---|
| 186A0h | TMXMSCheckSystemRoutine | Проверка некоторых системных подпрограмм на наличие хуков |
| 186A1h | TMXMSCheckSystemFileIO | Проверка главных функций ввода-вывода файлов на наличие хуков |
| 186A2h | TMXMSCheckSpecialSystemHooking | Проверка типа объекта файла и функции Itoskrnl Io на наличие хуков |
| 186A3h | TMXMSCheckGeneralSystemHooking | Проверка Io Manager на наличие хуков |
| 186A4h | TMXMSCheckSystemObjectByName | Рекурсивное отслеживание системных объектов (каталог или символическая ссылка) |
| 186A5h | TMXMSCheckSystemObjectByName2 * | Копирование системного объекта в память пользовательского режима |
Перед подробным анализом функции TMXMSCheckSystemObjectByName2 Билл Демиркапи приводит дизассемблированный листинг нескольких структур, используемых этой функцией:
C:
struct CheckSystemObjectParams
{
PVOID Src;
PVOID Dst;
DWORD Size;
DWORD* OutSize;
};
struct TXMSParams
{
DWORD OutStatus;
DWORD HandlerID;
CHAR unk[0x38];
CheckSystemObjectParams* CheckParams;
};Функция TMXMSCheckSystemObjectByName2 принимает на вход указатель источника, указатель назначения и размер в байтах. Вызываемый для TMXMSCheckSystemObjectByName2 валидатор проверяет следующее:
- ProbeForRead в объекте CheckParams структуры TXMSParams;
- ProbeForRead иProbeForWrite в объекте Dst структуры CheckSystemObjectParams.
Функция TMXMSCheckSystemObjectByName2
Цикл for может показаться пугающим, но все, что он содержит, — оптимизированный метод проверки диапазона памяти ядра. Для каждой страницы памяти в диапазоне от Src до Src + Size функция вызывает MmIsAddressValid. По-настоящему страшны следующие операции.
Копирование Size в указатель Dst
Эти строки принимают недостоверный указатель Src и копируют байты Size в недостоверный указатель Dst. Мы можем использовать операции memmove для чтения произвольного указателя ядра, но как насчет записи в произвольный указатель ядра? Проблема заключается в том, что средство проверки TMXMSCheckSystemObjectByName2 требует, чтобы местом назначения была память пользовательского режима. К счастью, Билл Демиркапи обнаружил в коде еще одну ошибку.
Строка *params->OutSize = Size; берет объект Size из нашей структуры и помещает его в указатель, определяемый OutSize. На что указывает OutSize, не проверяется, поэтому мы можем записывать в DWORD любой вызов IOCTL. Одно предостережение: указатель Src должен указывать на действительную память ядра длиной в байтах, соответствующей значению Size байтов. Чтобы удовлетворить этому требованию, Демиркапи просто передал базу модуля ntoskrnl в качестве источника.
Используя этот произвольный шаблон записи, мы можем использовать ранее найденный трюк выгрузки для выполнения произвольного кода. Хотя процедура валидации не позволяет нам передавать указатель ядра, если вызов выполняется из пользовательского режима, на самом деле нет никакой необходимости проходить через валидатор. Вместо этого с использованием нашего шаблона записи мы можем поместить тот указатель, который мы хотим, в массив процедуры выгрузки, расположенный внутри секции .data драйвера.
Обход сертификации Microsoft WHQL
Пока что мы рассмотрели методы чтения и записи произвольной памяти ядра, но для установки нашего собственного руткита не хватает одного шага. Хотя можно выполнить шелл-код ядра только с использованием примитива чтения/записи, Билл Демиркапи предложил пойти по пути наименьшего сопротивления. Поскольку речь идет о драйвере стороннего производителя, скорее всего, он использует выделенную память NonPagedPool, которую мы можем задействовать для размещения и выполнения нашего вредоносного шелл-кода.
Давай посмотрим, как Trend Micro распределяет память. В самом начале точки входа драйвера программа проверяет, поддерживается ли система, определяя версию и номер сборки ОС. Trend Micro делает это потому, что в программе жестко закодировано несколько смещений, которые отличаются в разных редакциях Windows.
К счастью, глобальная переменная PoolType, которая используется для выделения невыгружаемой памяти NonPagedPool, по умолчанию установлена в 0. Билл Демиркапи заметил, что, хотя изначально это значение равнялось 0, переменная все еще находилась в секции .data, то есть ее можно изменить. Когда исследователь посмотрел на то, что записано в переменной, он увидел, что функция, отвечающая за проверку версии операционной системы, также в некоторых случаях устанавливала значение переменной PoolType.
Установка значения переменной PoolType
Если на компьютере установлена Windows 10 или более новая версия Windows, драйвер предпочитает использовать NonPagedPoolNx. Хорошо с точки зрения безопасности, но плохо для нас. Чтобы использовать уязвимость, нужно найти запасной элемент ExAllocatePoolWithTag c жестко определенным аргументом NonPagedPool, иначе мы не сможем использовать выделенную память драйвера в Windows 10. Но это не так просто. Как насчет функции MysteriousCheck()?
Функция MysteriousCheck()
Функция MysteriousCheck() проверяет, был ли включен Microsoft Driver Verifier. Вместо того чтобы просто использовать функцию NonPagedPoolNx, которая работает в Windows 8 и выше, Trend Micro выполняет явную проверку, чтобы использовать только безопасное распределение памяти.
Драйвер Trend Micro сертифицирован WHQL, а для получения этого сертификата необходима проверка драйверов. В Windows 10 драйверы не выделяют исполняемую память, это гарантирует Driver Verifier. Компания Trend Micro решила не обращать внимания на требования безопасности и разработала драйвер таким образом, чтобы он работал в любой среде тестирования или отладки, которая обнаружит такие нарушения.
Драйвер Trend Micro сертифицирован WHQL
Trend Micro мог просто оставить стандартную проверку Windows 10, зачем вообще создавать явную проверку для Driver Verifier? Единственная рабочая теория, которую и предложил Билл Демиркапи, заключается в том, что по какой-то причине большинство их драйверов несовместимы с NonPagedPoolNx (совместима только их точка входа), в противном случае подобные ухищрения теряют всякий смысл.
Устанавливаем свой руткит с помощью RootkitBuster
Итак, как все-таки можно использовать RootkitBuster для установки в систему собственного руткита? Для этого нужно выполнить всего лишь три несложных шага.
- Найти любое используемое драйвером распределение NonPagedPool. Пока у тебя не запущен Driver Verifier, можно использовать любые нестраничные выделения памяти, указатели которых хранятся в секции .data. Желательно выбирать распределение, которое используется нечасто.
- Напиши свой шелл-код ядра в любом месте выделенной памяти, используя произвольный примитив записи ядра TMXMSCheckSystemObjectByName2.
- Выполни свой шелл-код, зарегистрировав процедуру выгрузки (непосредственно в секции .data) или используя несколько других методов, представленных в таблице диспетчеризации 90004027h.
