背景
隨着 AI 大模型實盤交易競賽的升溫，越來越多的加密社區與開發者開始嘗試以 AI 驅動的自動化交易，諸多開源方案也被快速投入使用。然而，這些項目中不乏安全隱患。
NOFX AI 是一款基於 DeepSeek/Qwen AI 的開源加密貨幣期貨自動交易系統，支持 Binance、Hyperliquid 與 Aster DEX 等交易所。慢霧安全團隊接到 @Endlessss20 提供的最初情報，懷疑該系統可能會導致交易所 API Key 等泄漏，遂對此展開安全分析。
開源地址：https://github.com/NoFxAiOS/nofx
漏洞成因分析
經過慢霧安全團隊的深入分析，發現 NOFX AI 在不同 commit 版本中存在兩類主要鑑權問題。
“零鑑權”漏洞版本
2025 年 10 月 31 日的提交 517d0caf6fb091235e56c27889170b53a16e4e6b（origin/main、origin/dev 等分支均包含）引入了“默認管理員模式”，該 commit 版本的管理員模式默認開啓且中間件直接放行。
config.json.example:1-24 與數據庫遷移腳本都把 admin_mode 設爲 true，main.go:42-63 在讀取後直接調用 auth.SetAdminMode(true)。
更關鍵的是，在代碼 api/server.go#L799 可以看到，只要 auth.IsAdminMode() 爲 true，中間件會直接 return，完全跳過了 Authorization 認證頭的檢查。
因此在這個 commit 提交及之前，只要部署保持默認管理員模式，任何人都能直接訪問 /api/exchanges，拿到全部交易所 API/私鑰。
在這種模式下，所有受鑑權保護的 API 包括 /api/exchanges 都會按 “admin” 身份執行，因此任何人只需向公開的 API 發起 GET 請求就能拿到數據庫中 ExchangeConfig 的完整內容。
ExchangeConfig 字段包括 api_key、secret_key、hyperliquid_wallet_addr 以及 aster_private_key，均爲交易所登錄密鑰或私鑰。也就是說，只要保持默認管理員模式，任何人都可直接訪問 /api/exchanges 並獲取全部交易所 API/私鑰。這份 commit 的代碼相當於將所有交易所密鑰暴露在一個無需登錄的 GET 接口上。
要求 Authorization 的版本
在 2025 年 11 月 5 日的提交 be768d91a3969b39741623c9507f3119e583eb16(PR #540 “Enable admin password in admin mode”) 中， 開發者移除了原先只要檢測到 admin_mode 就直接放行不驗證 Authorization 的邏輯。
需要注意的是該 commit 目前只在 dev 系列分支裏（包括本地 dev 和 origin/dev 等）。origin/main 並沒有包含這個提交。
authMiddleware 被改寫爲 api/server.go:1471-1511 的形式，必須攜帶 Authorization: Bearer <token> 才能進入受保護路由。若格式錯誤或 JWT 驗證失敗，會直接返回 401。
同一提交還新增了 /api/admin-login，要求部署者設置環境變量 NOFX_ADMIN_PASSWORD，也就是管理員模式不再是“無需登錄自動生效”。如果 admin_mode 還是 true，main.go:203-226 會檢查環境變量 NOFX_ADMIN_PASSWORD，並調用 log.Fatalf 直接終止進程，除非事先設置了該變量。設置完成後，管理員必須通過新的 /api/admin-login 接口提交這個密碼才能拿到 JWT；沒設密碼就啓動，會在初始化階段被強制退出。
不過，這次改動只是把“完全無鑑權”升級爲“必須提供 JWT”，仍然沒有解決兩個核心問題。
一是 config.json.example:1-27 依舊寫死 jwt_secret，main.go:203-214 在環境變量缺失時繼續回退到那個公開字符串。
若開發者直接使用示例配置文件，將導致默認密鑰被啓用，從而存在安全風險。而項目中的的默認部署腳本 start.sh 文件在檢測到缺失配置時，會直接複製示例配置文件來使用。
二是 /api/exchanges 仍然以 JSON 形式把 api_key、secret_key、Aster 私鑰等敏感字段原樣返回。
因此，該版本訪問 /api/exchanges 雖需 Authorization，但攻擊者仍可通過默認密鑰創建 JWT 或調用默認登錄接口獲取 token，從而讀取全部密鑰。
當前版本固定 JWT 問題依舊存在
截至目前（2025 年 11 月 13 日左右），dev 分支的 HEAD 爲 b2e4be91523dc606be8708ec6602fecbbb0c20ea（PR #546 “Feature/faq”）。慢霧安全團隊重新 checkout 這份提交後覈對發現：
authMiddleware 仍是 api/server.go:1471-1511 的實現，需要 Bearer token；
/api/exchanges 仍直接返回 ExchangeConfig（api/server.go:1009-1021）；
config.json.example:1-27 和 main.go:198-226 依舊硬編碼 admin_mode=true 與默認 jwt_secret。
因此，只要運維人員沒有主動更換 jwt_secret 並關閉管理員模式，攻擊者仍可利用公開密鑰創建固定 JWT，進而訪問 /api/exchanges 並獲取所有交易所 API/私鑰。換言之，2025-11-05 的修復僅僅把漏洞從“零鑑權”變成了“憑默認密鑰鑑權”，問題的根源依然存在。
影響
我們根據程序特徵，全網搜索，發現公網存在 1000+ 已經私有化部署並且對外開放的系統：
慢霧安全團隊意識到，隨時可能出現攻擊情況，第一時間全盤考慮安全方案，最終我們決定聯繫幣安安全團隊、OKX 安全團隊，慢霧與幣安、OKX 成立安全作戰室，我們提供情報、影響範圍，幣安安全團隊、OKX 安全團隊各自獨立交叉驗證，根據獲得的 api_key 反向推進，從系統層面定位受影響用戶，告知用戶面臨的安全風險，第一時間更換 api_key、secret_key 等信息，防止用戶資產被對敲導致資損，保護用戶資產安全。
截至 11 月 17 日，所有受影響的 CEX 用戶均已完成通知，並已廢棄相關密鑰，用戶資產處於安全狀態。
對於少數 Aster、Hyperliquid 用戶，慢霧與幣安團隊已嘗試主動聯繫，但由於地址爲去中心化錢包地址，我們無法直接觸達具體用戶。如您正在使用 Aster、Hyperliquid 的自動化交易系統，請及時檢查並處理相關風險。
同時，我們將與 NOFX AI 團隊溝通本次漏洞詳情，並提供修復建議，協助其完善系統安全。
總結與建議
當下 AI 大模型量化項目正熱，但多數開源實現仍處於早期階段。部署這類新興開源系統時，務必要先做充分的代碼安全審計並強化風控措施，避免造成資金的損失。
綜合上述分析，NOFX 項目雖經修復嘗試，但核心問題仍未解決。任何部署 NOFX 項目的 commit 517d0caf 及更早版本（origin/main 目前仍停在這一代）都處於“無需 Authorization”狀態，必須立即升級或手工關閉 admin 模式。
即便升級到 be768d9 或當前 HEAD，如果繼續使用默認 jwt_secret，攻擊者仍可以通過創建固定 Authorization 頭拿到密鑰。要徹底修復該漏洞，需要同時做到：
1. 隨機化 JWT 密鑰：啓動時若發現 jwt_secret 與模板相同，拒絕運行；建議改爲寫入安全存儲或密鑰管理系統。
2. 禁用默認管理員模式：僅在顯式配置時才允許 admin 模式，並要求強密碼 + OTP；非 admin 模式下 /api/admin-login 應直接關閉。
3. 最小化 /api/exchanges 響應：默認只返回啓用狀態、測試網標誌等非敏感字段；導出 API/私鑰需單獨接口並二次驗證，且服務端對字段做脫敏或加密。
在開發團隊完成這些修復之前，任何面向公網的部署都應視爲高危。尤其是 origin/main 仍處於 517d0c 的“零鑑權”階段，維護方需儘快同步最新代碼並嚴格執行自定義密鑰及接口加固策略。
致謝
再次感謝 @Endlessss20 提供的最初情報源！