Processos de IUM (modo de usuário isolado)
Windows 10 introduziu um novo recurso de segurança chamado VSM (Modo de Segurança Virtual). O VSM aproveita o Hipervisor do Hyper-V e a SLAT (Conversão de Endereços de Segundo Nível) para criar um conjunto de modos chamados VTLs (Níveis de Confiança Virtual). Essa nova arquitetura de software cria um limite de segurança para impedir que processos em execução em uma VTL acessem a memória de outra VTL. O benefício desse isolamento inclui mitigação adicional de explorações de kernel enquanto protege ativos como hashes de senha e chaves Kerberos.
O diagrama 1 ilustra o modelo tradicional do modo Kernel e o código do modo usuário em execução no anel de CPU 0 e no anel 3, respectivamente. Nesse novo modelo, o código em execução no modelo tradicional é executado no VTL0 e não pode acessar o VTL1 com privilégios mais altos, em que o Kernel Seguro e o IUM (Modo de Usuário Isolado) executam o código. As VTLs são hierárquicas, o que significa que qualquer código em execução no VTL1 é mais privilegiado do que o código em execução no VTL0.
O isolamento de VTL é criado pelo Hipervisor do Hyper-V que atribui memória no momento da inicialização usando slat (conversão de endereços de segundo nível). Ele continua isso dinamicamente à medida que o sistema é executado, protegendo a memória que o Kernel Seguro especifica que precisa de proteção contra VTL0 porque ele será usado para conter segredos. À medida que blocos de memória separados são alocados para as duas VTLs, um ambiente de runtime seguro é criado para VTL1 atribuindo blocos de memória exclusivos a VTL1 e VTL0 com as permissões de acesso apropriadas.
Diagrama 1 – Arquitetura de IUM
Trustlets
Trustlets (também conhecidos como processos confiáveis, processos seguros ou processos de IUM) são programas em execução como processos de IUM no VSM. Eles completam as chamadas do sistema fazendo marshaling delas para o kernel do Windows em execução no anel VTL0 0. O VSM cria um ambiente de execução pequeno que inclui o pequeno Kernel Seguro em execução no VTL1 (isolado do kernel e dos drivers em execução no VTL0). O benefício de segurança clara é o isolamento de páginas de modo de usuário trustlet no VTL1 de drivers em execução 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 (Autoridade de Segurança Local) é executado como um trustlet. O LSASS gerencia a política do sistema local, a autenticação do usuário e a auditoria enquanto manipula 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 no VTL1 e se comunica com LSASS.exe em execução no VTL0 por meio de um canal RPC. Os segredos LSAISO são criptografados antes de enviá-los para o LSASS em execução no Modo Normal do VSM e as páginas de LSAISO são protegidas contra código mal-intencionado em execução no VTL0.
Diagrama 2 – Design de Trustlet LSASS
Implicações do IUM (modo de usuário isolado)
Não é possível anexar a um processo de IUM, inibindo a capacidade de depurar o código VTL1. Isso inclui a depuração post mortem de despejos de memória e a anexação das Ferramentas de Depuração para depuração dinâmica. Ele também inclui tentativas de contas privilegiadas ou drivers de kernel de carregar uma DLL em um processo de IUM, injetar um thread ou fornecer um APC no modo de usuário. Tais tentativas podem resultar em 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 disponibilizará no VTL0, mas não na VTL1. QueueUserApc poderá 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 conforme o esperado quando usadas em trustlets.
Use o código de exemplo abaixo para impedir a chamada de qualquer função que tente 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 retorno status de IsSecureProcess for bem-sucedido, examine o parâmetro SecureProcess _Out_ para determinar se o processo é um processo de IUM. Os processos de IUM são marcados pelo sistema como "Processos Seguros". Um resultado booliano 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, "Kit de Driver do Windows – 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;