Penetration Tests (Device Fundamentals)

The Device Fundamentals Penetration tests perform various forms of input attacks, which are a critical component of security testing. Attack and Penetration testing can help identify vulnerabilities in software interfaces.

Penetration

The Penetration tests include two categories of tests: Fuzz tests and I/O Spy and I/O Attack tests. The Fuzz tests were also a feature of the Device Path Exceriser test tool.

Test	Description
Disable I/O Spy	Disable I/O Spy on 1 or more devices. Test binary: Devfund_IOSpy_DisableSupport.wsc Test method: DisableIoSpy Parameters: - see Device Fundamentals Test Parameters DQ
Display I/O Spy-enabled Device	Display devices that have I/O Spy enabled on them. Test binary: Devfund_IOSpy_DisplayEnabledDevices.wsc Test method: DisplayIoSpyDevices
Enable I/O Spy	Enable I/O Spy on one or more devices. Test binary: Devfund_IOSpy_EnableSupport.wsc Test method: EnableIoSpy Parameters: - see Device Fundamentals Test Parameters DQ DFD - specifies the path to the IoSpy data file. The default location is %SystemDrive%\DriverTest\IoSpy
Fuzz Misc API test	The Fuzz Misc API tests are tests that determine whether the driver can handle a variety of common calls from kernel mode drivers. The tests includes the following tests: Calls to ZwReadFile and ZwWriteFile, specifying valid data buffer pointers, varying lengths (including zero), and varying byte offsets, including zero, -1 and 64-bit bytes offsets. Calls to cancel I/0 and flush buffers. A series of directory query calls using common file information classes with valid user data buffer pointers and varying buffer lengths (including zero). Directory query calls similar to those issued by programs running under control of the Virtual DOS Machine (VDM). Calls to retrieve the extended attributes of a file with varying buffer sizes and lengths. Calls to create and close section objects, with varying section page protection and sectional allocation attributes (committed section, image file section). Calls to lock and unlock files. Calls to retrieve quota entries for a volume. File Attributes Test, a series of file attribute queries with valid pointers to an ObjectAttributes structure. The File Attributes Test has an optional zero-length test. While retrieving the extended attributes of a file, the Fuzz test passes a blank (zero-length) query and an invalid buffer address to the driver. Test binary: Devfund_DevicePathExerciser.dll Test method: DoMiscAPITest Parameters: - see Device Fundamentals Test Parameters DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Fuzz Misc API with zero-length query test	This test performs the same tests as Fuzz Misc API test and this time passes a blank (zero-length) query and an invalid buffer address to the driver while trying to retrieve the extended attributes of a file. Test binary: Devfund_DevicePathExerciser.dll Test method: DoMiscAPIWithZeroLengthTest Parameters: - see Device Fundamentals Test Parameters DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Fuzz open and close test	This test performs thousands of create-open-close sequences. For detailed information about this test, see About the Fuzz open and close test. Test binary: Devfund_DevicePathExerciser.dll Test method: DoOpenCloseTest Parameters: - see Device Fundamentals Test Parameters DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Fuzz Query and Set File Information test	This test issues calls to retrieve and change the object, file, and volume information of devices. During the Query and Set File Information Test, the Fuzz test issue calls to retrieve and change the object, file, and volume information of devices opened by the Basic Open Operations and other open operations, including the operations performed by the Fuzz Sub-opens test. The Fuzz test issues each query or set call at least 1024 times with a valid buffer and a variety of buffer lengths and file information classes. One request of each type is also sent with an invalid buffer pointer and a zero buffer length. If you use the ChangeBufferProtectionFlags parameter, which sets the protection option, the Fuzz test varies the security setting on the buffer in each query and set call. This test also performs the Fuzz Sub-opens test. This test uses the ZwQueryInformationFile, ZwSetInformationFile, ZwQueryVolumeInformationFile, and ZwSetVolumeInformationFile functions. Test binary: Devfund_DevicePathExerciser.dll Test method: DoQueryAndSetFileInformationTest Parameters: - see Device Fundamentals Test Parameters DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Fuzz Query and Set Security test	This test issues calls to retrieve the security descriptor and change the security state of devices. During the Query and Set Security Test, the Fuzz test issues calls to retrieve the security descriptor and change the security state of devices opened by the Basic Open Operations and other open operations, including the operations performed by the Fuzz Sub-opens test. the Fuzz test issues each query or set call at least 1024 times with a valid buffer and a variety of buffer lengths and security information types (OWNER_SECURITY_INFORMATION, GROUP_SECURITY_INFORMATION, DACL_SECURITY_INFORMATION, SACL_SECURITY_INFORMATION, and no information type). One request of each type is also sent with an invalid buffer pointer and a zero buffer length. If you use the ChangeBufferProtectionFlags parameter, which sets the protection option, the Fuzz test varies the security setting on the buffer in each query and set call. Test binary: Devfund_DevicePathExerciser.dll Test method: DoQueryAndSetSecurityTest Parameters: - see Device Fundamentals Test Parameters DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Fuzz Random FSCTL test / Fuzz Random IOCTL test	This test issues a series of calls to the DeviceIoControl function with function codes, device types, data transfer methods, and access requirements that are selected at random from a specified range of values. The calls include input and output buffers with valid and invalid buffer pointers and lengths, and randomly generated content. During random tests, the Fuzz test issues a series of calls to the DeviceIoControl function with function codes, device types, data transfer methods, and access requirements that are selected at random from a specified range of values. The calls include input and output buffers with valid and invalid buffer pointers and lengths, and randomly generated content. The Fuzz test performs the random tests on all devices opened during the Basic Open Test and additional open tests. You can customize this test by using the following parameters: Use MinFunctionCode and MaxFunctionCode to specify the range of IOCTL or FSCTL function codes used in the calls Use MinDeviceType and MaxDeviceType to specify the range of device types used in the calls Use SeedNumber to specify a seed number for the random number generating routine. The function that the Fuzz test uses to generate random numbers for the test uses a seed number, a starting number for the random-number-generating algorithm. To reproduce the test conditions, use the seed number parameter to specify the seed number that was used in the original test trial. A Tailored Random Test is included as part of the random test. The tailored random test uses the results of the random test to examine the drivers response to IOCTL or FSCTL requests in more detail. The tailored random test probes areas that the random test missed and those on which the driver did not respond as expected based on the status returned by the random test calls. Test binary: Devfund_DevicePathExerciser.dll Test methods: DoRandomIOCTLTest, DoRandomFSCTLTest Parameters: - see Device Fundamentals Test Parameters MinInBuffer MaxInBuffer MinOutBuffer MaxOutBuffer MaxRandomCalls MaxTailoredCalls SeedNumber MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Fuzz Sub-opens test	The test performs a rapid series of calls to open objects in the device's namespace. In these calls, it passes a path that begins with the device and includes arbitrary names and nonsense strings of varying length and content. During a Relative Open Test, (also known as a Sub-open Test) the Fuzz test attempts to open objects in the device's namespace. During this test, the Fuzz test performs a rapid series of calls to open objects in the namespace of the devices opened by using Basic Open Operations and other open operations. In these calls, the Fuzz test passes a path that begins with the device and includes arbitrary names and nonsense strings of varying length and content. This test determines how the driver or file system manages open requests in its namespace. In particular, if the driver does not support open requests in its namespace, it must prevent unauthorized access, either by failing the requests, or by setting the FILE_DEVICE_SECURE_OPEN device characteristic when it uses IoCreateDevice or IoCreateDeviceSecure to create the device object. For more information about the namespace of a device, see Controlling Device Namespace Access. Test binary: Devfund_DevicePathExerciser.dll Test method: DoSubOpensTest Parameters: - see Device Fundamentals Test Parameters DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Fuzz Sub-opens with Streams test	This test tries to open a variety of named data streams on the device. The test uses a series of arbitrary stream names with content and characters that might be valid for other uses on some devices. During the Streams Test, the Fuzz test tries to open a variety of named data streams on the device. The tests use a series of arbitrary stream names with content and characters that might be valid for other uses on some devices. This test determines whether the driver can properly handle data stream requests, especially if the driver exports a device that does not support or anticipate data streams. A named data stream is an attribute of a file object. You specify a named data stream by writing the name of the file, a colon, and the name of the data stream, for example, "File01.txt:AccessDate" where AccessDate is a named data stream, that is, an attribute of the File01.txt file. The Fuzz test records the stream names used in the test. Test binary: Devfund_DevicePathExerciser.dll Test method: DoSubOpensWithStreamsTest Parameters: - see Device Fundamentals Test Parameters DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Fuzz Zero-Length Buffer FSCTL test / Fuzz Zero-Length Buffer IOCTL test	This test issues a series of calls to the DeviceIoControl function with input and/or output buffer lengths of 0. The test generates varying file system control codes by using different function codes, device types, data transfer methods, and access requirements. During the Zero-Length Buffer Test, the Fuzz test issues a series of calls to the DeviceIoControl function with input and/or output buffer lengths of 0. The test generates varying I/O control codes by using different function codes, device types, data transfer methods, and access requirements. For information about the contents of I/O control codes, see Defining I/O Control Codes. To test the driver's handling of invalid buffer pointers, the buffer pointers in these user-mode calls specify addresses high in kernel virtual address space, such as 0xFFFFFC00). The Fuzz test performs the Zero-Length Buffer test on all devices opened during the basic and additional open tests. You can customize this test by using the MinFunctionCode and MaxFunctionCode command parameters to specify the range of IOCTL or FSCTL function codes used in the calls and MinDeviceType and MaxDeviceType to specify the range of device types used in the calls. Test binary: Devfund_DevicePathExerciser.dll Test methods: DoZeroLengthBufferIOCTLTest, DoZeroLengthBufferFSCTLTest Parameters: - see Device Fundamentals Test Parameters MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull
Run I/O Attack	Runs I/O Attack on the specified device or devices. Test binary: Devfund_IOAttack_DeleteDataFile.wsc Test method: RunIoAttack Parameters: - see Device Fundamentals Test Parameters DQ

About the Fuzz open and close test,

The Fuzz open and close test employs several different ways of opening and closing instances of the specified device or devices: Basic Open Operations, Direct Device Open Operations, and an Open and Close stress test.

Basic Open Operations

During the Basic Open Operations, the Fuzz test repeatedly opens (creates) instances of the specified devices or the devices exported by the specified driver by using different methods and options.

The Fuzz test always performs the Basic Open Operations. You do not need to select them and you cannot exclude them from a test session.

The Fuzz test performs all open operations in user mode by calling system services (ZwXxx Routines) that are appropriate to the device. If an open call returns a handle to the device, the Fuzz test uses the handle to perform the other device tests selected for the test session.

There are five types of Basic Open Operations:

Standard open. the Fuzz test opens the device asynchronously and specifies only the native device name.
Open with added backslash. the Fuzz test issues an open call for the device name followed by a backslash (\), such as \device\cdrom\, as though the call were to open a root directory within the device.
This operation determines how the driver or file system manages open requests in its namespace. In particular, if the device does not support open requests in its namespace, the driver must prevent unauthorized access, either by failing the requests, or by setting the FILE_DEVICE_SECURE_OPEN device characteristic when it calls IoCreateDevice or IoCreateDeviceSecure to create the device object.
Open as a named pipe. the Fuzz test opens the device and establishes a named pipe to the device. The access parameter (ShareAccess) is initially set to read and write, but is adjusted if the request fails. If the device does not support named pipes, it should fail the request.
Open as a mailslot. the Fuzz test opens the device as a mailslot. If the device does not support this type of connection, it should fail the request.
Open as a tree connection. the Fuzz test opens the device as a tree connection for use in remote network access. The access parameter (ShareAccess) is initially set to read and write, but is adjusted if the request fails. If the device does not support this type of connection, it should fail the request.

The parameters used in the open calls vary to accommodate the characteristics of the device and make it likely that the calls succeed. For example, if a basic open operation fails because the call did not meet the security requirements of the device, the Fuzz test repeats the open operation with a request for lesser access. For example, if an open operation that requested write access returns a security violation error, the open is repeated with a request for read access.

Direct Device Open Operations

During the Direct Device Open Operations, the Fuzz test opens the device directly, as a device, not as a file in a file system. Direct Device Open Operations are always synchronous. If the call is successful, the Fuzz test uses the handle provided to perform other selected tests.

Open and Close Test

During the Open and Close Test, the Fuzz test creates several threads, each of which performs thousands of create-open-close sequences. This tests the driver's ability to handle an extraordinary volume of otherwise simple and anticipated calls.