[[344521]]
最近，我开始使用基于Facedancer的一种工具来挖掘USB主机堆栈中的漏洞。本文首先介绍我的Fuzzing测试方法，然后给出完整更新的Windows 8.1 x64中的漏洞的实际示例。本文的目的不是重新定义USB Fuzzing测试，也不是对我的Fuzzing测试架构进行完整描述，而是要叙述从Fuzzing测试到漏洞报告的完整步骤。
0x01 Fuzzing 方法
我的Fuzzing结构基于Facedancer和Umap工具，并向其中添加了一些功能：
- · 在PCAP中为仿真设备捕获流量；
- · 从已记录的PCAP重放流量；
- · 基于Radamsa的数据包变异。
0x02 USB基础
本文的目的不是要详细描述USB的工作原理，但仍需要一些知识才能更好地理解USB Fuzzing。连接设备后，主机会向该设备发出标准请求，以检索有关该设备的信息（供应商ID，产品ID，可用功能等），这样做是为了对其进行配置并将适当的驱动程序加载到OS中，此信息称为 描述符。这些请求/描述符在特殊端点上交换：每个连接的新标准设备都必须响应发送给它的请求。端点是设备接口之间的逻辑链接和USB主机堆栈，接口由一个或多个端点组成，并提供类功能（HID，大容量存储等）或特定功能。
0x03 Fuzzing的实例示例
我模拟了USB大容量存储设备，并丢弃了交换的流量，然后，我决定Fuzzing配置描述符，尤其是bNumEndpoints字段。
变异只是将这个字节替换为一个随机字节。一段时间后，我在Windows 8.1 x64上触发了BSOD。在这里，我的变异描述符以红色框的形式发送到主机。在使用变异描述符对数据包序列重放了几次之后，我推测主机在以橙色框发送设置配置请求后立即触发了BSOD 。
在Wireshark中，变异的描述符如下所示：
崩溃转储分析几乎没有用，因为内核池内存已被损坏：每次崩溃都在另一个位置。我继续注入数据包，并且在某个时候Windows BSOD给了我以下问题的位置：USBSTOR.sys。
驱动程序名称是显式的：它是大容量存储驱动程序。
0x04 逆向大容量存储驱动程序
下载完USBSTOR.sys的符号后，我将其加载到IDA Pro中，幸运的是，这些符号很容易理解，我很快找到了有趣的函数： USBSTOR_SelectConfiguration（）
第一个基本块显示了对usbd.sys导出的调用： USBD_CreateConfigurationRequestEx（），该输出返回指向URB_FUNCTION_SELECT_CONFIGURATION结构的指针 。根据MSDN [6]，此“例程分配并格式化URB以选择USB设备的配置”。URB是客户端驱动程序用来描述其要发送到设备的请求的结构[7]。
第二个基本块调用USBSTOR_SyncSendUsbRequest（），并将先前创建的URB作为第一个参数。调用此函数后，请求将通过USB堆栈发送，然后从主机控制器物理发送到设备。如果我中断USBSTOR_SyncSendUsbRequest（）调用，则会观察到不是此调用导致系统崩溃。
USBD_CreateConfigurationRequestEx（）函数中，我看到它复制 bNumEndpoints（我设置为0的Fuzzing 空间）从USB_INTERFACE_DESCRIPTOR结构的 NumberOfPipes基于USBD_INTERFACE_INFORMATION结构。该USB_INTERFACE_DESCRIPTOR枚举过程结构初始化，并且不会在本文中进行研究。
现在，在调用USBD_CreateConfigurationRequestEx（）之后，我回到USBSTOR.sys ，RDI指向：
- struct _URB_SELECT_CONFIGURATION {
- struct URB_HEADER Hdr;
- PUSB_CONFIGURATION_DESCRIPTOR ConfigurationDescriptor;
- USBD_CONFIGURATION_HANDLE ConfigurationHandle;
- USBD_INTERFACE_INFORMATION Interface;
- };
R14指向：
- USHORT Length;
- UCHAR InterfaceNumber;
- UCHAR AlternateSetting;
- UCHAR Class;
- UCHAR SubClass;
- UCHAR Protocol;
- UCHAR Reserved;
- USBD_INTERFACE_HANDLE InterfaceHandle;
- ULONG NumberOfPipes; // Our bNumEndpoints = 0 is here !
- USBD_PIPE_INFORMATION Pipes[1];
- } USBD_INTERFACE_INFORMATION, *PUSBD_INTERFACE_INFORMATION;[object Object]
现在，将_USBD_INTERFACE_INFORMATION结构复制到RCX，我将此指针放回RAX中。
这些指令的伪代码为：
- ECX <- endpoint number If the number of endpoint is zero
- ECX <- ECX-1 ECX <- 0-1 = 0xffffffff
- R8 (0xffffffff*3*8)+80
- memset(@dest, 0x0, R8) memset(@dest, 0x0, 0x1800000038)
在这里，有一个memset，其大小等于0x1800000038，导致不可利用的内核池溢出。
Windows 8.1 32位
我看到了在64位模式下发生的情况，但没有看到32位模式下发生的情况。我将不再详细说明指令流，因为是完全相同的。
以下代码段对应于先前代码段的32位等效：
在伪代码中，memset（）的大小如下：
- EAX <- endpoint number If the number of endpoint is zero
- EAX <- EAX-1 EAX <- 0-1 = 0xffffffff
- EAX (0xffffffff*0x14)+0x38 = 0x24
- memset(@dest, 0x0, EAX) memset(@dest, 0x0, 0x24)
此处，由于结构中的指针大小不同，因此大小计算也不同。因为EAX只有32位长，所以结果0x1400000024不适合它，因此存储了0x00000024。_URB_SELECT_CONFIGURATION的大小为0x38字节，因此未初始化分配结构的20个字节，如果分配的空间紧随其后没有正确地用memcpy（）填充，则在特定条件下可以利用该漏洞。
0x05 参考文献
- [1] http://goodfet.sourceforge.net/hardware/facedancer21/
- [2] https://github.com/nccgroup/umap
- [3] https://code.google.com/p/ouspg/wiki/Radamsa
- [4] Universal Serial Bus Specification 2.0 page 250
- [5] Universal Serial Bus Specification 2.0 page 260
- [6] http://msdn.microsoft.com/en-us/library/
- [7] http://msdn.microsoft.com/en-us/library/windows/hardware/ff538923%28v=vs.85%29.aspx
本文翻译自：https://blog.quarkslab.com/usb-fuzzing-basics-from-fuzzing-to-bug-reporting.html如若转载，请注明原文地址：
文章来源网络，作者：管理，如若转载，请注明出处：https://shuyeidc.com/wp/137962.html<
