Тройной фронт: Битва за защиту уязвимостей системы торговли NOFX AI

2025-11-17 12:03:09

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

Фон

С ростом популярности соревнований по реальной торговле с использованием крупных моделей AI, все больше крипто-сообществ и разработчиков начинают пробовать автоматизированную торговлю на основе AI, многие открытые решения также быстро начинают использоваться. Однако среди этих проектов немало угроз безопасности.

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

Адрес из источников информации: https://github.com/NoFxAiOS/nofx

Анализ причин уязвимости

После глубокого анализа команды безопасности Slow Fog было обнаружено, что NOFX AI имеет две основные проблемы с аутентификацией в разных версиях commit.

«Уязвимая версия без проверки»

Коммит от 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, промежуточное ПО сразу возвращает, полностью пропуская проверку заголовка аутентификации Authorization.

(Ссылка: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”). Команда безопасности Slow Mist после повторного checkout этого коммита подтвердила:

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 для обсуждения деталей уязвимости и предоставим рекомендации по исправлению, чтобы помочь им улучшить безопасность системы.

Итоги и рекомендации

В настоящее время проекты по количественной оценке крупных моделей ИИ становятся популярными, но большинство открытых реализаций все еще находятся на ранних стадиях. При развертывании таких новых открытых систем обязательно необходимо сначала провести тщательный аудит безопасности кода и усилить меры по управлению рисками, чтобы избежать потерь средств.

С учетом вышеизложенного анализа, проект NOFX, несмотря на попытки исправления, все еще не решил основные проблемы. Любые развертывания проекта NOFX, начиная с коммита 517d0caf и более ранних версий (origin/main в настоящее время все еще находится на этом уровне), находятся в состоянии «не требуется авторизация», и их необходимо немедленно обновить или вручную отключить режим администратора.

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

Случайная генерация JWT-ключа: если при запуске обнаруживается, что jwt_secret совпадает с шаблоном, отказать в выполнении; рекомендуется записать в безопасное хранилище или систему управления ключами.
Отключите режим администратора по умолчанию: разрешите режим admin только при явной настройке и требуйте сложный пароль + OTP; в режиме, отличном от admin, /api/admin-login должен быть полностью отключен.
Минимизация /api/exchanges ответа: по умолчанию возвращаются только поля ненасытного статуса, флага тестовой сети и другие не чувствительные поля; экспорт API/приватного ключа требует отдельного интерфейса и вторичной проверки, а сервер обрабатывает поля с применением десенсибилизации или шифрования.

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

Посмотреть Оригинал

На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .