黄金加密学
菜单

NOFX AI 鉴权漏洞复盘:默认管理员模式与公开 JWT 密钥如何暴露交易凭据

原文发布于 2025 年 11 月 17 日 11:38:22(UTC+8),作者为 Yao、Thinking、Pds,编辑为 77。以下版本状态、排查结果及处置进展均以原文报告时点为准,不代表项目当前状态。

NOFX AI 是一款基于 DeepSeek/Qwen AI 的开源加密货币期货自动交易系统,支持 Binance、Hyperliquid 与 Aster DEX 等交易所。慢雾安全团队在收到 @Endlessss20 提供的线索后,对其交易所 API Key 等敏感信息可能泄漏的问题展开分析。

据慢雾报告,不同提交版本存在两类相互关联的鉴权问题:早期默认管理员模式可直接绕过认证;后续版本虽然要求提供 JWT,但示例配置中的公开默认签名密钥仍可能被沿用。同时,交易所配置接口会原样返回 API 密钥及部分私钥字段,使鉴权缺陷直接影响交易凭据的保密性。

第一阶段:默认管理员模式绕过认证

慢雾分析的 2025 年 10 月 31 日提交 517d0caf6fb091235e56c27889170b53a16e4e6b 引入了默认管理员模式。报告指出,该提交包含在当时的 origin/main、origin/dev 等分支中。

在这一版本中:

  • 示例配置与数据库迁移脚本将 admin_mode 设为 true;
  • 程序读取配置后启用管理员模式;
  • 鉴权中间件发现管理员模式开启,就直接放行,不再检查 Authorization 请求头。

按慢雾的分析,保持默认管理员模式的相关部署,无需登录即可访问 /api/exchanges。受保护接口会以 admin 身份执行,该接口则返回数据库中的完整 ExchangeConfig。

返回字段包括 api_key、secret_key、hyperliquid_wallet_addr 和 aster_private_key。其中既有交易所 API 凭据、钱包地址,也有私钥字段。对外开放接口与默认免认证行为叠加,构成了敏感信息泄漏路径。

第二阶段:要求 JWT,但默认签名密钥仍可被沿用

2025 年 11 月 5 日的提交 be768d91a3969b39741623c9507f3119e583eb16,对应 PR #540“Enable admin password in admin mode”,移除了管理员模式下直接跳过认证的逻辑。

修改后的中间件要求请求携带 Authorization: Bearer <token>;格式错误或 JWT 验证失败时返回 401。同一提交新增 /api/admin-login,要求管理员通过密码获取 JWT。如果启用了管理员模式却未设置环境变量 NOFX_ADMIN_PASSWORD,程序会在初始化阶段终止。

这意味着管理员模式不再默认免登录,但并不等于凭据泄漏风险已经消除。 慢雾指出,当时这项提交仅进入 dev 系列分支,origin/main 尚未包含该提交;同时仍有两个关键问题:

  1. JWT 签名密钥可能沿用公开默认值。 示例配置仍写有固定的 jwt_secret,相关环境变量缺失时,程序会回退到公开字符串。默认部署脚本 start.sh 在配置缺失时还会直接复制示例配置,增加默认值被实际使用的可能。
  2. 敏感接口仍返回完整凭据。 /api/exchanges 继续以 JSON 原样返回 api_key、secret_key、Aster 私钥等字段。

在继续使用默认 JWT 签名密钥的部署中,攻击者可利用公开密钥构造可通过验证的 JWT,再访问敏感接口。新增管理员密码要求,并未消除这一签名信任边界上的缺陷。

截至 2025 年 11 月 13 日左右的复核结果

慢雾报告称,其重新检出了当时 dev 分支的 HEAD:b2e4be91523dc606be8708ec6602fecbbb0c20ea,对应 PR #546“Feature/faq”。复核发现:

  • 鉴权中间件仍要求 Bearer token;
  • /api/exchanges 仍直接返回 ExchangeConfig;
  • 示例配置及启动逻辑仍保留默认开启的管理员模式和默认 jwt_secret。

因此,报告认为,未主动替换默认 JWT 签名密钥、仍沿用相关默认配置的部署,依然存在被构造令牌并读取交易凭据的风险。11 月 5 日的改动增加了认证步骤,但没有同时解决公开默认密钥和接口过度返回敏感信息的问题。

暴露范围与处置:不能将部署数量等同于受损人数

慢雾称,依据程序特征进行全网搜索后,发现 1,000 多个已私有化部署且对公网开放的系统。这一数字是报告中的公网部署发现数量,并非已确认遭攻击、发生资产损失的用户数量。

据原文,慢雾随后联系币安与 OKX 安全团队,三方成立安全作战室。慢雾提供情报及影响范围,币安、OKX 安全团队各自独立交叉验证,并根据获得的 API Key 定位受影响用户,通知其更换 api_key、secret_key 等信息,以防范对敲导致的资产损失。

截至 2025 年 11 月 17 日,慢雾称所有受影响的 CEX 用户均已完成通知,相关密钥已废弃,用户资产处于安全状态。 原文没有披露已确认的被盗金额。

对于少数 Aster、Hyperliquid 用户,慢雾与币安团队表示已尝试主动联系,但由于相关地址为去中心化钱包地址,无法直接触达具体用户。原文因此提醒使用这类自动化交易系统的用户检查并处理风险,并表示将与 NOFX AI 团队沟通漏洞详情、提供修复建议。

修复应同时覆盖认证、默认配置和敏感数据返回

慢雾在报告中提出的修复建议包括:

  1. 替换并约束 JWT 签名密钥。 启动时发现 jwt_secret 与模板相同,应拒绝运行;建议将密钥存入安全存储或密钥管理系统。
  2. 取消默认管理员模式。 仅允许显式配置启用,并要求强密码与一次性密码(OTP);非管理员模式下关闭 /api/admin-login。
  3. 收紧 /api/exchanges 响应。 默认仅返回启用状态、测试网标志等非敏感字段。导出 API 凭据或私钥应使用独立接口,并要求二次验证,同时对相关字段进行脱敏或加密处理。

针对报告涉及的旧版本,慢雾建议立即升级或手动关闭管理员模式;对于已引入 JWT 认证的版本,也不能仅凭“接口需要 token”判断安全,仍需更换默认签名密钥并加固敏感接口。报告将完成上述修复前的公网部署视为高危。

这次分析涉及的关键并非 AI 模型本身,而是自动交易系统如何保管交易凭据、验证调用者身份,以及限制敏感数据的返回范围。慢雾据此建议,部署此类早期开源系统前,应先完成充分的代码安全审计并强化风控措施。

来源:慢雾《三方并肩:NOFX AI 交易系统漏洞守卫战》;NOFX AI 开源仓库。

延伸阅读