ثلاثة أطراف متقاربة: معركة حراسة ثغرات نظام تداول NOFX AI

المؤلف: Yao & Thinking & Pds المحرر: 77

الخلفية

مع ارتفاع درجة حرارة المنافسة في تداول النماذج الكبيرة المدعومة بالذكاء الاصطناعي، بدأ المزيد من مجتمعات التشفير والمطورين في محاولة تنفيذ التداول الآلي المدفوع بالذكاء الاصطناعي، وتم استخدام العديد من الحلول المفتوحة المصدر بسرعة. ومع ذلك، ليست جميع هذه المشاريع خالية من مخاطر الأمان.

!

NOFX AI هو نظام تداول تلقائي مفتوح المصدر لمستقبلات العملات المشفرة يعتمد على DeepSeek/Qwen AI، ويدعم منصات مثل Binance وHyperliquid وAster DEX. تلقى فريق SlowMist الأمني المعلومات الأولية من @Endlessss20، ويشتبه في أن هذا النظام قد يؤدي إلى تسرب مفاتيح API الخاصة بالبورصات، لذا بدأوا في تحليل الأمان.

عنوان المصدر المفتوح：https://github.com/NoFxAiOS/nofx

تحليل أسباب الثغرات

بعد تحليل متعمق من فريق أمان Slow Mist، تم اكتشاف وجود نوعين رئيسيين من مشاكل المصادقة في إصدارات commit المختلفة لـ 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/exchanges بوصف “مسؤول”، لذلك يمكن لأي شخص ببساطة إجراء طلب GET إلى واجهة برمجة التطبيقات العامة للحصول على المحتوى الكامل لـ ExchangeConfig في قاعدة البيانات.

تشمل حقول ExchangeConfig api_key و secret_key و hyperliquid_wallet_addr و aster_private_key، جميعها مفاتيح تسجيل دخول أو مفاتيح خاصة للبورصة. بمعنى آخر، طالما أن وضع المسؤول الافتراضي محفوظ، يمكن لأي شخص الوصول مباشرة إلى /api/exchanges والحصول على جميع مفاتيح API/الخصوصية للبورصة. هذا الكود في هذا الالتزام يعادل تعريض جميع مفاتيح البورصة على واجهة GET لا تتطلب تسجيل الدخول.

!

نسخة التفويض المطلوبة

في التقديم بتاريخ 5 نوفمبر 2025 be768d91a3969b39741623c9507f3119e583eb16(PR #540 “تفعيل كلمة مرور المسؤول في وضع الإدارة”) ، أزال المطورون المنطق السابق الذي كان يقوم بإطلاق الوصول دون التحقق من التفويض بمجرد اكتشاف admin_mode.

يجب الانتباه إلى أن هذا الالتزام موجود فقط في سلسلة فروع 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 private key بنفس الشكل بصيغة JSON.

لذلك، يتطلب الوصول إلى /api/exchanges في هذا الإصدار تفويضًا، ولكن يمكن للمهاجمين لا يزالون إنشاء JWT باستخدام المفتاح الافتراضي أو استدعاء واجهة تسجيل الدخول الافتراضية للحصول على رمز، مما يسمح لهم بقراءة جميع المفاتيح.

!

مشكلة JWT الثابتة في الإصدار الحالي لا تزال موجودة

حتى الآن (حوالي 13 نوفمبر 2025) ، يُعتبر HEAD لفرع dev هو b2e4be91523dc606be8708ec6602fecbbb0c20ea (PR #546 “Feature/faq”). بعد أن أعادت فريق أمن Slow Mist التحقق من هذا الالتزام ، وجدوا ما يلي:

• authMiddleware لا يزال هو التنفيذ في api/server.go:1471-1511، يحتاج إلى Bearer token؛
• /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 نظام تم نشره بشكل خاص ومفتوح للجمهور على الشبكة العامة:

!

!

أدرك فريق SlowMist الأمني أنه قد تحدث هجمات في أي وقت، وقررنا على الفور وضع خطة أمنية شاملة. في النهاية، قررنا الاتصال بفريق الأمن في Binance وفريق الأمن في OKX. أنشأت SlowMist غرفة عمليات أمنية بالتعاون مع Binance و OKX. نحن نقدم المعلومات ونطاق التأثير، بينما يقوم كل من فريق الأمن في Binance وفريق الأمن في OKX بالتحقق بشكل مستقل ومتبادل. بناءً على api_key الذي تم الحصول عليه، نعمل على تحديد المستخدمين المتأثرين من مستوى النظام، وإبلاغ المستخدمين بالمخاطر الأمنية التي يواجهونها، واستبدال api_key و secret_key وغيرها من المعلومات في أسرع وقت ممكن، لمنع خسائر الأصول الناتجة عن التلاعب، وحماية أصول المستخدمين.

حتى 17 نوفمبر، تم إبلاغ جميع مستخدمي CEX المتأثرين وتم إلغاء المفاتيح ذات الصلة، وأصبحت أصول المستخدمين في حالة أمان.

بالنسبة لقلة من مستخدمي Aster** و Hyperliquid**، حاولت فرق Slow Fog وفريق Binance الاتصال بشكل نشط، ولكن نظرًا لأن العناوين هي عناوين محافظ لامركزية، لم نتمكن من الوصول مباشرة إلى المستخدمين المحددين. إذا كنت تستخدم نظام التداول الآلي لـ Aster أو Hyperliquid، يرجى التحقق بسرعة ومعالجة المخاطر ذات الصلة.

في الوقت نفسه، سنتواصل مع فريق NOFX AI لمناقشة تفاصيل الثغرة هذه، وسنقدم اقتراحات للإصلاح، وسنساعدهم في تحسين أمان النظام.

ملخص وتوصيات

في الوقت الحالي، فإن مشاريع النماذج الكبيرة للذكاء الاصطناعي في مجال الكوانت هي في ذروتها، لكن معظم التطبيقات مفتوحة المصدر لا تزال في مراحلها المبكرة. عند نشر مثل هذه الأنظمة المفتوحة المصدر الناشئة، من الضروري إجراء تدقيق شامل لأمان الشفرات وتعزيز تدابير إدارة المخاطر لتجنب فقدان الأموال.

بناءً على التحليل أعلاه، على الرغم من محاولات الإصلاح لمشروع NOFX، إلا أن المشكلة الأساسية لا تزال غير محلولة. أي نشر لمشروع NOFX ب commit 517d0caf وإصدارات أقدم (حاليًا لا يزال origin/main متوقفًا عند هذا الجيل) في حالة “لا حاجة للتفويض”، ويجب الترقية على الفور أو إغلاق وضع المسؤول يدويًا.

حتى مع الترقية إلى be768d9 أو HEAD الحالي، إذا استمر استخدام jwt_secret الافتراضي، يمكن للمهاجمين الحصول على المفتاح من خلال إنشاء رأس Authorization ثابت. لإصلاح هذه الثغرة بشكل كامل، يجب القيام بما يلي:

1. عشوائي مفتاح JWT: عند بدء التشغيل إذا تم العثور على jwt_secret متطابق مع القالب، يتم رفض التشغيل؛ يُنصح بتغييره إلى التخزين الآمن أو نظام إدارة المفاتيح.

2. تعطيل وضع المسؤول الافتراضي: السماح بوضع المسؤول فقط عند التكوين الصريح، ويتطلب كلمة مرور قوية + OTP؛ يجب إغلاق /api/admin-login مباشرة في وضع غير المسؤول.

3. تقليل استجابة /api/exchanges: بشكل افتراضي، تعيد فقط الحقول غير الحساسة مثل حالة التفعيل، علامة الشبكة التجريبية، إلخ؛ يجب أن يكون تصدير API/المفتاح الخاص من خلال واجهة منفصلة وتحقق ثانٍ، ويجب على الخادم إجراء إزالة الحساسية أو التشفير للحقول.

يجب اعتبار أي نشر موجه للعامة عالي المخاطر حتى تكمل فريق التطوير هذه الإصلاحات. خاصة أن الأصل/الرئيسي لا يزال في مرحلة “عدم المصادقة” 517d0c، ويجب على المسؤولين صيانة تحديث الكود بأسرع ما يمكن وتنفيذ استراتيجيات تعزيز المفاتيح المخصصة والواجهات بشكل صارم.