Процессы изолированного пользовательского режима (IUM)

Windows 10 появилась новая функция безопасности с именем Виртуальный безопасный режим (VSM). VSM использует гипервизор Hyper-V и преобразование адресов второго уровня (SLAT) для создания набора режимов, называемых виртуальными уровнями доверия (VTL). Эта новая архитектура программного обеспечения создает границу безопасности, чтобы предотвратить доступ процессов, выполняющихся в одном VTL, к памяти другого VTL. Преимущество этой изоляции включает в себя дополнительное устранение эксплойтов ядра при одновременной защите ресурсов, таких как хэши паролей и ключи Kerberos.

На схеме 1 показана традиционная модель режима ядра и кода пользовательского режима, выполняющихся в кольцах ЦП 0 и 3 соответственно. В этой новой модели код, выполняемый в традиционной модели, выполняется в VTL0 и не может получить доступ к более привилегированной версии VTL1, где выполняются коды Secure Kernel и Isolated User Mode (IUM). Виртуальные библиотеки являются иерархическими, что означает, что любой код, выполняемый в VTL1, является более привилегированным, чем код, выполняемый в VTL0.

Изоляция VTL создается гипервизором Hyper-V, который назначает память во время загрузки с помощью преобразования адресов второго уровня (SLAT). Он продолжает это динамически по мере выполнения системы, защищая память, указанную защищенным ядром, требующую защиты от VTL0, так как она будет использоваться для хранения секретов. Так как для двух виртуальных библиотек выделены отдельные блоки памяти, создается безопасная среда выполнения для VTL1 путем назначения монопольных блоков памяти VTL1 и VTL0 с соответствующими разрешениями доступа.

Схема 1. Архитектура IUM

Доверенные адреса

Доверенные (также называемые доверенными процессами, безопасными процессами или процессами IUM) — это программы, выполняемые как процессы IUM в VSM. Они выполняют системные вызовы, маршалируя их в ядро Windows, работающее в VTL0 ring 0. VSM создает небольшую среду выполнения, которая включает в себя небольшое безопасное ядро, выполняемое в VTL1 (изолированное от ядра и драйверов, работающих в VTL0). Явным преимуществом безопасности является изоляция страниц пользовательского режима trustlet в VTL1 от драйверов, работающих в ядре VTL0. Даже если режим ядра VTL0 скомпрометирован вредоносными программами, он не будет иметь доступа к страницам процесса IUM.

Если vsm включен, среда локального центра безопасности (LSASS) выполняется как доверенный. LSASS управляет политикой локальной системы, проверкой подлинности пользователей и аудитом при обработке конфиденциальных данных безопасности, таких как хэши паролей и ключи Kerberos. Чтобы использовать преимущества vsm в области безопасности, доверенный LSAISO.exe (LSA Isolated) выполняется в VTL1 и взаимодействует с LSASS.exe, работающими в VTL0, через канал RPC. Секреты LSAISO шифруются перед их отправкой в LSASS, работающий в обычном режиме VSM, а страницы LSAISO защищены от вредоносного кода, выполняющегося в VTL0.

Схема 2. Проектирование доверенных модулей LSASS

Последствия изолированного пользовательского режима (IUM)

Невозможно подключиться к процессу IUM, что препятствует возможности отладки кода VTL1. Сюда входит посмертная отладка дампов памяти и подключение средств отладки для динамической отладки. Он также включает попытки привилегированных учетных записей или драйверов ядра загрузить библиотеку DLL в процесс IUM, внедрить поток или доставить APC в пользовательском режиме. Такие попытки могут привести к дестабилизации всей системы. Api Windows, которые могут поставить под угрозу безопасность Trustlet, могут неожиданно завершиться сбоем. Например, загрузка библиотеки DLL в trustlet сделает ее доступной в VTL0, но не в VTL1. QueueUserApc может автоматически завершиться сбоем, если целевой поток находится в trustlet. Другие API, такие как CreateRemoteThread, VirtualAllocEx и Read/WriteProcessMemory, также не будут работать должным образом при использовании с trustlets.

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

Комментарии

Если состояние isSecureProcess возвращается успешно, проверьте параметр SecureProcess _Out_, чтобы определить, является ли процесс процесс процессом IUM. Процессы IUM помечены системой как "Безопасные процессы". Логический результат TRUE означает, что целевой процесс относится к типу IUM.

NTSTATUS
IsSecureProcess(
   _In_ HANDLE ProcessHandle,
   _Out_ BOOLEAN *SecureProcess
   )
{
   NTSTATUS status;

       // definition included in ntddk.h  
   PROCESS_EXTENDED_BASIC_INFORMATION extendedInfo = {0};
 
   PAGED_CODE(); 
  
   extendedInfo.Size = sizeof(extendedInfo);

   // Query for the process information  
   status = ZwQueryInformationProcess(
                  ProcessHandle, ProcessBasicInformation, &extendedInfo,
                  sizeof(extendedInfo), NULL);

   if (NT_SUCCESS(status)) {
      *SecureProcess = (BOOLEAN)(extendedInfo.IsSecureProcess != 0);
   }
 
          return status;
}

WDK для Windows 10 "Комплект драйверов Windows — Windows 10.0.15063.0" содержит требуемое определение структуры PROCESS_EXTENDED_BASIC_INFORMATION. Обновленная версия структуры определена в ntddk.h с новым полем IsSecureProcess.

typedef struct _PROCESS_EXTENDED_BASIC_INFORMATION {
    SIZE_T Size;    // Ignored as input, written with structure size on output
    PROCESS_BASIC_INFORMATION BasicInfo;
    union {
        ULONG Flags;
        struct {
            ULONG IsProtectedProcess : 1;
            ULONG IsWow64Process : 1;
            ULONG IsProcessDeleting : 1;
            ULONG IsCrossSessionCreate : 1;
            ULONG IsFrozen : 1;
            ULONG IsBackground : 1;
            ULONG IsStronglyNamed : 1;
            ULONG IsSecureProcess : 1;
            ULONG IsSubsystemProcess : 1;
            ULONG SpareBits : 23;
        } DUMMYSTRUCTNAME;
    } DUMMYUNIONNAME;
} PROCESS_EXTENDED_BASIC_INFORMATION, *PPROCESS_EXTENDED_BASIC_INFORMATION;