Ba bên đồng hành: Cuộc chiến bảo vệ lỗ hổng hệ thống giao dịch NOFX AI

Tác giả: Yao & Thinking & Pds Biên tập: 77

Bối cảnh

Khi cuộc thi giao dịch thực tế với mô hình AI lớn đang nóng lên, ngày càng nhiều cộng đồng tiền điện tử và nhà phát triển bắt đầu thử nghiệm giao dịch tự động dựa trên AI, nhiều giải pháp mã nguồn mở cũng được đưa vào sử dụng nhanh chóng. Tuy nhiên, trong số những dự án này không thiếu những mối nguy hiểm về an ninh.

NOFX AI là một hệ thống giao dịch tự động hợp đồng tương lai tiền điện tử mã nguồn mở dựa trên DeepSeek/Qwen AI, hỗ trợ các sàn giao dịch như Binance, Hyperliquid và Aster DEX. Đội ngũ bảo mật Slow Fog đã nhận được thông tin ban đầu từ @Endlessss20, nghi ngờ rằng hệ thống này có thể dẫn đến việc rò rỉ API Key của sàn giao dịch, do đó đã tiến hành phân tích an ninh.

Địa chỉ mã nguồn mở: https://github.com/NoFxAiOS/nofx

Phân tích nguyên nhân lỗ hổng

Sau khi nhóm an ninh Slow Fog tiến hành phân tích sâu, đã phát hiện ra rằng NOFX AI tồn tại hai loại vấn đề xác thực chính trong các phiên bản commit khác nhau.

“Lỗi không xác thực” phiên bản

Việc nộp vào ngày 31 tháng 10 năm 2025 với mã 517d0caf6fb091235e56c27889170b53a16e4e6b (bao gồm các nhánh origin/main, origin/dev, v.v.) đã giới thiệu “chế độ quản trị viên mặc định”, chế độ quản trị viên của phiên bản commit này được bật mặc định và middleware được cho phép trực tiếp.

config.json.example:1-24 và script di chuyển cơ sở dữ liệu đều đặt admin_mode thành true, main.go:42-63 khi đọc xong sẽ gọi trực tiếp auth.SetAdminMode(true).

（Tham khảo: https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config.json.example）

（Tham khảo: https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config/database.go#L214）

（Tham khảo:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/main.go#L42-63）

Điều quan trọng hơn là, trong mã api/server.go#L799 có thể thấy, chỉ cần auth.IsAdminMode() là true, middleware sẽ trực tiếp return, hoàn toàn bỏ qua kiểm tra tiêu đề xác thực Authorization.

（Tham khảo:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/api/server.go#L799）

Do đó, trong commit này và trước đó, chỉ cần triển khai giữ chế độ quản trị viên mặc định, bất kỳ ai cũng có thể truy cập trực tiếp vào /api/exchanges và lấy toàn bộ API/khóa riêng của sàn giao dịch.

Trong chế độ này, tất cả các API được bảo vệ bởi xác thực, bao gồm /api/exchanges, sẽ được thực hiện với tư cách “admin”, vì vậy bất kỳ ai chỉ cần gửi yêu cầu GET đến API công khai đều có thể lấy được nội dung đầy đủ của ExchangeConfig trong cơ sở dữ liệu.

Trường ExchangeConfig bao gồm api_key, secret_key, hyperliquid_wallet_addr và aster_private_key, đều là khóa đăng nhập hoặc khóa riêng của sàn giao dịch. Điều này có nghĩa là chỉ cần giữ chế độ quản trị mặc định, bất kỳ ai cũng có thể truy cập trực tiếp /api/exchanges và lấy tất cả các API/khóa riêng của sàn giao dịch. Mã của commit này tương đương với việc phơi bày tất cả các khóa của sàn giao dịch trên một giao diện GET không cần đăng nhập.

Yêu cầu phiên bản Authorization

Trong việc nộp vào ngày 5 tháng 11 năm 2025 be768d91a3969b39741623c9507f3119e583eb16(PR #540 “Kích hoạt mật khẩu quản trị trong chế độ quản trị”), các nhà phát triển đã loại bỏ logic trước đây chỉ cần phát hiện admin_mode là tự động cho phép mà không xác minh Authorization.

Cần lưu ý rằng commit này hiện chỉ có trong các nhánh dev (bao gồm dev cục bộ và origin/dev, v.v.). origin/main không bao gồm commit này.

authMiddleware được viết lại theo dạng api/server.go:1471-1511, phải mang theo Authorization: Bearer mới có thể vào các tuyến đường được bảo vệ. Nếu định dạng sai hoặc xác thực JWT không thành công, sẽ trả về 401 ngay lập tức.

（Tham khảo:https://github.com/NoFxAiOS/nofx/blob/be768d91a3969b39741623c9507f3119e583eb16/api/server.go#L1471）

Yêu cầu mới được thêm vào /api/admin-login trong cùng một yêu cầu, yêu cầu người triển khai thiết lập biến môi trường NOFX_ADMIN_PASSWORD, có nghĩa là chế độ quản trị không còn là “không cần đăng nhập tự động có hiệu lực”. Nếu admin_mode vẫn là true, main.go:203-226 sẽ kiểm tra biến môi trường NOFX_ADMIN_PASSWORD và gọi log.Fatalf để dừng quá trình, trừ khi biến này đã được thiết lập trước. Sau khi thiết lập xong, quản trị viên phải gửi mật khẩu này qua giao diện mới /api/admin-login để nhận được JWT; nếu không thiết lập mật khẩu và khởi động, sẽ bị buộc phải thoát trong giai đoạn khởi tạo.

Tuy nhiên, sự thay đổi này chỉ nâng cấp “không cần xác thực” thành “phải cung cấp JWT”, vẫn chưa giải quyết hai vấn đề cốt lõi.

Một là config.json.example:1-27 vẫn giữ jwt_secret cố định, main.go:203-214 sẽ tiếp tục quay lại chuỗi công khai đó khi biến môi trường bị thiếu.

Nếu nhà phát triển sử dụng trực tiếp tệp cấu hình mẫu, điều này sẽ dẫn đến việc khóa mặc định được kích hoạt, từ đó có nguy cơ an ninh. Trong khi đó, tệp kịch bản triển khai mặc định start.sh trong dự án sẽ sao chép tệp cấu hình mẫu để sử dụng khi phát hiện thiếu cấu hình.

Thứ hai là /api/exchanges vẫn trả về các trường nhạy cảm như api_key, secret_key, khóa riêng Aster dưới dạng JSON.

Do đó, phiên bản này truy cập /api/exchanges mặc dù cần có Authorization, nhưng kẻ tấn công vẫn có thể tạo JWT thông qua khóa mặc định hoặc gọi giao diện đăng nhập mặc định để lấy token, từ đó đọc toàn bộ khóa.

Vấn đề JWT cố định hiện tại vẫn còn tồn tại

Tính đến thời điểm hiện tại (khoảng ngày 13 tháng 11 năm 2025), HEAD của nhánh dev là b2e4be91523dc606be8708ec6602fecbbb0c20ea (PR #546 “Feature/faq”). Đội ngũ an ninh Slow Mist đã kiểm tra lại và xác nhận sau khi checkout lại bản commit này:

• authMiddleware vẫn là triển khai của api/server.go:1471-1511, cần Bearer token;
• /api/exchanges vẫn trả về ExchangeConfig trực tiếp (api/server.go:1009-1021);
• config.json.example:1-27 và main.go:198-226 vẫn mã hóa cứng admin_mode=true và jwt_secret mặc định.

Do đó, chỉ cần nhân viên vận hành không chủ động thay đổi jwt_secret và tắt chế độ quản trị viên, kẻ tấn công vẫn có thể lợi dụng khóa công khai để tạo JWT cố định, từ đó truy cập /api/exchanges và lấy tất cả API/khóa riêng của các sàn giao dịch. Nói cách khác, bản sửa lỗi vào ngày 2025-11-05 chỉ đơn giản là biến lỗ hổng từ “không xác thực” thành “xác thực bằng khóa mặc định”, vấn đề gốc rễ vẫn còn tồn tại.

Ảnh hưởng

Chúng tôi dựa trên các đặc điểm của chương trình, tìm kiếm trên toàn mạng, phát hiện có hơn 1000 hệ thống đã được triển khai tư nhân và mở ra cho công chúng:

Đội ngũ an ninh của Slow Mist nhận thức rằng có thể xảy ra tình huống tấn công bất cứ lúc nào, vì vậy chúng tôi đã xem xét tổng thể các phương án bảo mật ngay lập tức. Cuối cùng, chúng tôi quyết định liên hệ với đội ngũ an ninh của Binance và OKX. Slow Mist đã thành lập phòng tác chiến an ninh với Binance và OKX, chúng tôi cung cấp thông tin và phạm vi ảnh hưởng. Đội ngũ an ninh của Binance và OKX sẽ độc lập kiểm tra chéo và xác minh, dựa trên api_key đã nhận được để xác định ngược lại, từ cấp hệ thống xác định người dùng bị ảnh hưởng, thông báo cho người dùng về các rủi ro an ninh mà họ đang đối mặt, thay đổi ngay lập tức api_key, secret_key và các thông tin khác để ngăn chặn tài sản của người dùng bị thiệt hại do giao dịch chéo, bảo vệ an toàn tài sản của người dùng.

Tính đến ngày 17 tháng 11, tất cả người dùng CEX bị ảnh hưởng đã hoàn tất thông báo và đã hủy các khóa liên quan, tài sản của người dùng đang ở trạng thái an toàn.

Đối với một số người dùng Aster**, Hyperliquid**, Slow Mist và đội ngũ Binance đã cố gắng liên hệ một cách chủ động, nhưng do địa chỉ là địa chỉ ví phi tập trung, chúng tôi không thể liên lạc trực tiếp với người dùng cụ thể. Nếu bạn đang sử dụng hệ thống giao dịch tự động Aster, Hyperliquid, hãy kiểm tra và xử lý kịp thời các rủi ro liên quan.

Đồng thời, chúng tôi sẽ giao tiếp với đội ngũ NOFX AI về chi tiết lỗ hổng này và cung cấp các đề xuất sửa chữa, hỗ trợ họ hoàn thiện an ninh hệ thống.

Tóm tắt và Đề xuất

Hiện nay, các dự án định lượng mô hình AI lớn đang rất phổ biến, nhưng hầu hết các phiên bản mã nguồn mở vẫn đang ở giai đoạn đầu. Khi triển khai các hệ thống mã nguồn mở mới nổi này, cần phải thực hiện kiểm toán an ninh mã nguồn đầy đủ và tăng cường các biện pháp quản lý rủi ro để tránh gây ra tổn thất tài chính.

Tổng hợp phân tích trên, dự án NOFX mặc dù đã có những nỗ lực sửa chữa, nhưng vấn đề cốt lõi vẫn chưa được giải quyết. Bất kỳ phiên bản nào của dự án NOFX được triển khai từ commit 517d0caf trở về trước (origin/main hiện vẫn dừng lại ở thế hệ này) đều ở trạng thái “không cần Authorization”, cần phải nâng cấp ngay lập tức hoặc tắt chế độ admin bằng tay.

Ngay cả khi nâng cấp lên be768d9 hoặc HEAD hiện tại, nếu tiếp tục sử dụng jwt_secret mặc định, kẻ tấn công vẫn có thể lấy được khóa bằng cách tạo một tiêu đề Authorization cố định. Để khắc phục hoàn toàn lỗ hổng này, cần phải thực hiện đồng thời các điều sau:

1. Ngẫu nhiên hóa khóa JWT: Nếu phát hiện jwt_secret giống với mẫu khi khởi động, từ chối hoạt động; nên thay đổi để ghi vào lưu trữ an toàn hoặc hệ thống quản lý khóa.

2. Vô hiệu hóa chế độ quản trị viên mặc định: chỉ cho phép chế độ admin khi được cấu hình rõ ràng và yêu cầu mật khẩu mạnh + OTP; trong chế độ không phải admin, /api/admin-login nên được đóng hoàn toàn.

3. Giảm thiểu /api/exchanges phản hồi: Mặc định chỉ trả về trạng thái kích hoạt, dấu hiệu mạng thử nghiệm và các trường không nhạy cảm khác; Xuất API/khóa riêng cần có giao diện riêng và xác thực lần hai, và máy chủ sẽ làm mờ hoặc mã hóa các trường.

Trước khi đội ngũ phát triển hoàn thành những sửa lỗi này, bất kỳ triển khai nào hướng tới mạng công cộng đều nên được coi là rất nguy hiểm. Đặc biệt là origin/main vẫn đang trong giai đoạn “không xác thực” 517d0c, bên bảo trì cần nhanh chóng đồng bộ mã mới nhất và thực hiện nghiêm ngặt chiến lược gia cố khóa tùy chỉnh và giao diện.