CVE-2015-2291

(1) IQVW32.sys antes da versão 1.3.1.0 e (2) IQVW64.sys antes da versão 1.3.1.0 no driver de diagnóstico Intel Ethernet para Windows permite que usuários locais causem negação de serviço ou possivelmente executem código arbitrário com privilégios de kernel por meio de uma chamada IOCTL especialmente criada: (a) 0x80862013, (b) 0x8086200B, (c) 0x8086200F ou (d) 0x80862007.

Visão Geral

Este repositório contém uma análise da vulnerabilidade em questão, juntamente com exploits de prova de conceito funcionais em Windows 7 SP1 de 64 bits e Windows 10 20H2. O arquivo do driver pode ser localizado no diretório Driver Files. Se você descobrir erros de digitação ao longo da análise/documento, ou se quiser ver determinados detalhes com uma descrição mais elaborada, por favor, abra uma issue no repositório! Vou corrigi-los o mais rápido possível.

Motivação

A motivação por trás de escrever um exploit para este driver de dispositivo em particular é unicamente porque ele está atualmente sendo abusado na natureza para carregar um root-kit não assinado de um atacante. Usando o método BYOVD (Bring Your Own Vulnerable Driver), o malware pode verificar se está rodando com privilégios elevados, soltar uma cópia do driver de dispositivo vulnerável, carregar o driver e, subsequentemente, explorá-lo para obter execução de código no kernel e carregar o root-kit. Não consegui fazer engenharia reversa com sucesso na amostra do malware, então tomei a iniciativa de criar o exploit.

Amostras encontradas na natureza: https://bazaar.abuse.ch/sample/84ed7fec67de5621806dbb43af5167a5fc60ab7f2403448519dc0eca2b8f9022/ https://bazaar.abuse.ch/sample/0925b8985b19d7925d68186d666b0050a4cb3f2a577d64765d770a57a2eab9ae/ https://bazaar.abuse.ch/sample/e8b7f42d544fe8b954c4021315cff2fdd44d67d11704009cdf3037d34e0c0a93/

CVE-2015-2291 - Análise Técnica de um Exploit

O driver de dispositivo, nomeadamente iqvw64e.sys, é um driver projetado para realizar diagnósticos do adaptador de rede. Ele permite que o componente em modo de usuário interaja com o driver de dispositivo para executar uma infinidade de rotinas de kernel, expondo alguns códigos de controle de E/S (também conhecidos como IOCTLs), com um código de controle de E/S "sub" fornecido no buffer de entrada do usuário durante a interação. O código de controle de E/S que será usado para atingir o caminho de código vulnerável é 0x80862007. Além do código de controle primário, os mencionados códigos de controle de E/S "sub" que serão abordados nesta análise serão o código 0x33 para atingir a chamada de função memmove, e o código 0x30 para atingir os caminhos de código da chamada de função memset. Esta análise não cobrirá nenhum detalhe sobre a rotina DriverEntry, pois há documentação suficiente na página de Documentação da Microsoft para lhe dar uma explicação completa.

Para começar, queremos saber como podemos interagir com este driver de dispositivo específico em primeiro lugar. O meio mais comum de se comunicar com um driver de dispositivo é através do uso de uma função chamada DeviceIoControl. A ideia geral por trás dessa função é que podemos passar um handle de driver válido criado por CreateFileA, passar um código de controle de E/S que corresponda à rotina de kernel que queremos, passar uma estrutura (ou buffer) que ela espera, e ela retornará dados no nosso buffer de saída. Embora rotinas como essas possam ser, às vezes, necessárias (ex.: acessar registradores específicos do modelo para fins de overclocking), elas também apresentam um sério risco à segurança. Mas... como?

No caso da CVE-2015-2291, a vulnerabilidade pode ser acionada por um usuário sem privilégios. Como não existem verificações de sanitização e privilégios de administrador não são necessários para explorar a vulnerabilidade, isso representa um risco de segurança. O que está subjacente a essas duas falhas é a capacidade de controlar totalmente as chamadas de função memset e memmove expostas pela interface de código de controle de E/S. Lembra-se da função DeviceIoControl mencionada anteriormente, de como podemos passar uma estrutura que será usada em uma rotina de kernel? É assim que tudo se conecta.

Vamos dar um passo para trás. Primeiro, queremos obter o handle do driver relacionado ao driver de dispositivo vulnerável. Mesmo antes disso, precisamos localizar o objeto de dispositivo nomeado correspondente. Eles são expostos ao espaço do usuário por um link simbólico (normalmente codificado), que pode ser encontrado usando o WinObj, parte da [suíte SysInternals]. Embora pudéssemos usar um utilitário de despejo de strings para despejar o link simbólico, ou, alternativamente, fazer engenharia reversa do driver de dispositivo, eu simplesmente carreguei o driver de dispositivo e o localizei usando o WinObj. O link simbólico encontrado em relação ao driver de dispositivo é \\.\GLOBALROOT\Device\Nal. Para obter o handle do driver, precisamos chamar a função CreateFileA e fazer com que ela retorne um handle de driver válido para usarmos mais tarde no processo. O código para este processo é o seguinte:```C if (h_nal == (HANDLE)-1) { printf("\n[-] Unable to obtain a driver handle to the Nal device driver. Error: %d (0x%x)", GetLastError(), GetLastError()); unused = getchar(); return 1; } printf("\n[+] Obtained a driver handle to the Nal device driver. Handle Value: 0x%p", h_nal);

Usaremos o handle do driver mais adiante no processo de exploração. Por enquanto, vamos começar a preparação do nosso exploit. O próximo passo seria carregar a biblioteca `ntdll.dll` usando a função [LoadLibraryA](https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya) para retornar um [module handle](https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types), de modo que possamos localizar dinamicamente as funções de que precisamos. Embora a biblioteca `ntdll.dll` já possa estar carregada em nosso processo, precisamos mesmo assim obter um handle para a biblioteca que possamos usar. As funções de que precisamos para a exploração são [NtQuerySystemInformation](https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntquerysysteminformation) para vazar o endereço base do kernel do NT (com integridade média de processo) para mais adiante no processo de exploração, e a função [NtQueryIntervalProfile](http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FNT%20Objects%2FProfile%2FNtQueryIntervalProfile.html) para disparar a vulnerabilidade. Quanto ao código para carregar a biblioteca `ntdll.dll`, é o seguinte:```C
h_ntdll = LoadLibraryA("C:\\Windows\\System32\\ntdll.dll");
if (!h_ntdll)
{
	printf("\n[-] Failed to load the \"ntdll.dll\" API library. Error: %d (0x%x)", GetLastError(), GetLastError());
	unused = getchar();
	return 0;
}
printf("\n[+] Loaded the \"ntdll.dll\" API library. Handle Value: 0x%p", h_ntdll);

Agora que obtivemos um handle para a biblioteca, começaremos localizando a função NtQueryIntervalProfile. Para começar, precisaremos de uma definição de tipo para esta função, pois ela não é documentada. Embora você possa encontrar a definição de tipo online, eu a forneci aqui para facilitar o acesso:```C typedef unsigned int(__stdcall* NtQueryIntervalProfile)(