Processos de modo de usuário isolado (IUM)

O Windows 10 introduziu um novo recurso de segurança chamado Virtual Secure Mode (VSM). O VSM aproveita o Hyper-V Hypervisor e o SLAT (Second Level Address Translation) para criar um conjunto de modos chamados VTLs (Virtual Trust Levels). Essa nova arquitetura de software cria um limite de segurança para impedir que processos executados em uma VTL acessem a memória de outra VTL. O benefício desse isolamento inclui mitigação adicional de explorações do kernel enquanto protege ativos como hashes de senha e chaves Kerberos.

O diagrama 1 mostra o modelo tradicional do modo Kernel e o código do modo Usuário em execução no anel 0 e 3 da CPU, respectivamente. Neste novo modelo, o código em execução no modelo tradicional é executado em VTL0 e não pode acessar o VTL1 com privilégios mais altos, onde o Secure Kernel e o Modo de Usuário Isolado (IUM) executam o código. As VTLs são hierárquicas, o que significa que qualquer código em execução em VTL1 é mais privilegiado do que o código em execução em VTL0.

O isolamento VTL é criado pelo Hyper-V Hypervisor que atribui memória no momento da inicialização usando Second Level Address Translation (SLAT). Ele continua isso dinamicamente à medida que o sistema é executado, protegendo a memória que o Secure Kernel especifica que precisa de proteção contra VTL0 porque ele será usado para conter segredos. Como blocos separados de memória são alocados para as duas VTLs, um ambiente de tempo de execução seguro é criado para VTL1 atribuindo blocos de memória exclusivos para VTL1 e VTL0 com as permissões de acesso apropriadas.

Diagrama 1 - Arquitetura IUM

de arquitetura do ium

Fideicomisso

Trustlets (também conhecidos como processos confiáveis, processos seguros ou processos IUM) são programas executados como processos IUM no VSM. Eles completam as chamadas do sistema organizando-as para o kernel do Windows em execução no anel VTL0 0. O VSM cria um pequeno ambiente de execução que inclui o pequeno Secure Kernel em execução em VTL1 (isolado do kernel e drivers em execução em VTL0). O benefício claro de segurança é o isolamento de páginas de modo de usuário confiável em VTL1 de drivers executados no kernel VTL0. Mesmo que o modo kernel do VTL0 seja comprometido por malware, ele não terá acesso às páginas de processo do IUM.

Com o VSM habilitado, o ambiente LSASS (Local Security Authority) é executado como um trustlet. O LSASS gerencia a política do sistema local, a autenticação do usuário e a auditoria, enquanto lida com dados de segurança confidenciais, como hashes de senha e chaves Kerberos. Para aproveitar os benefícios de segurança do VSM, um trustlet chamado LSAISO.exe (LSA Isolado) é executado em VTL1 e se comunica com LSASS.exe em execução em VTL0 por meio de um canal RPC. Os segredos LSAISO são criptografados antes de enviá-los para LSASS em execução no VSM Modo Normal e as páginas do LSAISO são protegidas contra código malicioso executado em VTL0.

Diagrama 2 – LSASS Trustlet Design

Implicações do Modo de Usuário Isolado (IUM)

Não é possível anexar a um processo IUM, inibindo a capacidade de depurar o código VTL1. Isso inclui depuração post mortem de despejos de memória e anexação das Ferramentas de Depuração para depuração ao vivo. Ele também inclui tentativas de contas privilegiadas ou drivers de kernel para carregar uma DLL em um processo de IUM, para injetar um thread ou entregar um APC de modo de usuário. Tais tentativas podem resultar na desestabilização de todo o sistema. As APIs do Windows que comprometeriam a segurança de um Trustlet podem falhar de maneiras inesperadas. Por exemplo, carregar uma DLL em um Trustlet a tornará disponível em VTL0, mas não em VTL1. QueueUserApc pode falhar silenciosamente se o thread de destino estiver em um Trustlet. Outras APIs, como CreateRemoteThread, VirtualAllocEx e Read/WriteProcessMemory também não funcionarão como esperado quando usadas em Trustlets.

Use o código de exemplo abaixo para evitar chamar quaisquer funções que tentem anexar ou injetar código em um processo de IUM. Isso inclui drivers de kernel que enfileiram APCs para execução de código em um trustlet.

Comentários

Se o status de retorno de IsSecureProcess for bem-sucedido, examine o parâmetro SecureProcess _out_ para determinar se o processo é um processo de IUM. Os processos IUM são marcados pelo sistema como "Processos Seguros". Um resultado booleano de TRUE significa que o processo de destino é do tipo 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;
}

O WDK para Windows 10, "Windows Driver Kit - Windows 10.0.15063.0", contém a definição necessária da estrutura PROCESS_EXTENDED_BASIC_INFORMATION. A versão atualizada da estrutura é definida em ntddk.h com o novo campo 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;