Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Las pruebas de penetración de fundamentos del dispositivo realizan varias formas de ataques de entrada, que son un componente crítico de las pruebas de seguridad. Las pruebas de ataque y penetración pueden ayudar a identificar vulnerabilidades en las interfaces de software.
Penetración
Las pruebas de penetración incluyen dos categorías de pruebas: Pruebas Fuzz y pruebas Espía E/S y Ataque E/S. Las pruebas Fuzz también eran una característica de la herramienta de pruebas Device Path Exceriser.
| Prueba | Descripción |
|---|---|
Deshabilitar monitor de E/S |
Desactiva Espía E/S en 1 o más dispositivos. Binario de prueba: Devfund_IOSpy_DisableSupport.wsc Método de prueba : DisableIoSpy Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DQ |
Mostrar dispositivo habilitado para Espía E/S |
Muestra los dispositivos que tienen Espía E/S habilitada. Binario de prueba: Devfund_IOSpy_DisplayEnabledDevices.wsc Método de prueba: DisplayIoSpyDevices |
Habilitar Espía E/S |
Habilita Espía E/S en uno o más dispositivos. Binario de prueba: Devfund_IOSpy_EnableSupport.wsc Método de prueba : EnableIoSpy Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DQ DFD: especifica la ruta de acceso al archivo de datos de IoSpy. La ubicación predeterminada es %SystemDrive%\DriverTest\IoSpy |
Prueba Fuzz Misc API |
Las pruebas de Fuzz Misc API son pruebas que determinan si el controlador puede controlar una variedad de llamadas comunes desde controladores de modo kernel. Las pruebas incluyen las siguientes pruebas:
Binario de prueba: Devfund_DevicePathExerciser.dll Método de prueba : DoMiscAPITest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Fuzz Misc API con prueba de consulta de longitud cero |
Esta prueba realiza las mismas pruebas que la prueba de Fuzz Misc API y esta vez pasa una consulta en blanco (longitud cero) y una dirección de búfer no válida al controlador al intentar recuperar los atributos extendidos de un archivo. Binario de prueba: Devfund_DevicePathExerciser.dll Método de prueba: DoMiscAPIWithZeroLengthTest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Prueba de apertura y cierre de Fuzz |
Esta prueba realiza miles de secuencias de crear-abrir-cerrar. Para obtener información detallada sobre esta prueba, consulte Acerca de la prueba de apertura y cierre Fuzz. Binario de prueba: Devfund_DevicePathExerciser.dll Método de prueba : DoOpenCloseTest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Prueba de consulta y configuración de información de archivos |
Esta prueba emite llamadas para recuperar y cambiar la información de objeto, archivo y volumen de los dispositivos. Durante la prueba Query and Set File Information, la prueba Fuzz emite llamadas para recuperar y cambiar la información de objeto, archivo y volumen de los dispositivos abiertos por las Basic Open Operations y otras operaciones de apertura, incluidas las operaciones realizadas por la prueba Fuzz Sub-opens. La prueba Fuzz emite cada consulta o llamada de conjunto al menos 1024 veces con un búfer válido y una variedad de longitudes de búfer y clases de información de archivo. También se envía una petición de cada tipo con un puntero de búfer no válido y una longitud de búfer cero. Si usa el parámetro ChangeBufferProtectionFlags, que establece la opción de protección, la prueba Fuzz varía la configuración de seguridad del búfer en cada consulta y llamada de ajuste. Esta prueba también realiza la prueba Fuzz Sub-opens. Esta prueba usa las funciones ZwQueryInformationFile, ZwSetInformationFile, ZwQueryVolumeInformationFile, y ZwSetVolumeInformationFile. Binario de prueba: Devfund_DevicePathExerciser.dll Método de prueba : DoQueryAndSetFileInformationTest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Prueba Fuzz Query y Set Security |
Esta prueba emite llamadas para recuperar el descriptor de seguridad y cambiar el estado de seguridad de los dispositivos. Durante la prueba Query and Set Security, la prueba Fuzz emite llamadas para recuperar el descriptor de seguridad y cambiar el estado de seguridad de los dispositivos abiertos por las Basic Open Operations y otras operaciones de apertura, incluidas las operaciones realizadas por la prueba Fuzz Sub-opens. la prueba Fuzz emite cada consulta o llamada a set al menos 1024 veces con un búfer válido y una variedad de longitudes de búfer y tipos de información de seguridad (OWNER_SECURITY_INFORMATION, GROUP_SECURITY_INFORMATION, DACL_SECURITY_INFORMATION, SACL_SECURITY_INFORMATION y ningún tipo de información). También se envía una petición de cada tipo con un puntero de búfer no válido y una longitud de búfer cero. Si se utiliza el parámetro ChangeBufferProtectionFlags, que establece la opción de protección, la prueba Fuzz varía la configuración de seguridad en el buffer en cada llamada query y set. Binario de prueba: Devfund_DevicePathExerciser.dll Método de prueba: DoQueryAndSetSecurityTest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Prueba Fuzz Random FSCTL / Prueba Fuzz Random IOCTL |
Esta prueba emite una serie de llamadas a la función DeviceIoControl con códigos de función, tipos de dispositivo, métodos de transferencia de datos y requisitos de acceso seleccionados aleatoriamente a partir de un intervalo de valores especificado. Las llamadas incluyen búferes de entrada y salida con punteros y longitudes de búfer válidos y no válidos, y contenido generado aleatoriamente. Durante las pruebas aleatorias, la prueba Fuzz emite una serie de llamadas a la función DeviceIoControl con códigos de función, tipos de dispositivo, métodos de transferencia de datos y requisitos de acceso seleccionados de forma aleatoria a partir de un intervalo de valores especificado. Las llamadas incluyen búferes de entrada y salida con punteros y longitudes de búfer válidos y no válidos, y contenido generado aleatoriamente. La prueba Fuzz realiza las pruebas aleatorias en todos los dispositivos abiertos durante las Operaciones de apertura básicas y las pruebas de apertura adicionales. Puede personalizar esta prueba mediante los parámetros siguientes:
La función que usa la prueba Fuzz para generar números aleatorios para la prueba usa un número de inicialización de , un número inicial para el algoritmo de generación de números aleatorios. Para reproducir las condiciones de prueba, use el parámetro número de semilla para especificar el número de semilla que se usó en la prueba original. Se incluye una Prueba aleatoria a medida como parte de la prueba aleatoria. La prueba aleatoria adaptada utiliza los resultados de la prueba aleatoria para examinar con más detalle la respuesta de los controladores a las solicitudes IOCTL o FSCTL. La prueba aleatoria adaptada sondea las áreas que la prueba aleatoria no detectó y aquellas en las que el controlador no respondió como se esperaba según el estado devuelto por las llamadas de la prueba aleatoria. Binario de prueba: Devfund_DevicePathExerciser.dll Métodos de prueba: DoRandomIOCTLTest, DoRandomFSCTLTest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo MinInBuffer MaxInBuffer MinOutBuffer MaxOutBuffer MaxRandomCalls MaxTailoredCalls SeedNumber MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Fuzz Sub-opens test |
La prueba realiza una serie rápida de llamadas para abrir objetos en el espacio de nombres del dispositivo. En estas llamadas, pasa una ruta que comienza con el dispositivo e incluye nombres arbitrarios y cadenas sin sentido de longitud y contenido variables. Durante una Prueba de apertura relativa, (también conocida como Prueba de subapertura) la prueba Fuzz intenta abrir objetos en el espacio de nombres del dispositivo. Durante esta prueba, la prueba Fuzz realiza una serie rápida de llamadas para abrir objetos en el espacio de nombres de los dispositivos abiertos mediante Basic Open Operations y otras operaciones abiertas. En estas llamadas, la prueba Fuzz pasa una ruta que comienza con el dispositivo e incluye nombres arbitrarios y cadenas sin sentido de longitud y contenido variables. Esta prueba determina cómo el controlador o el sistema de archivos administra las solicitudes abiertas en su espacio de nombres. En concreto, si el controlador no admite solicitudes abiertas en su espacio de nombres, debe evitar el acceso no autorizado, ya sea con errores en las solicitudes o estableciendo la característica de dispositivo FILE_DEVICE_SECURE_OPEN cuando usa IoCreateDevice o IoCreateDeviceSecure para crear el objeto de dispositivo. Para obtener más información sobre el espacio de nombres de un dispositivo, consulte Control de acceso al espacio de nombres de dispositivos. Binario de prueba: Devfund_DevicePathExerciser.dll Método de prueba : DoSubOpensTest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Fuzz Sub-opens con la prueba Streams |
Esta prueba intenta abrir una variedad de flujos de datos con nombre en el dispositivo. La prueba usa una serie de nombres de flujo arbitrarios con contenido y caracteres que podrían ser válidos para otros usos en algunos dispositivos. Durante la prueba Streams, la prueba Fuzz intenta abrir una variedad de flujos de datos con nombre en el dispositivo. Las pruebas usan una serie de nombres de secuencia arbitrarios con contenido y caracteres que podrían ser válidos para otros usos en algunos dispositivos. Esta prueba determina si el controlador puede controlar correctamente las solicitudes de flujo de datos, especialmente si el controlador exporta un dispositivo que no admite ni prevé flujos de datos. Un flujo de datos denominado es un atributo de un objeto de archivo. Para especificar un flujo de datos con nombre, escriba el nombre del archivo, dos puntos y el nombre del flujo de datos, por ejemplo, "File01.txt:AccessDate", donde AccessDate es un flujo de datos con nombre, es decir, un atributo del archivo File01.txt. La prueba Fuzz registra los nombres de los flujos utilizados en la prueba. Binario de prueba: Devfund_DevicePathExerciser.dll Método de prueba: DoSubOpensWithStreamsTest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Prueba Fuzz Zero-Length Buffer FSCTL / Prueba Fuzz Zero-Length Buffer IOCTL |
Esta prueba emite una serie de llamadas a la función DeviceIoControl con longitudes de búfer de entrada y/o salida de 0. La prueba genera distintos códigos de control del sistema de archivos mediante diferentes códigos de función, tipos de dispositivo, métodos de transferencia de datos y requisitos de acceso. Durante la prueba de búfer de longitud cero, la prueba Fuzz emite una serie de llamadas a la función DeviceIoControl con longitudes de búfer de entrada y/o salida de 0. La prueba genera distintos códigos de control de E/S mediante diferentes códigos de función, tipos de dispositivo, métodos de transferencia de datos y requisitos de acceso. Para obtener información sobre el contenido de los códigos de control de E/S, vea Definir códigos de control de E/S. Para probar el manejo del controlador de punteros de búfer no válidos, los punteros de búfer en estas llamadas de modo de usuario especifican direcciones altas en el espacio de direcciones virtual del kernel, como 0xFFFFFC00). La prueba Fuzz realiza la prueba de búfer de longitud cero en todos los dispositivos abiertos durante las pruebas de apertura básica y adicional. Puede personalizar esta prueba mediante los parámetros de comando MinFunctionCode y MaxFunctionCode para especificar el intervalo de códigos de función IOCTL o FSCTL usados en las llamadas y MinDeviceType y MaxDeviceType para especificar el intervalo de tipos de dispositivo usados en las llamadas. Binario de prueba: Devfund_DevicePathExerciser.dll Métodos de prueba: DoZeroLengthBufferIOCTLTest, DoZeroLengthBufferFSCTLTest Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Ejecutar Ataque E/S |
Ejecuta Ataque de E/S en el dispositivo o dispositivos especificados. Binario de prueba: Devfund_IOAttack_DeleteDataFile.wsc Método de prueba: RunIoAttack Parámetros: - véase Parámetros de prueba de los fundamentos del dispositivo DQ |
Acerca de la prueba de apertura y cierre de Fuzz
La prueba de apertura y cierre de Fuzz emplea varias formas diferentes de abrir y cerrar instancias del dispositivo o dispositivos especificados: Operaciones básicas de apertura, Operaciones directas de apertura de dispositivos, y una prueba de apertura y cierre.
Operaciones abiertas básicas
Durante la Basic Open Operations, la prueba de Fuzz abre repetidamente (crea) instancias de los dispositivos especificados o los dispositivos exportados por el controlador especificado mediante diferentes métodos y opciones.
La prueba Fuzz siempre realiza las operaciones abiertas básicas. No es necesario seleccionarlos y no puede excluirlos de una sesión de prueba.
La prueba Fuzz realiza todas las operaciones abiertas en modo de usuario llamando a los servicios del sistema (rutinas ZwXxx) que son adecuadas para el dispositivo. Si una llamada abierta devuelve un identificador al dispositivo, la prueba Fuzz usa el identificador para realizar las otras pruebas de dispositivo seleccionadas para la sesión de prueba.
Hay cinco tipos de operaciones abiertas básicas:
Apertura estándar. La prueba de Fuzz abre el dispositivo de forma asincrónica y especifica solo el nombre del dispositivo nativo.
Abrir con barra invertida añadida. la prueba Fuzz emite una llamada de apertura para el nombre del dispositivo seguido de una barra invertida (), como \device\cdrom\, como si la llamada fuera para abrir un directorio raíz dentro del dispositivo.
Esta operación determina cómo el controlador o el sistema de archivos administra las solicitudes abiertas en su espacio de nombres. En concreto, si el dispositivo no admite solicitudes abiertas en su espacio de nombres, el controlador debe evitar el acceso no autorizado, ya sea mediante un error en las solicitudes o estableciendo la característica del dispositivo FILE_DEVICE_SECURE_OPEN cuando llama a IoCreateDevice o IoCreateDeviceSecure para crear el objeto de dispositivo.
Abrir como una pipeline con nombre. la prueba Fuzz abre el dispositivo y establece una pipeline con nombre al dispositivo. El parámetro de acceso (ShareAccess) se establece inicialmente para leer y escribir, pero se ajusta si se produce un error en la solicitud. Si el dispositivo no admite pipelines con nombre, debe fallar la solicitud.
Abrir como una ranura de correo. La prueba Fuzz abre el dispositivo como un mailslot. Si el dispositivo no admite este tipo de conexión, debe producir un error en la solicitud.
Abrir como una conexión de árbol. la prueba Fuzz abre el dispositivo como una conexión en árbol para su uso en el acceso remoto a la red. El parámetro de acceso (ShareAccess) se establece inicialmente para leer y escribir, pero se ajusta si se produce un error en la solicitud. Si el dispositivo no admite este tipo de conexión, debe producir un error en la solicitud.
Los parámetros usados en las llamadas abiertas varían para adaptarse a las características del dispositivo y hacer que las llamadas se realicen correctamente. Por ejemplo, si se produce un error en una operación de apertura básica porque la llamada no cumple los requisitos de seguridad del dispositivo, la prueba Fuzz repite la operación abierta con una solicitud de acceso menor. Por ejemplo, si una operación de apertura que solicitó acceso de escritura devuelve un error de violación de seguridad, la apertura se repite con una solicitud de acceso de lectura.
Operaciones de apertura directa de dispositivos
Durante las Operaciones de apertura directa de dispositivos, la prueba Fuzz abre el dispositivo directamente, como un dispositivo, no como un archivo en un sistema de archivos. Las Operaciones de Apertura Directa de Dispositivo son siempre síncronas. Si la llamada se realiza correctamente, la prueba Fuzz usa el identificador proporcionado para realizar otras pruebas seleccionadas.
Abrir y cerrar prueba
Durante la Prueba de apertura y cierre, la prueba Fuzz crea varios subprocesos, cada uno de los cuales realiza miles de secuencias de creación, apertura y cierre. Esto pone a prueba la capacidad del conductor para gestionar un volumen extraordinario de llamadas, que de otro modo serían sencillas y anticipadas.
La prueba de apertura y cierre utiliza las mismas opciones que las pruebas Operaciones de apertura básicas y Apertura con barra invertida añadida, y se realiza justo antes de estas pruebas.
Temas relacionados
Cómo probar un controlador en tiempo de ejecución mediante Visual Studio
Cómo seleccionar y configurar las pruebas de Fundamentos del Dispositivo
Pruebas de aspectos básicos del dispositivo
Complementos WDTF Simple E/S proporcionados
Cómo probar un controlador en tiempo de ejecución desde un símbolo del sistema