Три сторони пліч-о-пліч: Бої за захист вразливостей торгової системи NOFX AI

Автор: Yao & Thinking & Pds Редактор: 77

фон

З ростом конкуренції у торгівлі на реальних рахунках з використанням великих моделей ШІ, все більше криптоспільнот та розробників починають намагатися використовувати автоматизовану торгівлю, керовану ШІ; багато відкритих рішень також швидко впроваджуються. Проте, у цих проектах не бракує проблем із безпекою.

!

NOFX AI є відкритою системою автоматичної торгівлі ф'ючерсами на криптовалюту, що базується на DeepSeek/Qwen AI, яка підтримує такі біржі, як Binance, Hyperliquid та Aster DEX. Команда безпеки SlowMist отримала первинну інформацію від @Endlessss20 та підозрює, що ця система може призвести до витоку таких даних, як API Key біржі, тому було розпочато безпековий аналіз.

Адреса з відкритим джерелом: https://github.com/NoFxAiOS/nofx

Аналіз причин вразливостей

Після детального аналізу команди безпеки Slow Mist було виявлено, що NOFX AI має дві основні проблеми з автентифікацією у різних версіях коммітів.

“Нульова авторизація” уразливість версії

Подання від 31 жовтня 2025 року 517d0caf6fb091235e56c27889170b53a16e4e6b (включає такі гілки, як origin/main, origin/dev тощо) впровадило “режим за замовчуванням адміністратора”, в якому режим адміністратора за замовчуванням увімкнено, а посередник безпосередньо пропускає.

config.json.example:1-24 та скрипти міграції бази даних встановлюють admin_mode на true, main.go:42-63 після читання безпосередньо викликає auth.SetAdminMode(true).

!

(Посилання:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config.json.example)

!

(Посилання:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config/database.go#L214)

!

(Посилання:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/main.go#L42-63)

Більш важливо, що в коді api/server.go#L799 можна побачити, що якщо auth.IsAdminMode() дорівнює true, посередник відразу повертає результат, повністю пропускаючи перевірку заголовка авторизації.

!

(Посилання:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/api/server.go#L799)

Отже, в цьому коміті та раніше, якщо деплой залишався в режимі за замовчуванням адміністратора, будь-хто міг безпосередньо отримати доступ до /api/exchanges і отримати всі API/приватні ключі бірж.

У цьому режимі всі API, захищені авторизацією, включаючи /api/exchanges, виконуються від імені “admin”, тому будь-хто може просто надіслати GET запит до відкритого API та отримати повний вміст ExchangeConfig з бази даних.

Поля ExchangeConfig включають api_key, secret_key, hyperliquid_wallet_addr та aster_private_key, які є ключами або приватними ключами для входу на біржу. Іншими словами, якщо залишити режим адміністратора за замовчуванням, будь-хто може безпосередньо отримати доступ до /api/exchanges і отримати всі API/приватні ключі біржі. Цей код коміту фактично відкриває всі ключі біржі на GET інтерфейсі, що не вимагає входу.

!

Версія авторизації

У поданні від 5 листопада 2025 року be768d91a3969b39741623c9507f3119e583eb16(PR #540 “Увімкнути пароль адміністратора в адміністративному режимі”) розробник видалив початкову логіку, за якою просто, виявивши admin_mode, пропускалося без перевірки Authorization.

Слід зазначити, що цей коміт наразі є лише в серії гілок dev (включаючи локальний dev та origin/dev тощо). origin/main не містить цього коміту.

authMiddleware був переписаний у вигляді api/server.go:1471-1511, і він повинен містити Authorization: Bearer , щоб отримати доступ до захищених маршрутів. Якщо формат неправильний або перевірка JWT не вдалася, буде безпосередньо повернено 401.

!

(Посилання:https://github.com/NoFxAiOS/nofx/blob/be768d91a3969b39741623c9507f3119e583eb16/api/server.go#L1471)****

Те ж подання також додало /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 все ще повертає чутливі поля, такі як api_key, secret_key, приватний ключ Aster у форматі JSON.

Тому, хоча для доступу до /api/exchanges потрібна авторизація, зловмисник все ще може створити JWT за допомогою ключа за замовчуванням або викликати стандартний інтерфейс входу для отримання токена, що дозволяє читати всі ключі.

!

Проблема з фіксованим JWT у поточній версії все ще існує

Станом на зараз (приблизно 13 листопада 2025 року), HEAD гілки dev є b2e4be91523dc606be8708ec6602fecbbb0c20ea (PR #546 “Feature/faq”). Команда безпеки SlowMist повторно перевірила цю коміт і виявила:

• authMiddleware залишається реалізацією api/server.go:1471-1511, потребує Bearer токена;
• /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 приватизованих систем, які відкриті для зовнішнього доступу:

!

!

Команда безпеки Slow Mist усвідомлює, що в будь-який момент може виникнути ситуація атаки, тому ми перш за все розглянули всі варіанти безпеки. Врешті-решт, ми вирішили зв’язатися з командою безпеки Binance та командою безпеки OKX, Slow Mist разом з Binance та OKX створили оперативний центр безпеки. Ми надаємо розвідувальну інформацію та масштаби впливу, команди безпеки Binance та OKX незалежно проводять перехресну перевірку, просуваючись назад за отриманим api_key, з системного рівня визначаючи постраждалих користувачів, повідомляючи користувачів про ризики безпеки, в найкоротші терміни змінюючи api_key, secret_key та іншу інформацію, щоб запобігти втраті активів користувачів внаслідок арбітражу, захищаючи безпеку активів користувачів.

Станом на 17 листопада всі постраждалі користувачі CEX отримали повідомлення та скасували відповідні ключі, активи користувачів знаходяться в безпечному стані.

Для деяких користувачів Aster** та Hyperliquid** команда SlowMist спільно з командою Binance намагалася зв'язатися, але через те, що адреса є адресою децентралізованого гаманця, ми не можемо безпосередньо зв'язатися з конкретними користувачами. Якщо ви використовуєте автоматизовану торгову систему Aster або Hyperliquid, будь ласка, своєчасно перевірте та обробіть відповідні ризики.

Одночасно ми зв'яжемося з командою NOFX AI для обговорення деталей цього вразливості та надамо рекомендації щодо виправлення, щоб допомогти їм покращити безпеку системи.

Підсумок та рекомендації

Сьогодні проекти з кількісного аналізу великих AI-моделей користуються популярністю, але більшість відкритих реалізацій все ще знаходяться на ранній стадії. При впровадженні таких нових відкритих систем обов'язково слід провести ретельний аудит безпеки коду та посилити заходи управління ризиками, щоб уникнути фінансових втрат.

Виходячи з вищезазначеного аналізу, проект NOFX, хоча і намагався виправити ситуацію, але основна проблема залишається невирішеною. Будь-яке впровадження проекту NOFX з комітом 517d0caf та більш ранніми версіями (origin/main наразі все ще знаходиться на цьому етапі) перебуває в стані “без необхідності авторизації”, і потрібно терміново оновити або вручну вимкнути режим адміністратора.

Навіть якщо оновитися до be768d9 або поточного HEAD, якщо продовжити використовувати за замовчуванням jwt_secret, зловмисник все ще може отримати ключ, створивши фіксований заголовок Authorization. Щоб повністю виправити цю вразливість, необхідно одночасно виконати наступні умови:

1. Випадкове генерування JWT ключа: якщо під час запуску виявлено, що jwt_secret однаковий з шаблоном, відмовитись від виконання; рекомендується записати його в безпечне сховище або систему управління ключами.

2. Вимкнення режиму адміністратора за замовчуванням: режим адміністратора дозволяється лише при явній конфігурації, з вимогою використання складного пароля + OTP; в режимі, що не є адміністративним, /api/admin-login має бути повністю вимкнено.

3. Мінімізація /api/exchanges відповіді: за замовчуванням повертаються лише поля ненадійного статусу, тестовий прапорець та інші не чутливі поля; експорт API/приватного ключа має здійснюватися через окремий інтерфейс з повторною перевіркою, а сервер має обробляти поля, щоб видалити чутливу інформацію або зашифрувати їх.

Перед завершенням цих виправлень командою розробників будь-яке розгортання, орієнтоване на публічну мережу, слід вважати високим ризиком. Особливо оскільки origin/main все ще перебуває на етапі “нульової автентифікації” 517d0c, відповідальні за підтримку повинні якнайшвидше синхронізувати останній код і суворо дотримуватися стратегії зміцнення користувацьких ключів та інтерфейсів.