Você sabia que um driver completamente legítimo pode dar ao invasor a oportunidade de se registrar no sistema por um longo tempo, permanecendo dentro mesmo após a reinstalação? Ou transformar seu computador em um tijolo? Por exemplo, alguns drivers aparentemente confiáveis (assinados) inofensivos são ferramentas para substituir o BIOS. Após esse ataque, apenas o programador salvará.
No Windows, existem aplicativos / scripts / bibliotecas confiáveis com interessante funcionalidade perigosa, como a execução de código arbitrário, o download de arquivos, o desvio do UAC etc. Se essa funcionalidade adicional for encontrada em um componente do kernel, ela se torna ainda mais interessante.
A partir do Windows Vista x64, aplica-se a política DSE (Driver Signature Enforcement) - todos os drivers no nível do kernel devem ser assinados. Se um invasor (com direitos de usuário / administrador), após penetrar no sistema, deseja obter o nível máximo de acesso (instalar rootkit / bootkit / SMM-rootkit / BIOS-rootkit), ele precisará, de alguma forma, ignorar o requisito de assinatura do driver. A capacidade de chamar determinadas funções ou instruções do modo kernel no modo kernel pode fornecer ao invasor uma ferramenta para elevar privilégios, divulgar informações ou causar uma negação de serviço. Chamamos essa funcionalidade de funcionalidade dupla (em alguns casos, isso pode ser chamado de vulnerabilidades ou backdoors, no entanto, a discussão sobre a definição correta está além do escopo deste artigo).
Soluções alternativas DSE
Vejamos quais opções um invasor geralmente tem para ignorar o DSE (você deve, de alguma forma, penetrar no ring0). A tabela abaixo resume as maneiras de ignorar o DSE com suas vantagens e desvantagens (para o atacante e os guardas de segurança, observe). Vale ressaltar que essas informações se aplicam ao Windows x64, começando com o Vista.
Como você pode ver na tabela, um driver assinado com funcionalidade de dupla finalidade é a maneira mais atraente de ignorar o DSE para um invasor.
Funcionalidade perigosa ou de dupla finalidade
Vejamos exemplos de recursos maliciosos que um invasor aparece na presença de um driver com funções perigosas de dupla finalidade.
- Escalonamento de privilégios para o nível de administrador / SISTEMA. É necessário ler / gravar memória física. Este ataque pode ser realizado, por exemplo, usando o driver ASMMAP da ASUS. Para fazer isso, leia a memória física e encontre a estrutura EPROCESS (é um elemento de uma lista vinculada) e, em seguida, percorra a lista em busca do processo cujo nível de privilégio queremos aumentar, além de algum processo conhecido com o nível SYSTEM (por exemplo, lsass, wininit). Em seguida, copie o valor do campo Token da estrutura do processo do sistema para a estrutura do processo de destino. Uma descrição mais detalhada do ataque é dada aqui .
- Desabilitando o SMEP. Para fazer isso, você precisa escrever no registro de controle cr4 (mais precisamente, redefinir seu 20º bit). Por exemplo, o driver bandainamcoonline.sys não apenas desabilita o SMEP, mas também executa o código de maneira útil de acordo com o ponteiro passado a ele pelo usuário. Para os interessados, há um artigo com uma descrição detalhada do driver.
Execução de código arbitrário no modo kernel. É necessário ler / gravar memória física e MSR. O significado é substituir o endereço (localizado em um dos MSRs), para o qual a transição será feita ao fazer uma chamada do sistema, para o endereço do local do código do invasor. Aqui você pode encontrar mais informações sobre isso. O PatchGuard irá interferir ao longo do caminho, mas você pode descobrir se desejar.
Como o driver e o PatchGuard são executados no anel 0, nada impede que o driver desative as verificações do PatchGuard (até, é claro, até que a Microsoft ouça a Intel e vá além do modelo com dois anéis de proteção). Os desenvolvedores de kernel da Microsoft estão bem cientes desse fato e executam várias ações para ocultar a localização desse código, ofuscar suas ações e as estruturas internas usadas. Em outras palavras, devido à incapacidade de impedir que você modifique o código PatchGuard, eles tentam ao máximo escondê-lo.
- Blunden B. O arsenal Rootkit: Escape e evasão nos cantos escuros do sistema.
O originalDado que o código do driver e o código do PatchGuard são executados no Ring 0, não há nada para impedir que um KMD desative as verificações do PatchGuard (a menos que, é claro, a Microsoft aceite a sugestão da Intel e vá além de um modelo de privilégio de dois toques). Os engenheiros de kernel da Microsoft estão cientes desse fato e realizam todos os tipos de acrobacias de programação para ofuscar onde reside o código, o que faz e as estruturas de dados internas que ele manipula. Em outras palavras, eles não podem impedir que você modifique o código do PatchGuard, então eles tentarão ocultá-lo.
- Blunden B. O arsenal Rootkit: Escape e evasão nos cantos escuros do sistema.
- Entrada do BIOS. Um exemplo na natureza é Lojax . Os invasores pegaram o conhecido RwDrv.sys e o usaram para seus propósitos sujos: leram o BIOS, modificaram e escreveram de volta. A reinstalação do Windows não ajudará aqui, pois o código malicioso fica no firmware no SPI-flash. Se a substituição do BIOS não for bem sucedida (ou substituída especialmente), também será desagradável. De qualquer forma, você terá que dirigir após o programador para corrigir as conseqüências irritantes.
- Ligue para o manipulador SMI. Em primeiro lugar, nem todos os BIOSs são igualmente indefesos contra o código no modo ring0: existem vários mecanismos para proteção de leitura / gravação; portanto, pode haver uma situação em que você precise ir mais baixo - para o modo SMM (o mais privilegiado). Uma maneira de chegar lá do modo kernel é puxar o manipulador SMI (geralmente existem vulneráveis entre eles). Para chamar o manipulador SMI, você deve poder gravar na porta de E / S, e isso só pode ser feito com privilégios ring0. Ou seja, um driver com capacidade de gravar em portas de E / S é capaz de detectar um manipulador SMI vulnerável que pode permitir que um invasor execute código no modo SMM. No exemplo, o autor usa o driver RwDrv.sys.
- Informações sobre o sistema. Lendo a memória do kernel (através da leitura da memória física), lendo o BIOS, informações sobre configurações do sistema, dispositivos conectados e mecanismos de proteção habilitados / desabilitados (através da leitura do MSR, registros de controle, acesso às portas de entrada / saída), em alguns casos, um hipervisor conhecido pode ser detectado ( como o VirtualBox via MSR ). Para esta tarefa, mesmo um driver que apenas pode ler, não necessariamente escrever, é mais adequado. Por exemplo, RamCaptureDriver64.sys da Belkasoft é adequado para leitura de memória física.
Se analisarmos vários artigos e notas sobre o CVE, podemos distinguir algumas classificações de potencialmente perigosas ao acessar as funções ring3 nos drivers. A tabela abaixo lista as funções perigosas e as fontes de informações sobre eles.
E esta não é a lista completa de possíveis funções perigosas. Você também pode falar sobre leitura / gravação de memória virtual do kernel, leitura / gravação de MMIO, acesso a dispositivos PCI, etc.
As três primeiras funções são do maior interesse e do maior perigo (e o mais provável de detectar um driver com essas funções): ler / gravar registros MSR, ler / gravar portas de E / S, ler / gravar memória física. Usando registros de controle, você pode ignorar alguns mecanismos de proteção, gravar no registro de sinalizador permite ativar as portas de entrada / saída de leitura / gravação no ring3 (a propósito, é mencionado neste artigo em Habré), o sucesso de ataques a canais de terceiros (acessando o cache, monitorando contadores) desempenho / ciclos) provavelmente não é provável.
No processo de criação deste material na conferência DEFCON 27 em Las Vegas, os pesquisadores Jesse Michael e Mickey Shkatov apresentaram o trabalho "Saia do kernel se não puder dirigir" , que também discute esse problema, e recomendamos que você estude esse material para concluir a imagem. Os cenários para o uso desses drivers são muito simples e claros, e são apresentados exemplos de seções de código responsáveis pela funcionalidade mais crítica. E também fornece código para trabalhar e encontrar drivers semelhantes.
Em geral, vale ressaltar que esse tópico há muito se preocupa com os pesquisadores de segurança. Em 2018, o pesquisador Alexander Matrosov em seu artigo "O que torna os drivers do SO perigosos para o BIOS?" levantou essa questão e demonstrou como é simples explorar o BIOS.
Drivers de função dupla
Abaixo estão os representantes mais famosos dos motoristas com funções de dupla finalidade.
O RwDrv.sys é um driver muito popular (fornecido com o utilitário RWeverything ). Lê e grava memória física, portas de E / S, MSR e registros de controle. Foi usado repetidamente em vários PoCs e, em seguida, no rootkit Lojax mencionado anteriormente. Uma interface é escrita para ele em C ++ e também é usada em chipsec .
cpuz / gpuz
Lê e grava memória física, portas e MSR. Existem vários utilitários de PoC usando-o ( aqui e aqui ).
pcdsrvc_x64 - driver da Dell, para obter mais informações, entre em contato com este post. Permite ler / gravar memória física nas portas de E / S.
AsIO64.sys
Ele fornece a capacidade de ler / gravar memória física e portas de E / S e também vem com uma dll conveniente para executar essas solicitações.
O Asmmap64.sys é outro driver da ASUS que permite ler / gravar memória física, portas de E / S e MSR. Seria especialmente agradável para um invasor, pois o acesso ao driver pode ser feito por um usuário comum sem direitos de administrador. Pessoas curiosas podem recorrer à fonte .
ntiolib_x64.sys / winio64.sys - drivers da MSI, são descritos em detalhes no artigo mencionado anteriormente. Usando o ntiolib_x64.sys, você pode ler / gravar memória física, portas de E / S e MSR, o winio64.sys fornece todas essas funções, exceto o MSR.
Geralmente, as funções perigosas descritas são reconhecidas como vulnerabilidades se o driver estiver acessível ao usuário sem direitos de administrador (ACL incorreta) ou quando permitir executar código arbitrário diretamente (como em bandainamcoonline.sys). Em outros casos, isso é apenas funcionalidade e, como o usuário possui direitos de administrador, ele pode usar todas as funções do driver e essa é a norma.
Se você acha que não há mais de uma dúzia desses drivers, está muito enganado. Você pode ver esta seleção de drivers interessantes. Esta lista contém drivers da ASUS, AVAST, Razer, LG, American Megatrends e outras empresas conhecidas. Portanto, existem muitos deles, você só precisa pesquisar. Então, eles representam uma ameaça real.
Essa ameaça também é entendida pelos funcionários da Microsoft. E eles serão gratos por informações sobre esses drivers;)
Recomendações
Para usuários:
- Você não deve sentar-se desnecessariamente na conta de administrador e desativar o UAC (embora não seja difícil contorná- la).
- Você pode instalar o detector tentando instalar drivers (por exemplo, aqui ).
- Se for necessário usar utilitários com esses drivers (diagnóstico, para atualizar o BIOS etc.), remova os drivers após o uso.
- Configure o Device Guard (se você é um feliz proprietário do Windows 10). Usando essa tecnologia, você pode criar sua própria política de integridade de código e adicionar listas brancas de programas e certificados. Por exemplo, adicione à política o requisito de que qualquer driver no modo kernel tenha uma assinatura Microsoft WHQL. Nesta postagem, você pode se familiarizar melhor com a configuração do Device Guard para essa finalidade.
É melhor que os fabricantes não assinem esses drivers. Se o usuário precisar atualizar o BIOS, verificar se há vulnerabilidades no sistema (olá, chipsec), medir o desempenho ou executar outras manipulações que exijam a instalação desses drivers, ele pode muito bem entrar no modo de teste, fazer tudo isso e sair. A usabilidade cairá, mas a segurança aumentará.
Conclusões
Se algo está assinado, você não pode confiar de qualquer maneira. Primeiro, você pode assinar algo assim e, segundo, um invasor pode tirar proveito desse assinado (mesmo que seja de um fabricante confiável).
Os especialistas em segurança da informação não devem excluir do modelo de ameaças situações em que um invasor exige que um driver com funcionalidade perigosa realize um ataque. Existem drivers suficientes; é bastante simples fazer isso. Se o ataque não for realizado com um driver pop como o RwEverything, mas com um menos conhecido, será ainda mais difícil detectá-lo. Portanto, você precisa estar alerta, monitorar essas coisas e não permitir que cada driver inicialize no sistema.
Autor: Elizaveta Khomenko