跳到正文
原文
研究者论文追踪· arXiv:2609.23980· Andy K. Zhang, Ava Huang, Joey Ji, Wai Han, Thomas Qin, Nardos Demilew, Michael Tian-Yue Liu, Brian Song, Riya Dulepet, Brian Wang, Kyleen Liao, Cuiyuanxiu Chen, Nishka Kacheria, Andrew Wu, Pratham Ra·本站收录 · 原文发表 精选关注度32

斯坦福与 UC Berkeley 发布 MobileCybench:用可执行探针评测 Agent 漏洞发现

MobileCybench: Evaluating Agent Vulnerability Discovery via Executable Probes

论文速读

评测/基准

据论文 PDF 整理(Gemini 生成),以原文为准

作者以探针评估5款智能体测试13款Android应用,GPT-5.6-Sol在APK混淆恶意应用下触发率53.8%。

问题
AI智能体提交软件漏洞报告的速度远超维护者审查能力,而判断利用是否成立需要结合应用特定安全属性进行人工研判,成本高昂。现有基准仅关注已知CVE或通用崩溃,无法评估智能体对应用特定业务安全属性的违背。
方法
提出以可执行探针评估漏洞利用的框架,并在13款Android应用中构建MobileCyBench基准(495个探针)。智能体生成恶意APK或远程利用脚本,评测器在独立环境中重放并由探针检查受损状态,再经补丁差分归因漏洞。
实验与结果
5款智能体在APK-only与源码可见设置下总体触发率分别为28.8%与32.8%。OpenCode/GPT-5.6-Sol在APK-only恶意应用下触发率为53.8%。所有触发均来自应用特定探针,通用探针未被触发。
局限与可以继续做的
基准仅覆盖13款可从源码构建的Android应用,探针依赖人工判断且不代表所有属性;未触发仅表示未违背受检属性;归因依赖可用补丁差分;部分智能体存在提供商安全拒绝;未审计主机算力与模型服务后端的波动。
实验设置OpenCode/GPT-5.5、OpenCode/GPT-5.6-Sol 等 · MobileCyBench · trigger rate (pass@2)、distinct vulnerabilities detected
模型
OpenCode/GPT-5.5OpenCode/GPT-5.6-SolOpenCode/GLM-5.2Claude Code/Opus 4.8Claude Code/Opus 5
基准
MobileCyBench
指标
trigger rate (pass@2)distinct vulnerabilities detected
AI 导读和推荐理由全文 325 字

斯坦福与 UC Berkeley 研究者提出 MobileCybench,用可执行探针(probe)评测 AI Agent 在 Android 应用中发现漏洞的能力,探针检查的是应用的安全属性而非已知漏洞清单,因此可对探针编写时尚未知的漏洞计分。基准包含 13 个开源 Android 应用、495 条由作者编写并评审的探针,覆盖机密性、完整性、可用性与访问控制四类属性,并设置恶意应用与远程攻击者两种攻击场景,每种再分仅提供混淆 APK 与可见源码两种访问级别。所有触发均来自应用特定探针,通用探针从未触发。构建与运行基准过程中发现 23 个此前未报告的漏洞,维护者已确认 12 个,其中 7 个已修补、5 个已确认,6 个获得公开 CVE 编号。

推荐理由论文给出 13 个 Android 应用、495 条探针的评测框架,并披露 23 个此前未报告的漏洞,可对照现有 Agent 安全基准的评分方式。

深度解读

6 个问题,约 5,900 字。每问先给一句结论,点开看完整回答

  1. 这篇论文试图解决什么问题?

    智能体漏洞报告爆发导致审查过载,论文解决如何对破坏应用特定安全属性的报告进行可执行自动化评估。

    评估智能体提交的漏洞报告需要耗费大量人工审查,现有基于已知 CVE 或通用崩溃的基准无法自动化检验破坏应用特定业务安全属性的漏洞。

    • 审查过载的现实挑战:AI 智能体提交漏洞报告的速度已超过维护者审核能力,判断漏洞利用是否成立高度依赖应用特定的业务逻辑与安全属性(如位置欺骗)。
    • 现有评估基准的局限:现有基准要么将检查绑定在已知漏洞的特定状态或差分构建上,无法对未知漏洞评分;要么仅检查通用崩溃或内存安全违规,无法捕捉应用特定的安全问题。
    • 核心设想与属性探针:应用安全属性是系统必须满足的条件,违背该属性即对应安全属性失效;将这些属性编写为独立的可执行探针(Probes),即可在无需已知漏洞签名的情况下判定利用是否成功。
    • 威胁模型(Threat Model):
      • 目标与范围:智能体发现并利用目标应用中违背机密性、完整性、可用性或访问控制的高影响漏洞。
      • 恶意应用设置(Malicious app):攻击者控制同设备上的普通权限应用,使用标准 IPC、Intent、广播、Content Provider 等用户级能力,不可申请签名或特权权限,不可使用 root、UI 自动化或测试插桩。
      • 远程攻击者设置(Remote attacker):攻击者持有应用后端的低权限非管理员账户,通过网络请求攻击后端以越权影响其他受害者账户,无受害者凭证或后端内部权限。
      • 受害系统:运行在 Android 模拟器中的目标应用及隔离部署的自建后端服务。
  2. 有哪些相关研究?

    相关研究包括网络与主机环境的智能体网安基准、Android系统安全分析工具,以及作为可执行检查的安全属性验证。

    相关研究主要涵盖智能体网络安全基准、Android 移动安全评估以及基于可执行测试断言的安全属性验证三大方向。

    智能体网络安全基准(Agentic Cybersecurity Benchmarks)

    • 已知漏洞结果匹配类:Cybench(Zhang et al., 2025b)使用夺旗机制;CVE-Bench(Zhu et al., 2025)记录 CVE 攻击结果;SEC-bench(Lee et al., 2025)匹配已知漏洞的 Sanitizer 报告;ExploitBench(Lee & Brumley, 2026)在 V8 利用阶段放置 Flag;BountyBench(Zhang et al., 2025a)基于维护者补丁验证利用是否失效。作者指出这类工作将检查绑定于已知漏洞,无法为未知漏洞评分。
    • 通用运行时不变式类:CyberGym(Wang et al., 2026; Shi et al., 2026)、AIxCC(Zhang et al., 2026)以及 BountyBench 的运行时检查关注通用服务崩溃或不可用。作者指出这类通用指标无法捕捉应用特定的业务逻辑违规。

    Android 系统安全研究(Android Security)

    • 移动安全基准与工具:Ghera(Mitra & Ranganath, 2017)构建了已知漏洞的 Android 应用仓库;CHEX(Lu et al., 2012)静态审查组件劫持;A2(Wang & Zhou, 2025)利用智能体挖掘 Android 漏洞并通过 LLM 生成的 Oracle 进行验证。作者指出既有网安基准均在 Linux 主机或 Web 应用运行,未覆盖 Android 特有的 IPC、组件导出与 WebView 攻击面。

    作为可执行检查的安全属性(Security Properties as Executable Checks)

    • 测试断言与安全策略:运行时验证(Leucker & Schallhart, 2009)、变异安全测试(Mai et al., 2020)与 Sanitizers(Serebryany et al., 2012)监控运行期异常;强制安全策略(Schneider, 2000)定义禁止行为;CWEval(Peng et al., 2025)为代码生成任务配备可执行安全测试。

    基线方法与基准定位

    • 对比基线与定位:基准评测了 OpenCode(集成 GPT-5.5、GPT-5.6-Sol、GLM-5.2)与 Claude Code(集成 Opus 4.8、Opus 5)共 5 款代码智能体。作者将 MobileCyBench 定位为在真实可运行 Android 应用及后端上,通过人工编写的 495 个安全属性探针与补丁差分归因机制,评估智能体开放式漏洞挖掘能力的评测基准。
  3. 论文如何解决这个问题?

    构建包含13款Android应用的MobileCyBench,以495个可执行探针检验状态,并通过补丁差分执行漏洞归因。

    论文提出了基于可执行探针(Probes)的漏洞评测框架并实例化为 MobileCyBench,通过重放利用脚本、运行探针检查系统状态变化,并结合补丁差分归因漏洞。

    问题设定与评测流程

    评测任务形式化为包含目标应用环境、攻击设置、访问级别和隐藏探针套件的组合。探针是不依赖具体攻击手法的可执行断言,若受害系统在攻击重放后的状态违背了预期属性,探针即触发。

    探针设计与两层评分体系

    • 应用特定探针(Application-Specific Probes):作者依据源码、文档及前期试点测试,为每款应用梳理机密性、完整性、可用性和访问控制(CIAA)四类属性,检查服务端未授权修改、越权读取文件、未授权设备控制等(Section A.2)。
    • 通用探针(Generic Probes):在恶意应用设置中额外包含 9 种通用检查(共 81 个实例),检查进程崩溃、植入秘密泄露、文件受控篡改与容器可用性(Section B.7)。
    • 可信状态采集:探针只读取模拟器日志、服务端数据库或后端 REST API 等受信状态,不信任攻击者进程标准输出或本地标记文件(Section A.2)。

    攻击执行与沙箱重放协议

    • 开发阶段:智能体在 Kali Linux 容器中获得 2 小时时限,拥有 ADB、APK 工具链及开发专用凭证,可自由交互与迭代测试(Section B.3)。
    • 利用提交契约:恶意应用设置提交包含源码的项目目录,仅允许申请 normal 或 dangerous 级权限;远程攻击设置提交可执行的 exploit.sh 脚本(Section B.1)。
    • 独立环境重放:评测器在重构的 Android 虚拟机(Pixel 2 配置文件)及 Docker Compose 后端中重放,严格隔离开发凭证,自动完成受害者登录操作后再执行攻击并运行探针(Section B.4、B.5)。

    补丁差分漏洞归因机制

    • 参考漏洞库构建:针对发现的候选漏洞,将易受攻击的基线构建与作者编写的最小修复补丁(或上游修复)配对,形成归因包(Section D.3)。
    • 双构建差分判定:将触发探针的保存利用分别在无补丁和有补丁版本上重放。当且仅当探针在无补丁版本触发而在有补丁版本恢复静默时,该利用被归因为对应的参考漏洞(Section D.4)。
  4. 论文做了哪些实验?

    在13款应用上评测5款智能体共250种配置,GPT-5.6-Sol触发率最高,所有触发均来自应用特定探针。

    实验在 13 款真实 Android 应用与自建后端上,对 5 款智能体在 4 种设置下的漏洞挖掘与利用生成能力进行了系统评估。

    实验设置

    • 被测模型与智能体:OpenCode/GPT-5.5、OpenCode/GPT-5.6-Sol、OpenCode/GLM-5.2、Claude Code/Opus 4.8、Claude Code/Opus 5,共 5 款代码智能体(Table 6)。
    • 测试应用与基准:涵盖 Audiobookshelf、Conversations、Home Assistant、Jerboa、Moe Memos、Moodle Mobile、Nextcloud Talk、ntfy、openHAB、ownCloud、OwnTracks、Termux、wallabag 共 13 款开源应用(Table 1)。
    • 攻击与访问设置:包括恶意应用(Malicious app)与远程攻击者(Remote attacker)两种路径,每种路径分别评估混淆 APK(APK-only)与开放源码(source-visible)两种访问级别。Termux 因无后端无远程任务,全网格共 250 种配置(Section 4.1)。
    • 评测指标:配置触发率(pass@2,两次尝试中任一次触发即计为成功)、独立漏洞检出数(去重归因后)。
    • 判定与评审方式:由 495 个预设探针读取可信系统状态判定,无 LLM 主观打分(Section 2.2、Table 1)。
    • 运行预算与重复:每种配置独立运行 2 次,单次运行时间上限 2 小时(7200 秒),全网格共计 500 次智能体生成运行(Section B.3)。

    主结果

    下表汇总了 5 款智能体在各攻击设置与访问级别下的配置触发率(pass@2,据 Table 10 与 Table 11):

    表格较宽,可左右滑动

    智能体恶意应用 (APK)恶意应用 (源码)远程攻击 (APK)远程攻击 (源码)检出独立漏洞数
    OpenCode/GPT-5.546.2%46.2%16.7%33.3%13
    OpenCode/GPT-5.6-Sol53.8%53.8%16.7%25.0%14
    OpenCode/GLM-5.215.4%30.8%16.7%16.7%6
    Claude Code/Opus 4.838.5%38.5%16.7%16.7%9
    Claude Code/Opus 546.2%38.5%16.7%25.0%10
    • 得分最高智能体表现:OpenCode/GPT-5.6-Sol 在 APK-only 恶意应用设置下取得最高的 53.8% 触发率,并检出最多的 14 个独立漏洞(Table 10、Table 11)。
    • 源码访问的增益幅度:总体配置触发率从 APK-only 的 28.8% 提升至源码可见下的 32.8%(Figure 4a),检出的独立漏洞数由 12 个增加至 17 个(Figure 4b)。
    • 通用探针完全静默:在恶意应用产生的全部 80 次触发运行中,81 个通用检查探针触发次数为 0,所有触发均由应用特定探针捕获(Section 4.2、Table 3)。

    漏洞归因与重复性分析

    • 重复触发高度指向同一漏洞:在两次尝试均触发的 47 组配置中,有 42 组经补丁差分归因为完全相同的漏洞包,仅 2 组归因为不同漏洞,3 组未完全判定(Section C.2)。
    • 远程利用比本地利用更稳定:在首轮触发的前提下,远程攻击第二轮复现率为 20/22,而恶意应用设置为 27/41,作者指出本地 Android IPC 利用的时序和环境不稳定性更高(Section C.2)。

    提供商安全机制拒绝分析

    • Claude Code 出现拒绝情况:Claude Code/Opus 4.8 拒绝率为 25.0%(24/96),Claude Code/Opus 5 拒绝率达 42.4%(42/99),且多发生于恶意应用构建阶段(Section C.6)。
    • OpenCode 智能体无拒绝记录:OpenCode 下的 GPT-5.5、GPT-5.6-Sol(享有网络安全信任访问权限)以及 GLM-5.2 均未记录到提供商内容安全拦截(Section C.6)。

    预训练与运行时污染审计

    • 外部检索被网络限制阻断:在 15 次尝试检索公共代码或元数据的 APK-only 触发运行中,所有外部请求均被代理返回 403 阻断(Table 17)。
    • 已知漏洞重建案例:在 ownCloud 任务中,部分智能体利用了早在 2023 年即公开的 CVE-2023-49105 逻辑,作者将其明确分类为重构建而非新发现(Section D.8)。

    其他消融与分析

    • 无智能体基线校验:在 25 个应用与设置对中重放空操作脚本,探针触发率为 0/25(Section A.6)。
    • 参考利用探针覆盖度:24 个包含参考利用的归因包中,标准探针套件成功触发 19 个(79%)(Section A.5)。
    • API 成本统计:500 次运行总计消耗 API 费用 6,973.19 美元,中位数单次配置成本为 10.95 美元(Table 20)。
    • 配对显著性检验:双访问级别合并后,OpenCode/GLM-5.2 与 OpenCode/GPT-5.6-Sol 存在显著差异(p = 0.004),其余相邻排名差异均不显著(Section C.1)。
  5. 有什么可以进一步探索的点?

    作者指出探针覆盖不完整、需要人工维护等局限;实验未覆盖iOS且受测应用仅13款。

    论文在探针设计与维护、归因依赖等方面指出了明确局限,并在评测应用范围与执行环境上存在既定边界。

    作者指出的局限与后续方向

    • 探针覆盖率无法代表所有漏洞:由于未知应用中实际存在的漏洞总数未知,探针套件无法声称对所有潜在漏洞具备覆盖率,探针静默仅代表未违反受检属性(Section 6、Section B.8)。
    • 探针集的长效维护开销:随着应用程序功能的持续迭代与代码演进,安全属性探针本身需要不断同步维护与更新,构建基准单应用耗费约 30 人时(Section 6)。
    • 属性选择主观性:各应用的被测属性源于作者对源码和文档的研判及试点运行,反映了作者的主观判断,可能无法代表全部 Android 安全属性(Section A.4、Section B.8)。
    • 部分漏洞利用难以完全无人重放:有 1 个已知漏洞利用需要真实受害者用户主动交互打开载荷才能生效,当前的无人自动化重放框架无法完成复现(Section A.5)。
    • 归因依赖完整工程制品:补丁差分归因必须依赖保存的利用代码、固定的目标状态及可编译的补丁版本,部分下载的 APK 运行无法重建差分(Section D.5)。

    实验覆盖范围

    • 平台仅覆盖 Android:实验仅测试了 Android 移动平台,未包含其他移动操作系统(Section B.8)。
    • 应用样本量为 13 款:评测对象仅涵盖 13 款可从源码编译并自建后端的开源应用,非随机抽样(Section 3、Section B.8)。
    • 测试模型共 5 款:实验仅评测了 3 款 OpenCode 驱动与 2 款 Claude Code 驱动的智能体配置(Table 6)。
    • 主机硬件资源未完全固定:论文未在日志中固化宿主机 vCPU、内存及 SSD 等计算硬件分配(Table 18)。
    • 提供商后端模型版本未锁死:闭源模型 API 可能会在相同模型标识符背后发生变动,论文未记录具体的后端端点指纹(Section B.3、Section B.8)。
  6. 总结一下论文的主要内容

    MobileCyBench提出通过可执行探针自动化评估智能体在13款Android应用中的漏洞发现能力与实际利用。

    该研究提出了基于可执行安全属性探针的自动化评估基准 MobileCyBench,用于衡量 AI 智能体在移动应用及后端环境下的漏洞挖掘与利用生成能力。

    • 核心定位与挑战:针对 AI 智能体生成漏洞报告过载且缺乏业务安全判定标准的问题,基准摆脱了对已知 CVE 签名的依赖,转而检验应用固有安全属性是否遭到破坏。
    • 基准构建机制:涵盖 13 款可运行开源 Android 应用及隔离后端,设计并人工审查了 495 个覆盖 CIAA 属性的检查探针,支持恶意应用与低权限远程攻击两种场景。
    • 利用重放与差分归因:评测器在独立沙箱与重构模拟器中重放智能体提交的利用,结合探针触发结果与补丁前后差异,实现对具体漏洞的精准归因。
    • 关键实验发现:评测 5 款代码智能体发现,OpenCode/GPT-5.6-Sol 在 APK-only 恶意应用下取得最高 53.8% 的触发率;所有有效触发均来自应用特定探针,通用探针无一触发。
    • 真实漏洞与安全启示:研究共挖掘出 23 个此前未报告的应用漏洞,其中 12 个已获维护者确认、6 个已分配 CVE;作者指出这反映出受测智能体已能在部分真实应用中构建破坏安全属性的利用。
阅读原文arxiv.org