前言

最近回看Blackhat里和智能体、移动基座相关的议题，最大的感受是：新系统、新架构层出不穷，OpenHarmony这类分布式系统慢慢铺开，如果还沿用老办法，靠零散踩点、随机Fuzz碰运气，效率会越来越低。

Android经过多年沉淀，漏洞类型、攻击面、权限模型、IPC机制、组件暴露缺陷已经有非常成熟的知识库。但OpenHarmony刚起来，公开POC、成熟挖掘经验偏少。

这里就存在一个很关键的突破口：同类设计属性，往往会衍生同类安全缺陷。我们不需要从零摸索新系统，而是先从已有成熟平台的漏洞里抽离属性，再拿着这套属性清单去新系统里对标审计。

这也是现在做智能体挖洞、移动基座审计的核心路线：找漏洞 → 提炼漏洞属性 → 搭建漏洞属性指南 → 跨平台迁移验证（Android漏洞经验迁移OpenHarmony）。

一、先分清：什么是漏洞，什么是漏洞属性

很多师傅容易把两者混在一起。

• 漏洞：是一个具体实例，比如Android某个系统App未导出组件越权访问、某个Binder接口缺少权限校验、Intent隐式调用导致参数注入。它是单点、特定版本、特定代码位置的问题。
• 漏洞属性：是这个漏洞背后，稳定、通用的底层特征，脱离具体代码、具体组件依然成立。

举几个简单的属性例子：

1. 跨进程通信接口，缺少调用方身份校验、权限校验；
2. 对外暴露的入口，可控参数直接进入危险API，没有过滤；
3. 权限模型设计上，高敏感能力被低权限标签包裹；
4. 序列化/反序列化逻辑，接收外部不可信数据，未做类型校验；
5. 配置默认开放，开发者没有最小权限落地；
6. 智能体工具调用链路，输入输出隔离失效、工具权限和Agent权限没有隔离。

同一个漏洞属性，可以在Android、OpenHarmony，甚至Agent工具调用框架里反复出现。
单个漏洞是“鱼”，漏洞属性是“捕鱼的规律”。

传统挖洞：发现一个漏洞，写报告，提交，结束。
基于属性的挖洞：发现一个漏洞，先拆解它属于哪几条属性，记录对应的审计点、判定标准、Payload思路，扩充到自己的漏洞属性指南里，后续去别的同架构系统直接复用这套检查项。

二、完整链路：找漏洞 → 提炼漏洞属性 → 沉淀漏洞属性指南

1. 拿到漏洞实例，先拆解维度

拿到一个已经验证的漏洞，不要急着归档，从这几个角度拆解属性：

• 攻击面：这个入口是IPC、组件、API、配置文件、Agent工具、RPC接口还是网络接口？
• 信任边界：哪里是可信域，哪里是不可信输入？信任边界有没有被打破？
• 校验缺失：缺少身份校验、权限校验、参数校验、输出净化哪一环？
• 设计缺陷：是编码实现问题，还是框架本身设计层面的缺陷？
• 利用前提：是否需要本地权限、是否需要用户交互、是否受版本限制？
• 同类查找特征：静态代码关键词、配置特征、接口命名特征，方便后续批量扫描。

举个例子：Android Binder接口越权漏洞
漏洞实例：A系统服务Binder接口没有checkPermission，第三方App可以直接调用敏感接口。
提炼属性：Binder对外接口，未对调用UID/PID做权限或身份校验；接口能力敏感，调用方可控。
对应的审计检查项：枚举所有Binder服务，遍历接口，查找权限校验逻辑。

2. 持续沉淀，形成漏洞属性指南

漏洞属性指南不是一篇通用漏洞文档，是你自己的、可落地的检查清单，每一条属性绑定：

• 属性描述
• 典型出现场景
• 静态审计特征
• 动态测试方法
• 基础Payload思路
• 平台适配差异（Android特有 / OpenHarmony特有 / 通用）

这个指南是持续迭代的，挖到新漏洞就补属性，遇到平台差异就标注差异点。随着清单变厚，你挖新系统的速度会明显提升，不再完全依赖公开漏洞库。

三、落地实践：Android漏洞属性迁移到OpenHarmony

Android和OpenHarmony底层设计目标不一样，但是很多安全范式是相通的：都有权限管控、跨进程通信、系统服务、组件模型、第三方应用沙箱、对外暴露接口。

我们可以直接把Android沉淀好的漏洞属性清单，平移到OpenHarmony做对标审计，同时区分通用属性和平台独有差异。

通用属性（两边都要重点查）

1. 跨进程通信接口缺少权限、身份校验
   Android：Binder；OpenHarmony：IPC、SAMGR服务
2. 对外暴露入口，可控参数直接传递到危险函数
3. 权限粒度划分粗糙，敏感能力被低等级权限覆盖
4. 序列化、Parcel相关数据未做校验，存在反序列化风险
5. 系统预置应用导出入口，缺少调用限制
6. 日志、返回信息泄露敏感数据

需要修正的差异化点（不能直接照搬）

• OpenHarmony的权限体系、ACL、token机制和Android Manifest权限不一样，不能直接套用Android的权限判断逻辑；
• 分布式软总线带来跨设备调用，多出一层跨设备信任边界，这是Android没有的攻击面；
• 组件模型、Ability、Extension和Android四大组件有相似但不完全等价，入口枚举方式不同；
• 系统服务注册、发现机制和Binder体系不一样，枚举工具、静态特征关键词要单独调整。

迁移的正确姿势：
拿着Android总结出来的漏洞属性，而不是拿着Android的POC去硬打OpenHarmony。
属性不变，只是审计入口、工具、判断逻辑跟着平台适配。

四、延伸到智能体（Agent）漏洞挖掘，这套思路同样适用

Blackhat近两年大量议题都在围绕Agent安全，很多人挖Agent漏洞，局限在prompt注入。但用漏洞属性思路去看，Agent的攻击面可以系统化铺开。

Agent相关漏洞属性举例：

1. Agent工具调用边界失控：Agent可以调用高危工具，但工具调用没有独立权限隔离；
2. 输入输出净化失效：用户可控输入直接透传给工具，或者工具返回数据直接给到LLM，没有沙箱隔离；
3. 工具描述、参数定义缺陷：工具Schema校验缺失，参数类型、范围没有限制；
4. 记忆模块越权读取、篡改，不同会话上下文污染；
5. 多Agent协同场景，Agent之间缺少身份鉴权，信任默认建立；
6. 逃逸：Agent可以绕过预设规则，访问宿主本地文件、执行系统命令。

本质上和移动系统的思路一脉相承：先找单点漏洞，抽离底层属性，做成检查清单，批量审计所有Agent工具链。

五、这套思路的优势和局限

优势：

1. 摆脱“漏洞跟着公开报告走”的被动模式，具备前置挖掘能力；
2. 跨平台迁移成本低，新系统、新框架上手速度大幅提升；
3. 适合沉淀个人知识库，SRC批量审计、定向挖洞效率更高；
4. 适配Agent这类新兴方向，现在公开标准化挖掘方法不多，这套思路很适合形成自己的方法论。

局限也要客观看待：

1. 属性是规律，不是万能公式，平台架构差异会带来不适用场景，需要持续修正；
2. 0day很多时候来自框架全新设计带来的新属性，旧属性清单覆盖不到；
3. 依然需要扎实的底层基础，懂IPC、权限、沙箱、Agent运行链路，不然只能停留在纸面清单。

六、个人实操建议

1. 每挖到一个漏洞，强制写一份属性拆解，而不是只写漏洞报告；
2. 维护一份Markdown格式的漏洞属性清单，按攻击面分类，持续更新；
3. 做新系统审计前，先梳理：这个系统和你熟悉的老系统，哪些安全范式一致、哪些是新增攻击面；
4. 不要沉迷POC复制，重点观察：同一个漏洞属性，在不同架构下的表现形式差异；
5. 智能体安全可以单独维护一套属性分支，和传统移动系统分开，方便后续定向研究。

结尾

漏洞挖掘到后期，拼的不只是Fuzz脚本、抓包工具，更多是归纳和迁移的能力。
Blackhat很多议题给我们的启发，不是某个炫酷的POC，而是研究者看待系统安全的视角：从单个缺陷，上升到设计层面的共性缺陷。

从Android到OpenHarmony，再到现在火热的智能体安全，漏洞会变，但漏洞背后的属性规律相对稳定。抓住属性，就是抓住一套可以持续复用的挖洞框架。

https://hongkai.org/papers/usenix26_SoK_Android_OpenHarmony.pdf
https://www.youtube.com/watch?v=VNYe3Cnk5Pw