Атака на ядро в x86 системах
Попытки защитить ядро предпринимались задолго до выхода висты. Начиная с W2K Microsoft предприняла первый радикальный шаг для защиты ядра от зловредных драйверов, так и норовящих модифицировать кое-что. Однако, для сохранения обратной совместимости с уже написанными программами была предусмотрена лазейка, отключающая защиту, а точнее целых пять:
I. установка параметра EnforceWriteProtection типа DWORD ветки системного реестра HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\MemoryManagement в "0" (изменения вступят в силу только после перезагрузки);
II. сброс флага WP (WriteProtect) в управляющем регистре CR0 (см. листинг 1, 2), — не требует перезагрузки, но доступно только из режима ядра;
III. репаминг страниц — отображаем физический адрес страницы, которую мы хотим модифицировать, на виртуальное адресное пространство "своего" процесса посредством вызова функции NtMapViewOfSection. назначаем все необходимые права и атрибуты, после чего делаем с ней все хотим! таким образом, можно открыть доступ к ядру даже с прикладного уровня, причем _без_ перезагрузки!
IV. запись в псевдоустройство PhysicalMemory, представляющее собой образ физической памяти до трансляции виртуальных адресов и позволяющее модифицировать память ядра даже с прикладного уровня обладая всего лишь правами администратора и без перезагрузки (см. листинг 3);
V. модификация файла NTOSKNRL.EXE на диске — самый уродливый способ из всех, требующий обхода SFC, коррекции контрольной суммы EXE-файла, перезагрузки и к тому же вызывающий серьезные конфликты при установке Service Pack'ов.
mov eax, cr0 ; грузим управляющий регистр cr0 в регистр eax
and eax, 0FFFEFFFFh; сбрасываем бит WP, запрещающий запись
mov cr0, eax ; обновляем управляющий регистр cr0
Листинг 1 код, отключающий защиту ядра от записи
Соответственно, чтобы включить защиту, бит WP нужно установить, что и делают следующие машинные команды:
mov eax, cr0 ; грузим управляющий регистр cr0 в регистр eax
or eax, 10000h ; сбрасываем бит WP, запрещающий запись
mov cr0, eax ; обновляем управляющий регистр cr0
Листинг 2 код, включающий защиту ядра
"Политически корректная" программа должна не просто отключать/включать защиту от записи, а запоминать текущее состояние бита WP перед его изменением, а затем восстанавливать его обратно "как було", иначе можно непроизвольно включить защиту в самый неподходящий момент, серьезно навредив, вирусу или rootlit'у.
Запись в физическую память осуществляется сложнее (к тому же, необходимо предварительно найти код самого ядра, что можно сделать, например, поиском сигнатуры модифицируемой функции в PhysicalMemory, при этом сама функция должна присутствовать в памяти, а не валяться в страничном файле, т. е. прежде чем модифицировать функцию ее необходимо вызывать хотя бы с фиктивными аргументами):
// разные переменные
NTSTATUS ntS; HANDLE Section; OBJECT_ATTRIBUTES ObAttributes;
INIT_UNICODE(ObString, L"\\Device\\PhysicalMemory");
// инициализация атрибутов
InitializeObjectAttributes(&ObAttributes, &ObString,
OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);
// открываем секцию PhysicalMemory
ntS = NtOpenSection(&Section, SECTION_MAP_READ|SECTION_MAP_WRITE, &ObAttributes);
Листинг 3 открытие псевдоустройства PhysicalMemory
В частности, soft-ice работает использует первый способ, большинство антивирусов, брандмауэров и rootkit'ов — второй и третий.
Четвертый способ в основном встречается в rootkit'ах ( и программах, предназначенных для борьбы с ними, типа SDTRestore). Пятый способ обычно используется для превращения 180-дневной версии Windows в "лицензионную".
Первое наступление на rootkit'ы Microsoft предприняла в Windows 2003 Server SP1, закрыв доступ к PhysicalMemory не только администратору, но даже приложениям с привилегиями SYSTEM! Следующий шаг, предпринятый уже в висте — защита ядра цифровой подписью, предотвращающей его модификацию на диске. Во всяком случае теоретически. На практике же, хакеры модифицируют ядро _вместе_ с механизмом проверки цифровой подписи, отламывая последний за ненадобностью.
Предпринятые меры не слишком-то усилили защищенность системы, да и не могли ее усилить, поскольку, закрытие всех лазеек привело бы к неработоспособности огромного количества легальных программ, на что Microsoft пойти не могла, поэтому даже 32-битная редакция висты по-прежнему остается незащищенной.
