Três lados lado a lado: Batalha de defesa contra vulnerabilidades do sistema de negociação NOFX AI

Autor: Yao & Thinking & Pds Editor: 77

fundo

Com o aumento da competição de negociação em tempo real com grandes modelos de IA, cada vez mais comunidades e desenvolvedores de criptomoedas estão começando a experimentar negociação automatizada impulsionada por IA, e várias soluções de código aberto também estão sendo rapidamente utilizadas. No entanto, não faltam riscos de segurança nesses projetos.

NOFX AI é um sistema de negociação automática de futuros de criptomoeda de código aberto baseado em DeepSeek/Qwen AI, que suporta exchanges como Binance, Hyperliquid e Aster DEX. A equipe de segurança SlowMist recebeu a informação inicial fornecida por @Endlessss20 e suspeita que este sistema possa levar ao vazamento de chaves de API de exchanges, levando assim a uma análise de segurança.

Endereço de código aberto: https://github.com/NoFxAiOS/nofx

Análise das causas das vulnerabilidades

Após uma análise aprofundada da equipa de segurança da Slow Mist, foi descoberto que o NOFX AI apresenta dois tipos principais de problemas de autenticação em diferentes versões de commit.

Versão de vulnerabilidade “Zero Trust”

A submissão de 31 de outubro de 2025, 517d0caf6fb091235e56c27889170b53a16e4e6b (incluindo ramos como origin/main, origin/dev, etc.) introduziu o “modo de administrador padrão”, onde o modo de administrador da versão do commit está ativado por padrão e o middleware permite o acesso diretamente.

config.json.example:1-24 e o script de migração do banco de dados definem admin_mode como true, main.go:42-63 chama diretamente auth.SetAdminMode(true) após a leitura.

（Referência:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config.json.example）

（Refer:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config/database.go#L214）

（Referência:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/main.go#L42-63）

É ainda mais crucial que, no código api/server.go#L799, pode-se ver que, desde que auth.IsAdminMode() seja verdadeiro, o middleware retornará diretamente, pulando completamente a verificação do cabeçalho de autenticação.

（Refer:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/api/server.go#L799）

Portanto, neste commit e antes, desde que a implantação mantenha o modo de administrador padrão, qualquer pessoa pode acessar diretamente /api/exchanges e obter todas as chaves API/privadas das exchanges.

Nesse modo, todas as APIs protegidas por autenticação, incluindo /api/exchanges, serão executadas com a identidade de “admin”, portanto, qualquer pessoa pode simplesmente fazer uma solicitação GET à API pública para obter o conteúdo completo do ExchangeConfig no banco de dados.

Os campos ExchangeConfig incluem api_key, secret_key, hyperliquid_wallet_addr e aster_private_key, todos são chaves ou chaves privadas para login na exchange. Ou seja, enquanto o modo administrador padrão for mantido, qualquer pessoa pode acessar diretamente /api/exchanges e obter todas as chaves API/privadas da exchange. Este código de commit equivale a expor todas as chaves da exchange em uma interface GET que não requer login.

Versão de autorização requerida

Na submissão de 5 de novembro de 2025 be768d91a3969b39741623c9507f3119e583eb16(PR #540 “Ativar senha de administrador no modo administrador”), o desenvolvedor removeu a lógica anterior que permitia o acesso sem verificar a autorização assim que o admin_mode era detectado.

É importante notar que este commit atualmente está apenas na série de ramificações dev (incluindo dev local e origin/dev, etc.). origin/main não contém este commit.

authMiddleware foi reescrito para a forma api/server.go:1471-1511, devendo incluir Authorization: Bearer para acessar rotas protegidas. Se o formato estiver incorreto ou a validação JWT falhar, retornará diretamente 401.

（Refer:https://github.com/NoFxAiOS/nofx/blob/be768d91a3969b39741623c9507f3119e583eb16/api/server.go#L1471）

A mesma submissão também adicionou /api/admin-login, exigindo que o implantador configure a variável de ambiente NOFX_ADMIN_PASSWORD, o que significa que o modo administrador não é mais “sem necessidade de login para ativar automaticamente”. Se admin_mode ainda for true, main.go:203-226 verificará a variável de ambiente NOFX_ADMIN_PASSWORD e chamará log.Fatalf para terminar o processo diretamente, a menos que essa variável tenha sido configurada previamente. Após a configuração, o administrador deve enviar essa senha através da nova interface /api/admin-login para obter o JWT; se a senha não for configurada e o sistema for iniciado, será forçado a sair na fase de inicialização.

No entanto, esta mudança apenas atualizou “sem autenticação total” para “é necessário fornecer JWT”, sem resolver os dois problemas centrais.

Primeiro, config.json.example:1-27 continua a ter o jwt_secret fixo, main.go:203-214 quando a variável de ambiente está em falta, ainda recua para essa string pública.

Se os desenvolvedores usarem diretamente o arquivo de configuração de exemplo, a chave padrão será ativada, o que representa um risco de segurança. O script de implantação padrão no projeto, o arquivo start.sh, ao detectar configurações ausentes, copiará diretamente o arquivo de configuração de exemplo para uso.

Em segundo lugar, /api/exchanges ainda retorna os campos sensíveis, como api_key, secret_key e a chave privada Aster, na forma JSON.

Portanto, esta versão acessa /api/exchanges e requer autorização, mas um atacante ainda pode criar um JWT usando a chave padrão ou chamar a interface de login padrão para obter um token, permitindo ler todas as chaves.

O problema fixo do JWT na versão atual ainda existe

Até o momento (cerca de 13 de novembro de 2025), o HEAD do branch dev é b2e4be91523dc606be8708ec6602fecbbb0c20ea (PR #546 “Feature/faq”). A equipe de segurança da Slow Mist revisitou este commit e verificou que:

• authMiddleware é a implementação em api/server.go:1471-1511, requer um token Bearer;
• /api/exchanges ainda retorna diretamente ExchangeConfig (api/server.go:1009-1021);
• config.json.example:1-27 e main.go:198-226 ainda têm codificação fixa admin_mode=true e jwt_secret padrão.

Portanto, desde que os operadores de manutenção não mudem ativamente o jwt_secret e desativem o modo administrador, os atacantes ainda podem usar a chave pública para criar um JWT fixo, permitindo o acesso a /api/exchanges e obter todas as chaves API/privadas das exchanges. Em outras palavras, a correção de 2025-11-05 apenas transformou a vulnerabilidade de “zero autenticação” para “autenticação com chave padrão”, e a raiz do problema ainda persiste.

Impacto

Nós realizamos uma pesquisa na rede com base nas características do programa e descobrimos que existem mais de 1000 sistemas que foram implantados de forma privada e estão abertos ao público:

A equipe de segurança da Slow Mist está ciente de que ataques podem ocorrer a qualquer momento e, assim, considerou imediatamente um plano de segurança. Finalmente, decidimos entrar em contato com a equipe de segurança da Binance e a equipe de segurança da OKX. A Slow Mist, junto com a Binance e a OKX, formou um centro de operações de segurança. Nós fornecemos informações e o alcance do impacto, e as equipes de segurança da Binance e da OKX validam de forma independente e cruzada. Com base na api_key obtida, avançamos de forma reversa, localizando os usuários afetados a partir do sistema, informando-os sobre os riscos de segurança que enfrentam, e na primeira oportunidade, trocamos a api_key, secret_key e outras informações, para evitar que os ativos dos usuários sejam perdidos devido a negociações cruzadas, protegendo assim a segurança dos ativos dos usuários.

Até 17 de novembro, todos os usuários afetados da CEX foram notificados e as chaves relacionadas foram descartadas, os ativos dos usuários estão em estado seguro.

Para alguns poucos usuários da Aster** e Hyperliquid**, a SlowMist e a equipe da Binance tentaram entrar em contato proativamente, mas como o endereço é um endereço de carteira descentralizada, não conseguimos entrar em contato diretamente com os usuários específicos. Se você estiver usando o sistema de negociação automatizada da Aster ou Hyperliquid, verifique e trate os riscos relevantes a tempo.

Ao mesmo tempo, iremos comunicar à equipe da NOFX AI os detalhes desta vulnerabilidade e fornecer sugestões de correção, ajudando-os a melhorar a segurança do sistema.

Resumo e Sugestões

Atualmente, os projetos de quantização de grandes modelos de IA estão em alta, mas a maioria das implementações de código aberto ainda está em estágio inicial. Ao implantar esses novos sistemas de código aberto, é essencial realizar uma auditoria de segurança de código adequada e reforçar as medidas de controle de riscos, a fim de evitar perdas financeiras.

Com base na análise acima, embora o projeto NOFX tenha tentado ser corrigido, o problema central ainda não foi resolvido. Qualquer commit do projeto NOFX 517d0caf ou versões anteriores (a origin/main ainda está nesta versão) está em estado de “sem necessidade de autorização”, devendo ser atualizado imediatamente ou o modo admin deve ser desativado manualmente.

Mesmo atualizando para be768d9 ou o HEAD atual, se continuar a usar o jwt_secret padrão, um atacante ainda poderá obter a chave criando um cabeçalho de autorização fixo. Para corrigir completamente essa vulnerabilidade, é necessário fazer o seguinte:

1. Aleatorizar a chave JWT: Se ao iniciar for encontrada a mesma jwt_secret que o modelo, recuse a execução; recomenda-se alterar para gravar em armazenamento seguro ou sistema de gestão de chaves.

2. Desativar o modo de administrador padrão: permitir o modo admin apenas quando configurado explicitamente e exigir uma senha forte + OTP; o /api/admin-login deve ser fechado diretamente no modo não admin.

3. Minimizar a resposta /api/exchanges: por padrão, retorna apenas campos não sensíveis como o estado de ativação e a marca de rede de testes; a exportação de API/chaves privadas deve ter uma interface separada e uma segunda verificação, e o servidor deve desensibilizar ou criptografar os campos.

Antes que a equipe de desenvolvimento conclua essas correções, qualquer implantação voltada para a Internet deve ser considerada de alto risco. Especialmente porque o origin/main ainda está na fase de “zero autenticação” em 517d0c, os responsáveis pela manutenção devem sincronizar o código mais recente o mais rápido possível e aplicar rigorosamente as políticas de reforço de chaves personalizadas e interfaces.