Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Os testes de penetração de fundamentos de dispositivo executam várias formas de ataques de entrada, que são um componente crítico dos testes de segurança. Os testes de ataque e penetração podem ajudar a identificar vulnerabilidades em interfaces de software.
Penetração
Os testes de penetração incluem duas categorias: Fuzz tests e testes de I/O Spy e I/O Attack. Os testes Fuzz também foram um recurso da ferramenta de teste Device Path Exerciser.
| Teste | Descrição |
|---|---|
Desativar espião de E/S |
Desative Spy de E/S em 1 ou mais dispositivos. Binário de teste: Devfund_IOSpy_DisableSupport.wsc Método de teste: DisableIoSpy Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DQ |
Mostrar Dispositivo E/S com Espionagem Habilitada |
Dispositivos de exibição que têm espião de E/S ativado neles. Binário de teste: Devfund_IOSpy_DisplayEnabledDevices.wsc Método de teste: DisplayIoSpyDevices |
Ativar espião de E/S |
Habilite o Espião de E/S em um ou mais dispositivos. Binário de teste: Devfund_IOSpy_EnableSupport.wsc Método de teste: EnableIoSpy Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DQ DFD - especifica o caminho para o arquivo de dados do IoSpy. O local padrão é %SystemDrive%\DriverTest\IoSpy |
Teste da API Fuzz Misc |
Os testes da API Fuzz Misc são testes que determinam se o driver pode lidar com uma variedade de chamadas comuns de drivers de modo kernel. Os testes incluem os seguintes testes:
Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoMiscAPITest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DoPoolCheck DQ CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
API Fuzz Misc com teste de consulta de comprimento zero |
Este teste executa os mesmos testes que o teste Fuzz Misc API e, desta vez, passa uma consulta em branco (comprimento zero) e um endereço de buffer inválido para o driver ao tentar recuperar os atributos estendidos de um arquivo. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoMiscAPIWithZeroLengthTest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DoPoolCheck DQ CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
Teste de abertura e fechamento do Fuzz |
Este teste executa milhares de sequências create-open-close. Para obter informações detalhadas sobre esse teste, consulte Sobre o teste de abertura e fechamento do Fuzz. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoOpenCloseTest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DoPoolCheck DQ CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
teste de Consulta Fuzz e Definição de Informações de Arquivo |
Esse teste emite chamadas para recuperar e alterar as informações de objeto, arquivo e volume dos dispositivos. Durante o teste de Informações de Arquivo de Consulta e Conjunto , o teste Fuzz emite chamadas para recuperar e alterar as informações de objetos, arquivos e volumes de dispositivos abertos pelas Operações de Abertura Básicas e outras operações abertas, incluindo as operações realizadas pelo teste Fuzz Sub-opens. O teste Fuzz emite cada comando de consulta ou atribuição pelo menos 1024 vezes com um buffer válido e uma variedade de comprimentos de buffer e classes de informações de ficheiro. Uma solicitação de cada tipo também é enviada com um ponteiro de buffer inválido e um comprimento de buffer igual a zero. Se utilizar o parâmetro ChangeBufferProtectionFlags, que define a opção de proteção, o teste Fuzz varia a configuração de segurança no buffer em cada chamada de consulta e de definição. Este teste também executa o teste Fuzz Sub-opens. Este teste usa o ZwQueryInformationFile, ZwSetInformationFile, ZwQueryVolumeInformationFilee ZwSetVolumeInformationFile funções. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoQueryAndSetFileInformationTest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DoPoolCheck DQ CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
Teste de Fuzz Query e Set de Segurança |
Este teste emite chamadas para recuperar o descritor de segurança e alterar o estado de segurança dos dispositivos. Durante o Teste de Segurança de Consulta e Configuração , o teste Fuzz gera chamadas para recuperar o descritor de segurança e alterar o estado de segurança dos dispositivos abertos pelas Operações Abertas Básicas e outras operações abertas, incluindo as operações executadas pelo teste Fuzz Sub-opens. o teste Fuzz emite cada consulta ou chamada definida pelo menos 1024 vezes com um buffer válido e uma variedade de comprimentos de buffer e tipos de informações de segurança (OWNER_SECURITY_INFORMATION, GROUP_SECURITY_INFORMATION, DACL_SECURITY_INFORMATION, SACL_SECURITY_INFORMATION e nenhum tipo de informação). Uma solicitação de cada tipo também é enviada com um ponteiro de buffer inválido e um comprimento de buffer igual a zero. Se utilizar o parâmetro ChangeBufferProtectionFlags, que define a opção de proteção, o teste Fuzz varia a configuração de segurança no buffer em cada chamada de consulta e de definição. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoQueryAndSetSecurityTest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DoPoolCheck DQ CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
Teste Fuzz Random FSCTL / Teste Fuzz Random IOCTL |
Este teste emite uma série de chamadas para a função DeviceIoControl com códigos de função, tipos de dispositivos, métodos de transferência de dados e requisitos de acesso que são selecionados aleatoriamente a partir de um intervalo especificado de valores. As chamadas incluem buffers de entrada e saída com ponteiros e comprimentos de buffer válidos e inválidos e conteúdo gerado aleatoriamente. Durante testes aleatórios, o teste Fuzz emite uma série de chamadas para a função DeviceIoControl com códigos de função, tipos de dispositivos, métodos de transferência de dados e requisitos de acesso que são selecionados aleatoriamente a partir de um intervalo especificado de valores. As chamadas incluem buffers de entrada e saída com ponteiros e comprimentos de buffer válidos e inválidos e conteúdo gerado aleatoriamente. O teste Fuzz executa os testes aleatórios em todos os dispositivos abertos durante o Basic Open Operations e testes abertos adicionais. Você pode personalizar esse teste usando os seguintes parâmetros:
A função que o teste Fuzz usa para gerar números aleatórios para o teste usa um número de semente , um número inicial para o algoritmo de geração de números aleatórios. Para reproduzir as condições de teste, use o parâmetro número de sementes para especificar o número de sementes que foi usado no ensaio de teste original. Um de teste personalizado aleatório é incluído como parte do teste aleatório. O teste aleatório personalizado usa os resultados do teste aleatório para examinar a resposta dos motoristas às solicitações IOCTL ou FSCTL com mais detalhes. O teste aleatório personalizado investiga áreas que o teste aleatório não cobriu e aquelas em que o controlador não respondeu como esperado, com base no estado retornado pelas chamadas de teste aleatórias. Binário de teste: Devfund_DevicePathExerciser.dll Métodos de teste: DoRandomIOCTLTest, DoRandomFSCTLTest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo MinInBuffer MaxInBuffer MinOutBuffer MaxOutBuffer MaxRandomCalls MaxTailoredCalls SeedNumber MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck DQ CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
Teste Fuzz Sub-abre |
O teste executa uma série rápida de chamadas para abrir objetos no namespace do dispositivo. Nessas chamadas, ele passa por um caminho que começa com o dispositivo e inclui nomes arbitrários e cadeias de caracteres absurdas de comprimento e conteúdo variados. Durante um Teste Aberto Relativo , (também conhecido como Teste Subaberto ), o teste fuzz tenta abrir objetos no namespace do dispositivo. Durante esse teste, o teste Fuzz executa uma série rápida de chamadas para abrir objetos no namespace dos dispositivos abertos usando Basic Open Operations e outras operações abertas. Nessas chamadas, o teste Fuzz passa por um caminho que começa com o dispositivo e inclui nomes arbitrários e cadeias de caracteres absurdas de comprimento e conteúdo variáveis. Este teste determina como o driver ou sistema de arquivos gerencia solicitações abertas em seu namespace. Em particular, se o driver não oferecer suporte a solicitações abertas em seu namespace, ele deve impedir o acesso não autorizado, seja falhando nas solicitações ou definindo a característica FILE_DEVICE_SECURE_OPEN dispositivo quando usa IoCreateDevice ou IoCreateDeviceSecure para criar o objeto de dispositivo. Para obter mais informações sobre o namespace de um dispositivo, consulte Controlando o acesso ao namespace do dispositivo. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoSubOpensTest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DoPoolCheck DQ CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
Fuzz Sub-inicia com o teste de Streams |
Este teste tenta abrir uma variedade de fluxos de dados nomeados no dispositivo. O teste usa uma série de nomes de fluxo arbitrários com conteúdo e caracteres que podem ser válidos para outros usos em alguns dispositivos. Durante o Streams Test, o teste Fuzz tenta abrir uma variedade de streams de dados nomeados no dispositivo. Os testes usam uma série de nomes de fluxo arbitrários com conteúdo e caracteres que podem ser válidos para outros usos em alguns dispositivos. Este teste determina se o driver pode lidar corretamente com solicitações de fluxo de dados, especialmente se o driver exporta um dispositivo que não suporta ou antecipa fluxos de dados. Um fluxo de dados nomeado é um atributo de um objeto de ficheiro. Você especifica um fluxo de dados nomeado escrevendo o nome do arquivo, dois pontos e o nome do fluxo de dados, por exemplo, "File01.txt:AccessDate", onde AccessDate é um fluxo de dados nomeado, ou seja, um atributo do arquivo File01.txt. O teste Fuzz regista os nomes dos fluxos de dados usados no teste. Binário de teste: Devfund_DevicePathExerciser.dll Método de teste: DoSubOpensWithStreamsTest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DoPoolCheck DQ CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
Teste FSCTL de Zero-Length de Buffer Fuzz / Teste IOCTL de Buffer de Zero-Length Fuzz |
Este teste emite uma série de chamadas para a função DeviceIoControl com comprimentos de buffer de entrada e/ou saída de 0. O teste gera códigos de controle de sistema de arquivos variados usando diferentes códigos de função, tipos de dispositivos, métodos de transferência de dados e requisitos de acesso. Durante o teste de buffer Zero-Length, o teste Fuzz emite uma série de chamadas para a função DeviceIoControl , com comprimentos de buffer de entrada e/ou saída de 0. O teste gera códigos de controle de E/S variados usando diferentes códigos de função, tipos de dispositivos, métodos de transferência de dados e requisitos de acesso. Para obter informações sobre o conteúdo de códigos de controle de E/S, consulte Definindo códigos de controle de E/S. Para testar o tratamento de ponteiros de buffer inválidos pelo driver, os ponteiros de buffer nessas chamadas de modo utilizador especificam endereços elevados no espaço de endereçamento virtual do kernel, como 0xFFFFFC00). O teste Fuzz executa o teste Zero-Length Buffer em todos os dispositivos abertos durante os testes abertos básicos e adicionais. Você pode personalizar este teste usando os parâmetros de comando MinFunctionCode e MaxFunctionCode para especificar o intervalo dos códigos de função IOCTL ou FSCTL usados nas chamadas e MinDeviceType e MaxDeviceType para especificar o intervalo dos tipos de dispositivos usados nas chamadas. Binário de teste: Devfund_DevicePathExerciser.dll Métodos de teste: DoZeroLengthBufferIOCTLTest, DoZeroLengthBufferFSCTLTest Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck CiclosDeTeste AlterarFlagsDeProteçãoDoBuffer Personificar FillZeroPageWithNull |
Executar ataque de E/S |
Executa o Ataque de E/S no(s) dispositivo(s) especificado(s). Binário de teste: Devfund_IOAttack_DeleteDataFile.wsc Método de teste: RunIoAttack Parâmetros: - consulte Parâmetros de teste de fundamentos do dispositivo DQ |
Sobre o teste Fuzz de abrir e fechar
O teste de abertura e fechamento Fuzz emprega várias maneiras diferentes de abrir e fechar instâncias do dispositivo ou dos dispositivos especificados: Operações Básicas de Abertura , Operações Diretas de Abertura de Dispositivo , e um teste de Abertura e Fechamento .
Operações Abertas Básicas
Durante o Basic Open Operations, o teste Fuzz abre repetidamente (cria) instâncias dos dispositivos especificados ou dos dispositivos exportados pelo driver especificado usando métodos e opções diferentes.
O teste Fuzz sempre executa as Operações Abertas Básicas. Não é necessário selecioná-los e não é possível excluí-los de uma sessão de teste.
O teste Fuzz executa todas as operações abertas no modo de usuário chamando os serviços do sistema (Rotinas ZwXxx) que são apropriados para o dispositivo. Se uma chamada aberta retornar um identificador para o dispositivo, o teste Fuzz usará o identificador para executar os outros testes de dispositivo selecionados para a sessão de teste.
Existem cinco tipos de Operações Abertas Básicas:
Padrão aberto. o teste Fuzz abre o dispositivo de forma assíncrona e especifica apenas o nome do dispositivo nativo.
Abrir com o caractere de barra invertida adicionado. o teste Fuzz emite uma chamada aberta para o nome do dispositivo seguida por uma barra inversa (), como \device\cdrom\, como se fosse para abrir o diretório raiz do dispositivo.
Esta operação determina como o driver ou sistema de arquivos gerencia solicitações abertas em seu namespace. Em particular, se o dispositivo não suportar solicitações abertas em seu namespace, o driver deve impedir o acesso não autorizado, seja falhando as solicitações, ou definindo a característica FILE_DEVICE_SECURE_OPEN dispositivo quando ele chama IoCreateDevice ou IoCreateDeviceSecure para criar o objeto de dispositivo.
Abra como um pipe nomeado. Os testes Fuzz abrem o dispositivo e estabelecem um canal nomeado para o dispositivo. O parâmetro de acesso (ShareAccess) é inicialmente definido para leitura e gravação, mas é ajustado se a solicitação falhar. Se o dispositivo não suportar pipes nomeados, ele deve falhar em processar a solicitação.
Abrir como uma ranhura de correio. O teste Fuzz abre o dispositivo como um mailslot. Se o dispositivo não suportar este tipo de ligação, deverá falhar o pedido.
Abra como uma conexão de árvore. o teste Fuzz abre o dispositivo para uma ligação em árvore para uso no acesso remoto à rede. O parâmetro de acesso (ShareAccess) é inicialmente definido para leitura e gravação, mas é ajustado se a solicitação falhar. Se o dispositivo não suportar este tipo de ligação, deverá falhar o pedido.
Os parâmetros usados nas chamadas abertas variam para acomodar as características do dispositivo e tornar provável que as chamadas sejam bem-sucedidas. Por exemplo, se uma operação aberta básica falhar porque a chamada não atendeu aos requisitos de segurança do dispositivo, o teste Fuzz repetirá a operação aberta com uma solicitação de menor acesso. Por exemplo, se uma operação aberta que solicitou acesso de gravação retornar um erro de violação de segurança, a abertura será repetida com uma solicitação de acesso de leitura.
Operações diretas de abertura de dispositivos
Durante o Direct Device Open Operations, o teste Fuzz abre o dispositivo diretamente, como um dispositivo e não como um ficheiro no sistema de ficheiros. As operações diretas de abertura de dispositivo são sempre síncronas. Se a chamada for bem-sucedida, o teste Fuzz usará o identificador fornecido para executar outros testes selecionados.
Teste de Abertura e Fecho
Durante o teste Open and Close, o teste Fuzz cria vários threads, cada um dos quais executa milhares de sequências criar-abrir-fechar. Isso testa a capacidade do motorista de lidar com um volume extraordinário de chamadas simples e antecipadas.
O teste Abrir e Fechar usa as mesmas opções usadas nos testes Operações Abertas Básicas e Abrir com barra invertida adicionada e são executadas imediatamente antes desses testes.
Tópicos relacionados
Como testar um driver em tempo de execução usando o Visual Studio
Como selecionar e configurar os testes de fundamentos do dispositivo
Testes de Fundamentos de Dispositivos
Plug-ins simples de E/S do WDTF fornecidos
Como testar um driver em tempo de execução a partir de um prompt de comando