10.2 用 Immunity fuzzing 驱动 · 灰帽 Python 之旅

## 10.2 用 Immunity fuzzing 驱动我们需要使用 Immunity 强大的调试功能，挂钩住 DeviceIoControl 函数，在数据到达目标驱动之前，截获它们，这就是我们 Driver Fuzzing 的基础。如果一切顺利，最后可以将一些列工作写出自动化的 PyCommand，我们只要喝着茶看着 Immunity 完成一切工作：截获 DeviceIoControl，变形缓冲区数据，记录相关信息，将控制权交还给目标程序。之所以要对数据进行记录，是因为每次成功的 fuzzing 都会引起系统奔溃，而记录可以更好的还原崩溃时发送的数据。提示确保不要在自己的机器上进行实验。除非你想见到无数次的蓝屏，重启，最后就是硬盘报销的声音，哈哈！老天保佑，我们还可以使用虚拟机，虽然它的模拟在某些底层细节上不是很好，不过这可比硬盘便宜。开动代码。新建一个 Python 脚本 ioctl_fuzzer.py。 ``` #ioctl_fuzzer.py import struct import random from immlib import * class ioctl_hook( LogBpHook ): def init ( self ): self.imm = Debugger() self.logfile = "C:\ioctl_log.txt" LogBpHook. init ( self ) def run( self, regs ): """ We use the following offsets from the ESP register to trap the arguments to DeviceIoControl: ESP+4 -> hDevice ESP+8 -> IoControlCode ESP+C -> InBuffer ESP+10 -> InBufferSize ESP+14 -> OutBuffer ESP+18 -> OutBufferSize ESP+1C -> pBytesReturned ESP+20 -> pOverlapped """ in_buf = "" # read the IOCTL code ioctl_code = self.imm.readLong( regs['ESP'] + 8 ) # read out the InBufferSize inbuffer_size = self.imm.readLong( regs['ESP'] + 0x10 ) # now we find the buffer in memory to mutate inbuffer_ptr = self.imm.readLong( regs['ESP'] + 0xC ) # grab the original buffer in_buffer = self.imm.readMemory( inbuffer_ptr, inbuffer_size ) mutated_buffer = self.mutate( inbuffer_size ) # write the mutated buffer into memory self.imm.writeMemory( inbuffer_ptr, mutated_buffer ) # save the test case to file self.save_test_case( ioctl_code, inbuffer_size, in_buffer, mutated_buffer ) def mutate( self, inbuffer_size ): counter = 0 mutated_buffer = "" # We are simply going to mutate the buffer with random bytes while counter < inbuffer_size: mutated_buffer += struct.pack( "H", random.randint(0, 255) )[0] counter += 1 return mutated_buffer def save_test_case( self, ioctl_code,inbuffer_size, in_buffer, mutated_buffer ): message = "***** | |\n" message += "IOCTL Code: 0x%08x\n" % ioctl_code message += "Buffer Size: %d\n" % inbuffer_size message += "Original Buffer: %s\n" % in_buffer message += "Mutated Buffer: %s\n" % mutated_buffer.encode("HEX") message += "***** | |\n\n" fd = open( self.logfile, "a" ) fd.write( message ) fd.close() def main(args): imm = Debugger() deviceiocontrol = imm.getAddress( "kernel32.DeviceIoControl" ) ioctl_hooker = ioctl_hook() ioctl_hooker.add( "%08x" % deviceiocontrol, deviceiocontrol ) return "[*] IOCTL Fuzzer Ready for Action!" ``` 这里没有用到任何新的 Immunity 知识，只是继承了 LogBpHook 类，做了很小的扩展，这一切都在第五章做了详细的介绍。代码非常清晰明了，显示获得传递给驱动的 IOCT 代码，输入缓冲区长度，输入缓冲区位置。接着通过对输入数据的变形，创建一个包含了随即字符的新缓冲区，长度和输入缓冲区一样。之后将新缓冲区的数据写入原缓冲区，保存测试样例。最后把控制权交还给用户程序。记得把 ioctl_fuzzer.py 放到 PyCommands 目录下。这样我们就能使用 ioctl_fuzzer 命令 fuzz 任何使用 IOCTLs 了的程序（嗅探器，防火墙，或者杀毒软件）。表 10-1 是 Wireshark 的 fuzz 结果。 ``` ***** IOCTL Code: 0x00120003 Buffer Size: 36 Original Buffer: 0000000000000000000100000001000000000000000000000000000000000000 Mutated Buffer: a4100338ff334753457078100f78bde62cdc872747482a51375db5aa2255c46e ***** ***** IOCTL Code: 0x00001ef0 Buffer Size: 4 Original Buffer: 28010000 Mutated Buffer: ab12d7e6 ***** ``` Listing 10-1: Wireshark 的 fuzzing 输出在我们将一大堆的垃圾扔给驱动器之后，在于发现了两个可用的 IOCTL 代码 0x00001ef0 和 0x0012003 。如果要继续测试，就必须不断的和用户模式下的 Wireshark 进行交互，这样 Wireshark 就会调用不同 IOCTL 代码，最后祈祷上帝让其中一个 IOCTL 处理代码发生崩溃。虽然这样做很简单，也确实很够找出漏洞。不过还是不够聪明。举个例子，我们并不知道正在 fuzzing 的设备名，（不过可以通过 hook CreateFileW，然后观察被 DeviceIoControl 使用了的句柄，从而逆推得到设备名），而且 fuzz 的 IOCTL 代码并不全，我们在用户模式下对程序进行的操作是有限的，这样程序对驱动功能的调用也是有限的。这就像碰运气。我们期待的是一个更加聪明的 fuzzer，它能对所有的 IOCTL 不间断的 fuzzing，直到你的硬盘报销，或者在这之前发现一个漏洞。这可能吗，可能，先从我们伟大的 Immunity 携带的 driverlib 库开始。使用 driverlib 我们能枚举出驱动程序所有的设备名和 IOCTL 代码。把这些结合起来就能够实现一个高效，独立，全自动化的 fuzzer 了，这是一个伟大的进步，解放双手，不做野蛮人。Let’s get cracking。 ### 10.3.1 找出设备名用 Immunity 内建的 driverlib 库找出设备名很就当。让我们看看 driverlib 是怎么实现这个功能的。 ``` def getDeviceNames( self ): string_list = self.imm.getReferencedStrings( self.module.getCodebase() ) for entry in string_list: if "\\Device\\" in entry[2]: self.imm.log( "Possible match at address: 0x%08x" % entry[0], address = entry[0] ) self.deviceNames.append( entry[2].split("\"")[1] ) self.imm.log("Possible device names: %s" % self.deviceNames) return self.deviceNames ``` Listing 10-2: driverlib 库找出设备名的方法代码通过检索驱动中所有被引用了的字符串，找出其中包含了 "\Device\"的项。这项就可能是驱动程序注册了的符号链接，用来让用户模式下的程序调用的。我们就使用 C:\WINDOWS\System32\beep.sys 测试以下看看。以下操作都在 Immunity 中进行。 ``` *** Immunity Debugger Python Shell v0.1 *** Immlib instanciated as 'imm' PyObject READY. >>> import driverlib >>> driver = driverlib.Driver() >>> driver.getDeviceNames() ['\\Device\\Beep'] >>> ``` 我们很简单的使用三行代码就找到了一个可用的设备名 \\Device\\Beep,这省去了我们通过反汇编一行行查找代码的时间。Simple is Beautiful！下面看看 driverlib 是如何查找 IOCTL dispatch function（IOCTL 调度函数）和 IO IOCTL codes（ IOCTL 代码）的。任何驱动要实现 IOCTL 接口，都必须有一个 IOCTL dispatch 负责处理各种 IOCTL 请求。当驱动被加载的似乎后，第一个访问的函数就是 DriverEntry。DriverEntry 的主要框架如下： ``` NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) { UNICODE_STRING uDeviceName; UNICODE_STRING uDeviceSymlink; P DEVICE_OBJECT gDeviceObject; RtlInitUnicodeString( &uDeviceName, L"\\Device\\GrayHat" ); RtlInitUnicodeString( &uDeviceSymlink, L"\\DosDevices\\GrayHat" ) // Register the device IoCreateDevice( DriverObject, 0, &uDeviceName, FILE_DEVICE_NETWORK, 0, FALSE, &gDeviceObject ); // We access the driver through its symlink IoCreateSymbolicLink(&uDeviceSymlink, &uDeviceName); // Setup function pointers DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = IOCTLDispatch; DriverObject->DriverUnload = DriverUnloadCallbac DriverObject->MajorFunction[IRP_MJ_CREATE] = DriverCreateCloseCa DriverObject->MajorFunction[IRP_MJ_CLOSE] = DriverCreateCloseCa return STATUS_SUCCESS; } ``` Listing 10-3: DriverEntry 的 C 源码实现这是一个非常基础的 DriverEntry 代码框架，但是很直观的说明了设备是如何初始化的。要注意的是这行: ``` DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = IOCTLDispatch ``` 这行告示驱动器 IOCTLDispatch 负责所有 IOCTL 请求。当一个驱动器编译完成后，这行程序的汇编伪代码如下： ``` mov dword ptr [REG+70h], CONSTANT ``` 这指令集看起来有些特殊，REG 和 CONSTANT 都是汇编代码，IOCTLDispatch 指针将被存储在 (REG) 位移 0x70 的地方上。使用这些指令，我们就能找出 IOCTL 处理代码 CONSTANT，也就是 IOCTLDispatch，接着顺藤摸瓜找出 IOCTL 代码。driverlib 的具体实现如下： ``` def getIOCTLDispatch( self ): search_pattern = "MOV DWORD PTR [R32+70],CONST" dispatch_address = self.imm.searchCommandsOnModule( self.module .getCodebase(), search_pattern ) # We have to weed out some possible bad matches for address in dispatch_address: instruction = self.imm.disasm( address[0] ) if "MOV DWORD PTR" in instruction.getResult(): if "+70" in instruction.getResult(): self.IOCTLDispatchFunctionAddress = instruction.getImmConst() self.IOCTLDispatchFunction = self.imm.getFunction( self.IOCTLDispatchFunctio break # return a Function object if successful return self.IOCTLDispatchFunction ``` Listing 10-4: 找出 IOCTL dispatch function 的方法最新的 Immunity 中还有另一种列举函数搜索的方法，不过原理都一样。一旦我们找到了合适的函数，就将这个函数对象返回，在后面 IOCTL 代码查找中将会用它。下面来看看 IOCTL dispatch 的函数是如何实现的，以及如何查找出所有的 IOCTL 代码。 ### 10.3.3 找出 IOCTL 代码 IOCTL dispatch 根据传入的值(也就是 IOCTL 代码)执行相应的操作。这也是我们千方百计要找出所有 IOCTL 的原因，因为 IOCTL 就相当于用户模式下你调用的"函数"。让我们先看一段用 C 实现的 IOCTL dispatch，之后我们反汇编它们，并从中找出 IOCTL 代码。 ``` NTSTATUS IOCTLDispatch( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp ) { ULONG FunctionCode; PIO_STACK_LOCATION IrpSp; // Setup code to get the request initialized IrpSp = IoGetCurrentIrpStackLocation(Irp); FunctionCode = IrpSp->Parameters.DeviceIoControl.IoControlCode; // Once the IOCTL code has been determined, perform a // specific action switch(FunctionCode) { case 0x1337: // ... Perform action A case 0x1338: // ... Perform action B case 0x1339: // ... Perform action C } Irp->IoStatus.Status = STATUS_SUCCESS; IoCompleteRequest( Irp, IO_NO_INCREMENT ); return STATUS_SUCCESS; } ``` Listing 10-5: 一段简单的 IOCTL dispatch 代码支持三种 IOCTL 代码 (0x13370x1338, 0x1339) 当函数从 IOCTL 请求中检索到 IOCTL 代码的时候，就将代码传递个 switch{}语句，然后根据 IOCTL 代码执行相应的操作。switch 语句在汇编之后有可能是以下两种形式。 ``` // Series of CMP statements against a constant CMP DWORD PTR SS:[EBP-48], 1339 # Test for 0x1339 JE 0xSOMEADDRESS # Jump to 0x1339 action CMP DWORD PTR SS:[EBP-48], 1338 # Test for 0x1338 JE 0xSOMEADDRESS CMP DWORD PTR SS:[EBP-48], 1337 # Test for 0x1337 JE 0xSOMEADDRESS // Series of SUB instructions decrementing the IOCTL code MOV ESI, DWORD PTR DS:[ESI + C] # Store the IOCTL code in ESI SUB ESI, 1337 # Test for 0x1337 JE 0xSOMEADDRESS # Jump to 0x1337 action SUB ESI, 1 # Test for 0x1338 JE 0xSOMEADDRESS # Jump to 0x1338 action SUB ESI, 1 # Test for 0x1339 JE 0xSOMEADDRESS # Jump to 0x1339 action ``` Listing 10-6: 两种不同的 switch{}反汇编指令 switch{} 的反汇编指令有很多种，不过最常见的就是上面两种。在第一种情况下，我们可以通过一些列的 CMP 指令，找到进行比较的常量，这些就是 IOCTL 代码。第二种情况，稍微复杂点，它由一系列的 SUB 指令接条件跳转实现。关键的一行如下： ``` SUB ESI, 1337 ``` 这一行告诉了我们，最小的 IOCTL 代码就是 0x1337。从这里开始，0x1337 作为第一个常量，每行 SUB 指令减去多少，我能就加上多少，每次加出来的新的值作为一个新的 IOCTL 代码。不断累加，直到 switch 结束。具体实现可以看 Immunity 目录下的 Libs\driverlib.py。代码自动化的找出了 IOCTL dispatch 和所有的 IOCTL codes。现在 driverlib 为我们完成了最脏最累的活。接下来让我们做些高雅的事！用 driverlib 捕捉驱动程序中所有的设备名和 IOCTL 代码，并且将结果保存到 Python pickle 中。接着用它们构建 IOCTL fuzzer。Let’s get fuzzy！