اختراق Binance بقيمة 6.3 مليار دولار يكشف أهمية ضوابط المعاملات

أكدت Binance تعرض محافظها لتحويلات غير مصرح بها بقيمة تقارب 6.3 مليار دولار. الدرس للشركات هو حماية صلاحيات تنفيذ المعاملات، وليس الاكتفاء بحماية كلمات المرور والمفاتيح.

في 29 أكتوبر 2026، تمكن مهاجمون من تحويل أصول رقمية تُقدر قيمتها بنحو 6.3 مليار دولار من محافظ تابعة لمنصة Binance. أوقفت المنصة عمليات السحب مؤقتاً، وبدأت تتبع الأموال، وتعهدت بتغطية خسائر المستخدمين. لكن الخبر يحمل درساً مهماً يتجاوز العملات الرقمية: ماذا يحدث عندما يتمكن مهاجم من استخدام أنظمة الشركة الداخلية لتنفيذ معاملات مالية لم توافق عليها الشركة؟

ما الذي أكدته Binance حتى الآن؟

في بيانها الصادر يوم 30 أكتوبر، قدّرت Binance حجم الأصول المتأثرة بنحو 6.3 مليار دولار، وأعلنت تجميد ما يقارب 3 مليارات دولار بالتعاون مع جهات تعمل في شبكات البلوك تشين. كما تعهدت بتغطية الخسائر من صندوق حماية المستخدمين SAFU وأموال الشركة. لكن هناك فرقاً بين تجميد الأصول المسروقة واستعادتها فعلياً، كما أن التعهد بالتعويض لا يعني أن جميع المبالغ دُفعت بالفعل.

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

بحسب تحليل TRM Labs، شملت التحويلات غير المصرح بها نحو 6.36 مليار دولار عبر عشر شبكات بلوك تشين، وحدث الجزء الأكبر منها خلال نحو 20 دقيقة. وترجح الشركة مسؤولية مجموعة TraderTraitor المرتبطة بكوريا الشمالية. هذا تقييم استخباراتي من شركة متخصصة، وليس نتيجة نهائية أعلنتها Binance.

المشكلة الأخطر هي القدرة على تنفيذ التحويلات

أشارت التحقيقات الأولية لدى Binance إلى احتمال اختراق حاسوب محمول لمهندس DevOps. وربما مكّن هذا الاختراق المهاجم من الوصول إلى حاوية خدمة داخلية واستخدامها لإرسال طلبات سحب غير مصرح بها. لكن Binance أوضحت لاحقاً أنها اكتشفت نقاط اختراق إضافية، وأن العملية لم تكن مجرد استخدام مباشر لصلاحيات موظف واحد.

التفصيل المهم أن Binance لم تجد حتى الآن دليلاً على تسريب المفاتيح الخاصة للمحافظ. في المقابل، يشير تحليل TRM Labs إلى احتمال وصول المهاجم إلى البنية المسؤولة عن إصدار التوقيعات الصحيحة للمعاملات على عدة شبكات. هذا تفسير محتمل وليس سبباً مؤكداً. فقد يتمكن المهاجم من إساءة استخدام نظام مخوّل بتنفيذ المعاملات دون أن يحصل على المفاتيح السرية نفسها.

وجود توقيع رقمي صحيح يعني أن النظام تعرّف على صلاحية التوقيع، لكنه لا يثبت أن التحويل كان مقصوداً أو مشروعاً. والمشكلة نفسها قد تظهر في تطبيقات عادية، عندما يتمكن حساب خدمة مخترق من اعتماد مبالغ مستردة، أو تغيير بيانات حساب بنكي، أو صرف مستحقات العملاء دون مراجعة مستقلة.

إذا كان منتجك يتعامل مع الأموال، راجع صلاحيات التنفيذ

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

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

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

قرارك يعتمد أيضاً على مدى ارتباط منتجك بـ Binance

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

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

ما الذي ينبغي فعله هذا الأسبوع؟

ابدأ بتحديد العملية التي يمكن أن تسبب أكبر ضرر في منتجك إذا نُفذت دون إذن. ثم اختبر ما إذا كان اختراق حساب واحد أو خدمة داخلية واحدة كافياً لتنفيذها.

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

قد تكشف التحقيقات النهائية تفاصيل جديدة عن اختراق Binance. لكن الدرس واضح لتصميم المنتجات: حماية الوصول إلى النظام ضرورية، وحماية الصلاحيات التي يمتلكها هذا الوصول لا تقل أهمية عنها.