Trois parties côte à côte : NOFX AI Système de trading Défense contre les vulnérabilités

Auteur : Yao & Thinking & Pds Éditeur : 77

contexte

Avec la montée en puissance des compétitions de trading réel avec de grands modèles d'IA, de plus en plus de communautés et de développeurs de cryptomonnaies commencent à essayer le trading automatisé alimenté par l'IA, et de nombreuses solutions open source sont rapidement mises en œuvre. Cependant, ces projets ne sont pas sans risques de sécurité.

NOFX AI est un système de trading automatique de futures sur les cryptomonnaies open source basé sur DeepSeek/Qwen AI, prenant en charge des échanges tels que Binance, Hyperliquid et Aster DEX. L'équipe de sécurité Slow Mist a reçu des informations initiales de @Endlessss20, soupçonnant que ce système pourrait entraîner des fuites de clés API des échanges, et a donc entrepris une analyse de sécurité.

Adresse open source : https://github.com/NoFxAiOS/nofx

Analyse des causes des vulnérabilités

Après une analyse approfondie de l'équipe de sécurité de Slow Fog, il a été découvert que NOFX AI présente deux types de problèmes d'authentification principaux dans différentes versions de commit.

Version de la vulnérabilité “Zero Trust”

Le commit du 31 octobre 2025 517d0caf6fb091235e56c27889170b53a16e4e6b (qui inclut les branches origin/main, origin/dev, etc.) a introduit le “mode administrateur par défaut”, où le mode administrateur est activé par défaut et le middleware est directement autorisé.

config.json.example:1-24 et le script de migration de la base de données définissent admin_mode sur true, main.go:42-63 appelle directement auth.SetAdminMode(true) après lecture.

(Référence : https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config.json.example)

（Référencer : https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config/database.go#L214）

(Référence : https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/main.go#L42-63)

Il est encore plus crucial de noter que dans le code api/server.go#L799, on peut voir que tant que auth.IsAdminMode() est true, le middleware renvoie directement, sautant complètement la vérification de l'en-tête d'authentification.

(Référence : https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/api/server.go#L799)

Ainsi, dans ce commit et avant, tant que le déploiement reste en mode administrateur par défaut, n'importe qui peut accéder directement à /api/exchanges et obtenir toutes les clés API/privées des échanges.

Dans ce mode, toutes les API protégées par authentification, y compris /api/exchanges, s'exécutent en tant qu'“admin”, permettant ainsi à quiconque de faire une requête GET sur l'API publique pour obtenir le contenu complet de ExchangeConfig dans la base de données.

Le champ ExchangeConfig comprend api_key, secret_key, hyperliquid_wallet_addr et aster_private_key, qui sont tous des clés de connexion ou des clés privées pour l'échange. En d'autres termes, tant que le mode administrateur par défaut est maintenu, n'importe qui peut accéder directement à /api/exchanges et obtenir toutes les clés API/privées de l'échange. Ce code de commit équivaut à exposer toutes les clés d'échange sur une interface GET accessible sans connexion.

Version requise pour l'autorisation

Dans la soumission du 5 novembre 2025 be768d91a3969b39741623c9507f3119e583eb16(PR #540 “Activer le mot de passe admin en mode admin”), les développeurs ont supprimé la logique qui permettait de passer directement sans vérifier l'Authorization dès que admin_mode était détecté.

Il est à noter que ce commit se trouve actuellement uniquement dans la branche de la série dev (y compris dev local et origin/dev, etc.). origin/main ne contient pas ce commit.

authMiddleware a été réécrit sous la forme api/server.go:1471-1511 et doit inclure Authorization: Bearer pour accéder aux routes protégées. Si le format est incorrect ou si la validation JWT échoue, un retour 401 sera directement effectué.

（Référencer : https://github.com/NoFxAiOS/nofx/blob/be768d91a3969b39741623c9507f3119e583eb16/api/server.go#L1471）

La même soumission a également ajouté /api/admin-login, demandant au déployeur de définir la variable d'environnement NOFX_ADMIN_PASSWORD, c'est-à-dire que le mode administrateur n'est plus « sans connexion active ». Si admin_mode est toujours true, main.go:203-226 vérifiera la variable d'environnement NOFX_ADMIN_PASSWORD et appellera log.Fatalf pour terminer directement le processus, sauf si cette variable a été définie au préalable. Une fois la configuration terminée, l'administrateur doit soumettre ce mot de passe via la nouvelle interface /api/admin-login pour obtenir le JWT ; démarrer sans mot de passe entraînera une sortie forcée lors de la phase d'initialisation.

Cependant, ce changement ne fait que mettre à jour “sans authentification complète” en “doit fournir un JWT”, sans résoudre les deux problèmes fondamentaux.

Premièrement, config.json.example:1-27 continue d'écrire en dur jwt_secret, main.go:203-214 revient à cette chaîne publique lorsque la variable d'environnement est manquante.

Si les développeurs utilisent directement le fichier de configuration exemple, cela entraînera l'activation de la clé par défaut, ce qui présente un risque de sécurité. De plus, le script de déploiement par défaut dans le projet, le fichier start.sh, copiera directement le fichier de configuration exemple à utiliser en cas de configuration manquante.

Deuxièmement, /api/exchanges renvoie toujours les champs sensibles tels que api_key, secret_key et la clé privée Aster sous forme de JSON.

Ainsi, cette version accède à /api/exchanges nécessite une autorisation, mais un attaquant peut toujours créer un JWT avec la clé par défaut ou appeler l'interface de connexion par défaut pour obtenir un token, permettant ainsi de lire toutes les clés.

Le problème fixe de JWT dans la version actuelle persiste toujours

À ce jour (environ le 13 novembre 2025), le HEAD de la branche dev est b2e4be91523dc606be8708ec6602fecbbb0c20ea (PR #546 “Feature/faq”). L'équipe de sécurité SlowMist a vérifié cette soumission après l'avoir recheckout :

• authMiddleware est toujours l'implémentation de api/server.go:1471-1511, nécessitant un token Bearer ;
• /api/exchanges renvoie toujours ExchangeConfig directement (api/server.go:1009-1021) ;
• config.json.example:1-27 et main.go:198-226 codent toujours en dur admin_mode=true et jwt_secret par défaut.

Par conséquent, tant que le personnel opérationnel n'a pas activement changé le jwt_secret et désactivé le mode administrateur, un attaquant peut toujours utiliser la clé publique pour créer un JWT fixe, lui permettant d'accéder à /api/exchanges et d'obtenir toutes les clés API/privées des échanges. En d'autres termes, le correctif du 05-11-2025 a simplement transformé la vulnérabilité de “aucune authentification” en “authentification par clé par défaut”, le problème sous-jacent reste donc présent.

Influence

Nous avons effectué une recherche sur l'ensemble du réseau en fonction des caractéristiques du programme et avons découvert qu'il existe plus de 1000 systèmes déjà déployés en mode privé et ouverts au public :

L'équipe de sécurité de Slow Fog est consciente que des attaques peuvent survenir à tout moment, et elle envisage immédiatement des solutions de sécurité. Nous avons finalement décidé de contacter l'équipe de sécurité de Binance et l'équipe de sécurité d'OKX. Slow Fog, Binance et OKX ont établi un centre d'opérations de sécurité. Nous fournissons des informations et une portée d'impact, et les équipes de sécurité de Binance et d'OKX procèdent à des vérifications croisées de manière indépendante. En se basant sur les api_key obtenues, nous faisons des avancées inverses pour identifier les utilisateurs affectés au niveau du système, les informant des risques de sécurité auxquels ils font face, remplaçant immédiatement les api_key, secret_key et autres informations pour empêcher la perte de fonds des utilisateurs due à des transactions croisées, tout en protégeant la sécurité des actifs des utilisateurs.

À la date du 17 novembre, tous les utilisateurs de CEX concernés ont été informés et ont annulé les clés associées, les actifs des utilisateurs sont en sécurité.

Pour un petit nombre d'utilisateurs d'Aster**, Hyperliquid**, Slow Mist et l'équipe de Binance ont tenté de contacter proactivement, mais en raison de l'adresse étant une adresse de portefeuille décentralisé, nous ne pouvons pas atteindre directement les utilisateurs spécifiques. Si vous utilisez un système de trading automatisé Aster, Hyperliquid, veuillez vérifier et traiter rapidement les risques associés.

En même temps, nous communiquerons les détails de cette vulnérabilité à l'équipe NOFX AI et fournirons des recommandations de correction pour les aider à améliorer la sécurité de leur système.

Résumé et recommandations

Les projets de quantification des grands modèles d'IA sont en plein essor, mais la plupart des implémentations open source en sont encore à un stade précoce. Lors du déploiement de ces nouveaux systèmes open source émergents, il est essentiel de procéder à un audit de sécurité complet du code et de renforcer les mesures de gestion des risques pour éviter toute perte de fonds.

En résumé, bien que le projet NOFX ait tenté des réparations, les problèmes fondamentaux demeurent non résolus. Tous les commits du projet NOFX à partir de 517d0caf et les versions antérieures (origin/main est toujours bloqué à cette génération) sont dans un état de “pas d'autorisation nécessaire”, et il est impératif de les mettre à jour immédiatement ou de désactiver manuellement le mode admin.

Même après la mise à niveau vers be768d9 ou le HEAD actuel, si le jwt_secret par défaut est toujours utilisé, un attaquant peut toujours obtenir la clé en créant un en-tête Authorization fixe. Pour corriger complètement cette vulnérabilité, il est nécessaire de faire les deux choses suivantes :

1. Randomiser la clé JWT : si la clé jwt_secret est identique à celle du modèle lors du démarrage, refusez de fonctionner ; il est conseillé de l'écrire dans un stockage sécurisé ou un système de gestion des clés.

2. Désactiver le mode administrateur par défaut : autoriser le mode admin uniquement en cas de configuration explicite, et exiger un mot de passe fort + OTP ; en mode non admin, /api/admin-login doit être immédiatement désactivé.

3. Minimiser la réponse /api/exchanges : par défaut, seuls les champs non sensibles tels que l'état activé, le drapeau de test, etc., sont retournés ; l'exportation de l'API / clé privée nécessite une interface distincte et une seconde validation, et le serveur doit désensibiliser ou chiffrer les champs.

Avant que l'équipe de développement n'achève ces corrections, tout déploiement accessible au public doit être considéré comme à haut risque. En particulier, origin/main est toujours en phase “zero authentication” à 517d0c, et les mainteneurs doivent synchroniser rapidement le code le plus récent et appliquer strictement les stratégies de renforcement des clés personnalisées et des interfaces.