利用大模型辅助自动化挖掘BYOVD漏洞驱动

利 用 大 模 型 辅 助 自 动 化 挖 掘B Y O V D漏 洞 驱 动 张 艺 璇-阿 里 云 安 全-安 全 研 究 员 团队介绍 张艺璇 程聪 王晓满 阿里云安全研究员专注于人工智能在二进制文件分析、漏洞挖掘以及恶意软件检测中的应用 阿里云安全专家深耕病毒检测、主机安全、内核安全、虚拟化安全、恶意文件攻防领域 阿里云安全攻防策略专家专注于高级恶意样本对抗 演讲内容 •BYOVD背景介绍•使用大模型辅助自动化BYOVD驱动漏洞挖掘 •思路和流程•风险驱动筛选•自动分析工具搭建•工作流与prompt •实例分析•总结与展望 背景介绍 BYOVD BYOVD（BringYourOwnVulnerableDriver）攻击者将易受攻击的合法驱动程序(.sys文件)植入目标系统，然 后利 用 易 受 攻 击 的 驱 动 程 序 执 行 恶 意 操 作。BYOVD攻击往往会直接针对终端安全软件，使其被致盲或杀死，而终端安全防护被攻破后，入侵者将不受阻碍地开展任何恶意行动。 这些驱动是微软官方或第三方厂商开发的经过数字签名的驱动，驱动本身受安全软件信任，因此它们既不会被标记也不会被阻止。但由于代码实现中的缺陷，它们可以被恶意利用以执行提权、持久化驻留等操作。 BYOVD通常是通过驱动程序的IOCTL漏洞实现的。攻击者利用合法驱动中存在漏洞的IOCTL，在用户态发起IOCTL请求，通过内核驱动控制内核行为，达到提权、任意代码执行等目的。 BYOVD原理 CWE-782: Exposed IOCTL with Insufficient Access Control 用户自定义的IOCTL请求中，可能执行了某些高危操作 •MSR寄存器访问•I/O端口直接访问•内存映射•打开/关闭进程•…… 如果在执行这些操作前，没有进行权限校验或者校验方式能够被绕过，则可能导致这些操作被滥用。攻击者可以通过逆向分析，构造对应的IOCTL请求，借助白驱动执行危险操作，达到提权、任意代码执行等目的。 BYOVD危害与影响 由于驱动开发人员对安全编码规范不了解等原因，第三方驱动广 泛 存 在无 权 限 校 验/权 限 校 验 可 被 绕 过 等 问 题，这 使 得BYOVD成为潜在的安全隐患来源。 有报告指出，2024年约25%的勒索软件攻击已通过BYOVD技术利用合法但存在漏洞的驱动程序，绕过EDR并实现权限提升。 勒索团伙如RansomHub开发“EDRKillShifter”工具，通过加载漏洞驱动禁用主动防御。银狐及其他APT组织频繁采用BYOVD，在针对性攻击中进一步扩大威胁范围………… 原有BYOVD漏洞挖掘方法 人工逆向 •人工逐个分析每个Hunting文件，判断是否存在漏洞、编写PoC并验证•分析效率低且高度依赖专业知识 符号执行 •人工仅参与分析符号执行成功的文件，编写PoC并验证•由于路径爆炸、指针操作等问题，失败率很高 代码：符号执行举例 原有BYOVD漏洞挖掘方法 使用IDAPython脚本ida_ioctl_propagate.py自动搜索BYOVD驱动程序 •该脚本有两个功能：分类和分析•分类函数：识别IOCTL处理程序，然后查找从处理程序到目标API/指令的执行路径。•分析函数：修复IOCTL相关结构中的联合字段，并在子例程中递归传播函数参数名称/类型，以快速判断是否可以控制输入/输出。 该方案依赖完整符号或结构，如果没有完整的IOCTL分发表或IOCTL分发表被混淆，识别处理程序会变得困难；也不能处理多个IOCTL协同等复杂情况。 参考：https://blogs.vmware.com/security/2023/10/hunting-vulnerable-kernel-drivers.html 大模型能带来什么？ 分析效率提升大模型自动判断是否存在漏洞并实现PoC编写人工仅参与校验环节 分析成功率提升从代码语义方面分析文件，不要求严格的语法对专家经验依赖少 为什么选择BYOVD？ 可行性：BYOVD漏洞具备一定的统一性（结构化输入/输出） •IOCTL是一种结构化的接口。有明确的参数格式和调用方式•用户态通过DeviceIoControl调用内核驱动，传入一个InputBuffer和OutputBuffer。IOCTL的代码逻辑通常围绕这些缓冲区展开处理•攻击链具备一定的统一性。均需要分析从IOCTL处理程序到目标API/指令的执行路径。 现实意义：BYOVD攻击成本较低，容易被利用，缺乏针对BYOVD专门防护的终端安全产品极易受到攻击 思路和流程 为什么不直接让大模型分析二进制文件？ 数据：风险样本初筛 目的：从海量驱动程序中快速筛选出具备潜在安全风险且适合后续自动化分析的目标样本 1.选择带数字签名的64位驱动程序2.样本文件大小小于1MB3.危险函数导入检测识别驱动是否调用了与系统底层操作密切相关的高危内核API •MSR寄存器访问：wrmsr、rdmsr•I/O端口直接访问：outbyte、inbyte•内存映射类：MmMapIoSpace、ZwMapViewOfSection•进程操作类：ZwOpenProcess、ZwTerminateProcess•……. 数据：风险样本聚类 目的：对同类样本，只选最新时间的驱动进入分析流程，减少大模型和人工分析量 聚类1：驱动能否被任意打开。如果不能被任意打开，大模型需要先检查open中的校验能否绕过 聚类2：驱动名相同。可能是同一驱动的不同版本，选最新时间的驱动进入分析流程。 聚类3：来自同公司。反编译后的代码模式可能相似，减少后续人工分析量 工具：基于LLM+IDA-Pro+MCP的LLM-Agent 工具：基于LLM+IDA-Pro+MCP的LLM-Agent 工作流 我们实践发现，直接让大模型一次性完成类似漏洞挖掘的复杂任务，效果不佳。 所以我们参考ida_ioctl_propagate研究的分析过程，把任务拆分成简单容易解决的子任务（类似思维链提示），教大模型一步一步的完成解决问题。 三个任务构成了从入口发现到漏洞验证的完整技术链条，整个分析过程由大模型自主驱动。 相比ida_ioctl_propagate的分析，本方法具备更强的语义分析、上下文感知与容错能力 任务：派遣函数识别 目标：从驱动初始化逻辑中定位用户态与内核交互的入口点：IRP派遣函数 背景知识 •派遣函数常通过DriverObject->MajorFunction[]数组注册•由于编译优化、函数指针间接赋值等技术的存在，传统基于字符串匹配或简单模式识别极易遗漏或误判 派遣函数注册 大模型的优势 •通过语义分析寻找派遣函数，不依赖严格的语法•不仅可识别常见的数组赋值，还能识别常见的变体模式•如通过循环批量注册、函数表跳转等，提升识别的覆盖率 示例：派遣函数识别 这是一个常见变体，通过多层函数指针来实现间接赋值。❌先前的方案无法识别到实际的派遣函数，因为其均依赖于严格的语法链条。✔大模型能够识别到实际的派遣函数，因为其从语义层面进行分析。 提示词：派遣函数识别 你是一个驱动漏洞分析专家，核心技能是使用IDA-MCP-Server工具对驱动二进制文件进行反汇编或者反编译，分析驱动文件。 你可以自行决定下一步行动，不要询问我下一步做什么。 示例输出[{"driver_name": "xxx","irp_mj_functions":["sub_xxx"]"can_be_arbitrarily_opened": true}] 参考知识：寻找符合IRP_MJ_xxx模式的函数时，可参考以下知识。在Windows驱动开发中，MajorFunction是一个非常重要的结构体成员，它定义在驱动对象（DRIVER_OBJECT）中，用于指向一组处理I/O请求的函数指针。每个MajorFunction[i]对应一个IRP_MajorCode，表示不同的I/O操作类型。以下是常见的IRP_MajorCode值及其对应的函数功能说明0x00 IRP_MJ_CREATE文件/设备打开；0x0e IRP_MJ_DEVICE_CONTROL设备控制。 你需要：1.找到驱动名，并输出驱动名字符串。2.找到其中符合IRP_MJ_xxx模式的函数，输出该函数名。3.判断该驱动是否能够被任意打开。 具体分析步骤如下：1.从DriverEntry函数开始分析。2.找到符合IRP_MJ_xxx模式的函数。重点关注IRP_MJ_CREATE和IRP_MJ_CONTROL。如果入口函数找不到这些模式的函数，可以逐个跟踪分析入口函数中的子函数，使用广度优先策略跟踪分析子函数，最大嵌套层数不大于3 3.分析函数前，先调用反编译工具decompile_function反编译成伪C代码再分析。#相比二进制和汇编语言，大模型能更好的理解高级语言代码 任务：派遣函数原型修复 DriverDispatch(PDEVICE_OBJECTDeviceObject,PIRPIrp) 派遣函数常被识别为下述通用形式，导致原始语义丢失，干扰了模型语义分析。 func(__int64a1,IRP*a2) 设计实现派遣函数原型修复工具，该工具集成于ida-mcp-server中。在大模型识别到派遣函数后进行调用，实现对派遣函数的语义恢复。 任务：派遣函数原型修复 •第一个参数a1为指向DEVICE_OBJECT的指针，表示目标设备对象=>将a1修改为PDEVICE_OBJECT类型•第二个参数a2为指向IRP的指针，封装了I/O请求包。由于IRP派遣函数类型多样，每种操作类型参数有不同的意义，因此其包含一个联合体，其中定义了各个操作类型的参数。我们只关注DeviceIoControl的结构。因此定义新的local_type，只保留联合体中与DeviceIoControl相关的数据结构，再将a2修改为该类型 示例：派遣函数原型修复 语义恢复 任务：派遣函数分析与POC生成 目标：从已识别并修复的派遣函数出发，判断是否存在通往高危函数的可达路径且用户输入可控。 分析步骤（思维链） •执行路径分析：若发现某条路径中用户输入可直接或间接控制危险操作的参数，且无有效访问控制检查，则判定该路径具备可利用性。•POC生成：大模型使用其代码生成能力，自动生成POC。生成的POC包含完整的用户态调用逻辑：创建设备句柄、准备输入缓冲区、设置特定IOCTL码，继而调用DeviceIoControl触发目标路径。并代码中标明可控字段与预期行为（如触发蓝屏或实现任意地址读写），便于研究人员快速验证漏洞真实性。 大模型的优势：自动化语义分析 相较于其他方案：能够发现复杂的控制链路；可以分析权限校验的有无及绕过方案 提示词：派遣函数分析与POC生成 你是一个驱动漏洞分析专家，核心技能是使用IDA-MCP-Server工具对驱动二进制文件进行反汇编或者反编译，分析驱动文件。 定义角色 你可以自行决定下一步行动，不要询问我下一步做什么。 你需要从派遣函数sub_113C0开始分析，判断是否存在通往高危函数ZwTerminateProcess的可达路径且用户输入可控，如果存在可利用的执行路径，写出PoC。 在执行路径分析时，检查该IOCTL是否存在访问控制检查或访问控制检查可被绕过。检查该IOCTL是否存在用户可控的危险操作的参数。若无访问控制检查/访问控制检查可被绕过，同时IOCTL存在用户可控参数，则说明存在漏洞，写出PoC。你生成的POC应该包含完整的用户态调用逻辑：创建设备句柄、准备 明确具体步骤。教大模型完成这些任务时应该怎么办。进一步的“思维链提示” 输入缓冲区、设置特定IOCTL码，继而调用DeviceIoControl触发目标路径。请在代码中标明可控字段与预期行为（如触发蓝屏或实现