Tres partes codo a codo: NOFX AI defensa contra vulnerabilidades del sistema de trading

Autor: Yao & Thinking & Pds Editado por: 77

fondo

Con el aumento de las competiciones de trading en tiempo real con grandes modelos de IA, cada vez más comunidades y desarrolladores de criptomonedas están comenzando a probar el trading automatizado impulsado por IA, y muchas soluciones de código abierto se están utilizando rápidamente. Sin embargo, no faltan los riesgos de seguridad en estos proyectos.

NOFX AI es un sistema automatizado de comercio de futuros de criptomonedas de código abierto basado en DeepSeek/Qwen AI, que soporta intercambios como Binance, Hyperliquid y Aster DEX. El equipo de seguridad SlowMist recibió la información inicial proporcionada por @Endlessss20, sospechando que este sistema podría provocar filtraciones de claves API de los intercambios, por lo que se llevó a cabo un análisis de seguridad.

Dirección de código abierto: https://github.com/NoFxAiOS/nofx

Análisis de causas de vulnerabilidades

Después de un análisis exhaustivo por parte del equipo de seguridad de Slow Fog, se descubrió que NOFX AI presenta dos tipos principales de problemas de autenticación en diferentes versiones de commit.

Versión de vulnerabilidad “Zero Authentication”

La entrega del 31 de octubre de 2025, 517d0caf6fb091235e56c27889170b53a16e4e6b (incluyendo ramas como origin/main, origin/dev, etc.) introdujo el “modo administrador por defecto”, donde el modo administrador de esta versión de commit está habilitado por defecto y el middleware se permite directamente.

config.json.example:1-24 y el script de migración de la base de datos establecen admin_mode en true, main.go:42-63 llama directamente a auth.SetAdminMode(true) después de leer.

(Referencia:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/config.json.example)

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

（Referirse a:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/main.go#L42-63）

Lo más importante es que en el código api/server.go#L799 se puede ver que, siempre que auth.IsAdminMode() sea true, el middleware retornará directamente, omitiendo por completo la verificación del encabezado de autorización.

(Referencia:https://github.com/NoFxAiOS/nofx/blob/517d0caf6fb091235e56c27889170b53a16e4e6b/api/server.go#L799)

Por lo tanto, en este commit y en los anteriores, siempre que el despliegue mantenga el modo de administrador predeterminado, cualquier persona podrá acceder directamente a /api/exchanges y obtener todas las API/llaves privadas de los exchanges.

En este modo, todas las API protegidas por autenticación, incluyendo /api/exchanges, se ejecutarán con la identidad de “admin”, por lo que cualquier persona solo necesita realizar una solicitud GET a la API pública para obtener el contenido completo de ExchangeConfig en la base de datos.

El campo ExchangeConfig incluye api_key, secret_key, hyperliquid_wallet_addr y aster_private_key, que son las claves de acceso o claves privadas del intercambio. Es decir, siempre que se mantenga el modo administrador predeterminado, cualquier persona puede acceder directamente a /api/exchanges y obtener todas las API/claves privadas del intercambio. Este código de commit equivale a exponer todas las claves del intercambio en una interfaz GET que no requiere inicio de sesión.

Versión de autorización requerida

En la presentación del 5 de noviembre de 2025, be768d91a3969b39741623c9507f3119e583eb16( PR #540 “Habilitar la contraseña de administrador en el modo administrador” ), los desarrolladores eliminaron la lógica que anteriormente permitía el acceso sin verificar la autorización al detectar admin_mode.

Es importante tener en cuenta que este commit actualmente solo está en la serie de ramas dev (incluyendo dev local y origin/dev, etc.). origin/main no incluye este commit.

authMiddleware ha sido reescrito en la forma de api/server.go:1471-1511, debe llevar Authorization: Bearer para poder acceder a rutas protegidas. Si el formato es incorrecto o la verificación de JWT falla, se devolverá directamente un 401.

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

La misma提交 también agregó /api/admin-login, que requiere que el implementador establezca la variable de entorno NOFX_ADMIN_PASSWORD, es decir, el modo administrador ya no es “sin inicio de sesión automático”. Si admin_mode sigue siendo true, main.go:203-226 verificará la variable de entorno NOFX_ADMIN_PASSWORD y llamará a log.Fatalf para terminar el proceso directamente, a menos que se haya establecido previamente esa variable. Una vez configurado, el administrador debe enviar esta contraseña a través de la nueva interfaz /api/admin-login para obtener el JWT; si se inicia sin establecer una contraseña, será forzado a salir en la fase de inicialización.

Sin embargo, este cambio solo actualiza “sin autenticación completa” a “se debe proporcionar JWT”, y aún no resuelve los dos problemas centrales.

Uno es config.json.example:1-27 que sigue escribiendo jwt_secret, main.go:203-214 que vuelve a ese string público cuando faltan las variables de entorno.

Si los desarrolladores utilizan directamente el archivo de configuración de ejemplo, se habilitará la clave predeterminada, lo que conlleva un riesgo de seguridad. Además, el archivo de script de implementación predeterminado start.sh en el proyecto, al detectar la falta de configuración, copiará directamente el archivo de configuración de ejemplo para su uso.

En segundo lugar, /api/exchanges todavía devuelve en formato JSON los campos sensibles como api_key, secret_key y la clave privada de Aster tal como están.

Por lo tanto, esta versión accede a /api/exchanges aunque necesite autorización, pero un atacante aún puede crear un JWT mediante la clave predeterminada o llamar a la interfaz de inicio de sesión predeterminada para obtener un token, lo que le permite leer todas las claves.

El problema fijo de JWT en la versión actual sigue existiendo

Hasta ahora (alrededor del 13 de noviembre de 2025), el HEAD de la rama dev es b2e4be91523dc606be8708ec6602fecbbb0c20ea (PR #546 “Feature/faq”). El equipo de seguridad de Slow Fog revisó esta confirmación después de volver a hacer checkout y encontró lo siguiente:

• authMiddleware sigue siendo la implementación de api/server.go:1471-1511, necesita un token Bearer;
• /api/exchanges sigue devolviendo directamente ExchangeConfig (api/server.go:1009-1021);
• config.json.example:1-27 y main.go:198-226 siguen codificados de forma rígida admin_mode=true y el jwt_secret por defecto.

Por lo tanto, mientras el personal de operaciones no cambie activamente el jwt_secret y cierre el modo administrador, los atacantes aún pueden utilizar la clave pública para crear un JWT fijo y, así, acceder a /api/exchanges y obtener todas las claves API/privadas de los intercambios. En otras palabras, la solución del 2025-11-05 simplemente transformó la vulnerabilidad de “sin autenticación” a “autenticación con clave predeterminada”, y la raíz del problema sigue existiendo.

influencia

****Según las características del programa, hemos realizado una búsqueda en toda la red y hemos encontrado más de 1000 sistemas que ya han sido desplegados de manera privada y están abiertos al público: ****

El equipo de seguridad de Slow Fog se dio cuenta de que podría haber un ataque en cualquier momento, por lo que consideró de inmediato un plan de seguridad. Finalmente, decidimos contactar al equipo de seguridad de Binance y al equipo de seguridad de OKX. Slow Fog, Binance y OKX establecieron una sala de guerra de seguridad. Proporcionamos inteligencia y el alcance del impacto, y los equipos de seguridad de Binance y OKX validaron de manera independiente y cruzada. Con base en la api_key obtenida, retrocedimos para identificar a los usuarios afectados a nivel del sistema, informando a los usuarios sobre los riesgos de seguridad que enfrentan. En el primer momento, cambiamos la api_key, secret_key y otra información para evitar que los activos de los usuarios se vean afectados por operaciones de contraparte, protegiendo así la seguridad de los activos de los usuarios.

Hasta el 17 de noviembre, todos los usuarios de CEX afectados han sido notificados y han revocado las claves relacionadas, los activos de los usuarios están en estado seguro.

Para un número limitado de usuarios de Aster**, Hyperliquid**, Slow Mist y el equipo de Binance han intentado contactar de manera proactiva, pero debido a que la dirección es una dirección de billetera descentralizada, no podemos comunicarnos directamente con usuarios específicos. Si está utilizando un sistema de comercio automatizado de Aster o Hyperliquid, verifique y maneje los riesgos relacionados a tiempo.

Al mismo tiempo, nos comunicaremos con el equipo de NOFX AI sobre los detalles de esta vulnerabilidad y proporcionaremos sugerencias de reparación para ayudar a mejorar la seguridad del sistema.

Resumen y Sugerencias

Los proyectos de cuantificación de grandes modelos de IA están en auge, pero la mayoría de las implementaciones de código abierto aún se encuentran en una etapa temprana. Al implementar estos nuevos sistemas de código abierto, es esencial realizar una auditoría de seguridad del código adecuada y fortalecer las medidas de control de riesgos para evitar pérdidas de fondos.

A partir del análisis anterior, aunque el proyecto NOFX ha intentado repararse, los problemas centrales aún no se han resuelto. Cualquier implementación del proyecto NOFX con el commit 517d0caf y versiones anteriores (origin/main aún se encuentra en esta versión) está en estado de “sin autorización”, y debe actualizarse de inmediato o cerrar manualmente el modo administrador.

Incluso si se actualiza a be768d9 o al HEAD actual, si se sigue utilizando el jwt_secret por defecto, un atacante aún puede obtener la clave creando un encabezado de Autorización fijo. Para corregir completamente esta vulnerabilidad, es necesario hacer lo siguiente:

1. Aleatorizar la clave JWT: Si al iniciar se encuentra que jwt_secret es igual al de la plantilla, se debe rechazar la ejecución; se recomienda escribirlo en un almacenamiento seguro o en un sistema de gestión de claves.

2. Desactivar el modo administrador predeterminado: permitir el modo admin solo cuando se configure explícitamente y requerir una contraseña fuerte + OTP; en modo no admin, /api/admin-login debe estar cerrado directamente.

3. Minimizar la respuesta de /api/exchanges: por defecto solo devuelve campos no sensibles como el estado habilitado, la bandera de red de prueba, etc.; la exportación de API/clave privada requiere una interfaz separada y una segunda verificación, y el servidor desensibiliza o cifra los campos.

Antes de que el equipo de desarrollo complete estas correcciones, cualquier implementación orientada al público debe considerarse de alto riesgo. Especialmente porque origin/main todavía se encuentra en la fase de “cero autenticación” 517d0c, el equipo de mantenimiento debe sincronizar el código más reciente lo antes posible y aplicar estrictamente las estrategias de refuerzo de claves personalizadas e interfaces.