وفقًا لتقارير حديثة، كشفت Binance عن تأثير إجمالي يقدر بـ 6.3 مليار دولار من جراء الاختراق، في حين صرحت بأن 3 مليارات دولار من الأصول تم التحقق من تجميدها. لا تزال التفاصيل قيد التحقيق، لذا يجب التعامل مع المسار الفني للحادثة والنسب الأوسع لها كأمور أولية وليست حقائق نهائية.
النقطة الأساسية: حادث Binance المبلغ عنه يوضح لماذا يجب تصميم أمان السحب كنظام تفويض متعدد الطبقات، بحيث لا يمكن أن يؤدي اختراق محطة عمل أو حاوية خدمة بشكل مستقل إلى إنتاج معاملات سحب صالحة خارجياً.
ما هو المبلغ عنه حاليًا بشأن حادثة Binance؟
تصف التقارير الأخيرة حادثة في Binance بتأثير يقدر بـ 6.3 مليار دولار، وأصول مجمدة موثقة بقيمة 3 مليارات دولار، ومسار مشتبه به يشمل اختراق جهاز كمبيوتر محمول لمهندس DevOps، والوصول إلى حاوية الخدمة، وتقديم طلبات سحب غير مصرح بها. وذكرت Binance أنه لم يتم العثور على أي دليل على تسريب مفاتيح محفظة خاصة، وتم تعليق عمليات السحب أثناء تجديد الأمان، واستمرت عمليات الإيداع بشكل طبيعي.
يمثل التمييز بين التأثير المقدر والمبلغ المجمد أمراً مهماً. فقد يعكس تقدير التأثير أصولًا معرضة، أو محولة، أو محجوزة، أو قابلة للتتبع، أو مرتبطة بطريقة ما بالاستجابة للحادث. في المقابل، الأصول المجمدة هي الأصول التي اتخذ طرف ذي صلة إجراءً مقيدًا ملموسًا بشأنها. لا ينبغي اعتبار هذه الأرقام مقاييس متبادلة للخسارة، أو الاسترداد، أو التعرض النهائي للمستخدم.
| العنصر المبلغ عنه | التفاصيل الملموسة | تفسير الأمان |
|---|---|---|
| التأثير المقدر | صرحت Binance بتأثير إجمالي يقدر بـ 6.3 مليار دولار | الرقم المبلغ عنه يعكس نطاق الحادثة المقدر إجمالاً، وليس بالضرورة مجموع خسائر نهائي |
| الأصول المجمدة | صرحت Binance بأن 3 مليارات دولار تم التحقق من تجميدها | التجميد هو نتيجة احتواء ويتطلب التحقق على مستوى الأصول |
| الوصول الأولي المشتبه به | قد يكون جهاز كمبيوتر محمول لمهندس DevOps تم اختراقه سمح بالوصول إلى حاوية الخدمة | قد يؤدي اختراق نقطة نهاية إلى اختراق الإنتاج حيث تكون الحدود التشغيلية ضعيفة |
| مسار المعاملة المشتبه به | قد يكون المهاجم قد قدم معاملات سحب غير مصرح بها | تتطلب تدفقات عمل السحب ضوابط تتجاوز حيازة مفتاح المحفظة |
| مفاتيح المحفظة | قالت Binance إنها لم تجد أي دليل على تسريب مفتاح خاص للمحفظة | يمكن أن تحدث حادثة سحب دون سرقة مباشرة لمفاتيح التوقيع طويلة الأمد |
| استمرارية الخدمة | تم تعليق السحوبات، واستمرت الإيداعات بالعمل، وكان من المتوقع استئناف السحوبات في غضون 48 ساعة | يمكن للفصل بين العمليات الواردة والصادرة أن يحافظ على خدمات محددة أثناء الاحتواء |
| إجراء Arbitrum | أبلغ مجلس أمني Arbitrum عن تجميد 30.5 مليون دولار تشمل 74.6 مليون ARB و8,425 ETH | يمكن للتنسيق عابر البيئة أن يقيد حركة الأصول المتأثرة |
| إجراء Aave | جمدت Aave الأسواق عبر عمليات النشر V3 و V4 كإجراء احترازي | قد تحتاج البروتوكولات التابعة إلى تقليل التعرض قبل معرفة السبب الجذري الفني الكامل |
بالنسبة لفرق الأمان، السؤال المركزي ليس هل تم تسريب مفتاح خاص للمحفظة. السؤال المركزي هو أي هوية، أو عملية، أو إذن تطبيق، أو سياسة معاملة، أو سير عمل موافقة سمحت لطلب سحب غير مصرح به بالوصول إلى التنفيذ.
لهذا السبب يجب تفريق التقارير بين الحقائق المؤكدة والافتراضات التحقيقية. يُعتبر اختراق جهاز مهندس DevOps المسار الهجومي المبلغ عنه والذي لا يزال تحت التحقيق. غياب الأدلة على تسريب المفتاح الخاص هو بيان تشغيلي مهم، لكنه لا يحدد وحده كل ضوابط قد تكون فشلت.
كيف يمكن لجهاز كمبيوتر محمول مخترق أن يؤدي إلى سحوبات غير مصرح بها؟
يمكن أن يؤدي جهاز كمبيوتر محمول مسؤول مخترق إلى سحوبات غير مصرح بها عندما يحتوي الجهاز على وصول إلى أنظمة هوية الإنتاج، أو أدوات النشر، أو بيانات اعتماد الخدمة، أو وحدات التحكم المميزة، أو قنوات الموافقة التي يثق فيها نظام السحب. يسلط السيناريو المبلغ عنه لـ Binance الضوء على طبقة الخدمة بين طلبات السحب من المستخدمين وحركة الأصول النهائية، وليس على استخراج مفتاح المحفظة مباشرة.
تعمل بيئات التبادل والحفظ الحديثة غالبًا من خلال عدة مستويات موثوقة متصلة:
- مستوى نقطة نهاية البشر: أجهزة الكمبيوتر المحمولة للمسؤولين، رموز الأجهزة، مديري كلمات المرور، المتصفحات الآمنة، أدوات التطوير، وعملاء الوصول عن بعد.
- مستوى الهوية: تسجيل الدخول الموحد، إدارة الوصول المميز، تعيين الأدوار، ضوابط الجلسات، والوصول الطارئ.
- مستوى أحمال العمل: حاويات الخدمة، أنظمة التنسيق، حقن الأسرار، واجهات برمجة التطبيقات، وقوائم انتظار الرسائل الداخلية.
- مستوى المعاملات: قواعد السحب، قوائم السماح، قيود السرعة، محركات المخاطر، الموافقات المتعددة الأطراف، طلبات التوقيع، ورصد التسوية.
- مستوى الحفظ: شظايا المفاتيح، أجهزة التوقيع، الاحتياطيات غير المتصلة، وحدات الأمان المادي، وإجراءات الاسترداد.
يصبح الاختراق خطيرًا عندما يرث مستوى واحد سلطة مستترة من مستوى آخر. على سبيل المثال، يجب ألا تكون جلسة المسؤول المميزة كافية لإنشاء سحب غير مراجَع، أو تعديل سياسة السحب، أو تجاوز قائمة السماح، أو إرسال طلب توقيع عالي القيمة مباشرة إلى بنية الحفظ.
تسلسل الأحداث المبلغ عنه الذي يشمل حاوية الخدمة مهم بشكل خاص لأن أحمال العمل عادة ما تُمنح ثقة أوسع من المستخدمين الأفراد. قد يكون لدى الخدمة إذن لبناء طلبات سحب، أو استدعاء نقطة نهاية الموافقة الداخلية، أو قراءة الأرصدة، أو التواصل مع منسق التوقيع. إذا تم اختراق هوية تلك الخدمة، قد يحاول المهاجم التصرف كجزء مشروع من النظام.
من تجربتنا في تدقيق العقود الذكية والبنية التحتية لـ Web3 في Soken، السيطرة الحاسمة ليست مجرد الحفاظ على سرية المفاتيح. السيطرة الحاسمة هي ضمان أنه لا تمتلك محطة عمل أو حاوية أو بيانات اعتماد خدمة واحدة سلطة كافية لتحويل طلب غير موثوق إلى حركة أصول مكتملة.
لذلك يجب على بنية السحب الناضجة فرض فحوصات مستقلة عند كل حد. يجب تقييم ثقة الجهاز بشكل منفصل عن هوية المستخدم. يجب أن تكون الموافقة البشرية متميزة عن تفويض التطبيق. يجب أن يبقى محرك سياسة المعاملة مستقلاً عن الخدمة التي تقدم المعاملة. يجب أن ترفض أنظمة التوقيع الطلبات التي لا تحمل سياق سياسة قابل للتحقق.
يمكن للفرق التي تبني هذه الحدود دمجها في مراجعة البنية، ونمذجة التهديد، وعملية تقييم الأمان من خلال خدمات الأمان والتطوير التقنية. الهدف هو اختبار مسار التفويض الحقيقي، بما في ذلك الأنظمة التشغيلية التي تتواجد خارج العقود الذكية لكنها لا تزال تحدد كيفية حركة الأصول.
لماذا لا تنهي عدم وجود تسريب للمفتاح الخاص التحقيق؟
تضيق نتيجة Binance المعلنة بعدم وجود دليل على تسريب مفتاح خاص للمحفظة مسار هجوم محتمل واحد، لكنها لا تستبعد وجود سياسة معاملات مخترقة، أو تفويض توقيع مفوض، أو مصادقة خدمة، أو موافقات داخلية، أو بيانات اعتماد تشغيلية. يجب أن تدافع تصميمات الحفظ الآمنة عن مادة المفتاح وكل نظام يمكنه طلب، أو الموافقة، أو توجيه، أو تهيئة توقيع.
المفاتيح الخاصة هي الخطر الأكثر وضوحًا للحفظ، لكنها ليست الآلية الوحيدة للتحكم بالأصول. قد يتم تكوين نظام التوقيع لقبول طلبات من خدمات داخلية محددة. قد يتم توقيع المعاملة بشكل صحيح لكنها غير مصرح لها تشغيليًا إذا اخترق المهاجم الخدمة المسؤولة عن إنتاج الطلبات المعتمدة على السياسة.
يخلق هذا التمييز سؤالين أمنيّين منفصلين:
- هل تم اختراق السلطة التشفيرية؟ ويشمل ذلك المفاتيح الخاصة، وشرائح المفاتيح، وأجهزة التوقيع، ومواد الاسترداد، أو الوصول إلى بيئة التوقيع.
- هل تم اختراق التفويض التجاري؟ ويشمل جلسات مميزة، هويات الخدمة، قواعد السحب، حدود المخاطر، قوائم السماح للعناوين، حالة الموافقة، وقوائم انتظار المعاملات.
يركز تحقيق Binance المبلغ عنه بشكل خاص على السؤال الثاني. إذا كانت حاوية الخدمة قابلة للوصول عبر كمبيوتر محمول مخترق، سيحتاج المحققون إلى إعادة بناء بيانات الاعتماد المتاحة، والإجراءات التي تم تنفيذها، وما إذا كانت السجلات كاملة، وما إذا كانت ضوابط المعاملة تصرفت حسب التكوين.
يجب أن يحفظ التحقيق المدافع الأدلة عبر بيانات نقاط النهاية، سجلات الهوية، نشاط الحاويات، تكوين البنية التحتية، قوائم انتظار المعاملات، سجلات الموافقة، والآثار على الشبكة. يجب أن يحدد أيضًا جدولًا زمنيًا واضحًا: أول وصول مريب، تصعيد امتيازات، تفاعل الخدمة، تقديم السحب، طلب التوقيع، البث، إجراءات الاحتواء، وتجميد الأصول.
يحمل هذا العمل الأدلي آثارًا قانونية وحوكمية بالإضافة إلى التقنية. يحتاج مشغلو البورصات، وحفظة الأصول، وفرق البروتوكولات إلى إجراءات حادثة تحدد حقوق اتخاذ القرار، وتعرف حدود الإفصاح، وتحفظ السجلات، وتميز النتائج الأولية عن الحقائق المؤكدة. غالبًا ما تكون هذه الأسئلة الحوكمية مجاورة لـ الخدمات القانونية والامتثال، خصوصًا حيث تتقاطع الضوابط التشغيلية والاتصالات مع المستخدم.
تعزز الحادثة أيضًا الحاجة إلى سياسات سحب ذات معنى تحت حالة الاختراق. فالقائمة البيضاء غير فعالة إذا كانت خدمة مميزة مخترقة يمكنها تعديل القائمة. والحد الأقصى للمعاملة غير فعال إذا احتوى نظام تحكم مخترق على زيادة الحد. وعمليات الموافقة المتعددة غير فعالة إذا كانت جميع الموافقات تعتمد على نفس موفر الهوية، أو أسطول نقاط النهاية، أو خدمة داخلية.
ماذا تُظهر استجابات Arbitrum و Aave؟
توضح إجراءات مجلس أمان Arbitrum و Aave المبلغ عنها أن عمليات الاحتواء يمكن أن تمتد إلى ما هو أبعد من البورصة المتأثرة مباشرة عندما تتفاعل الأصول والسيولة مع أنظمة أونتشين أوسع. حيث أبلغ مجلس أمان Arbitrum عن تجميد 30.5 مليون دولار تشمل 74.6 مليون ARB و8,425 ETH، بينما جمدت Aave الأسواق في عمليات النشر V3 و V4 كإجراء احترازي.
تعكس هذه الإجراءات نموذجين مختلفين لكن متكاملين للاستجابة.
ركز إجراء مجلس أمان Arbitrum على أصول محددة معلنة. يمكن أن يكون التجميد المستهدف مفيدًا حيث يمتلك كيانات الحوكمة أو الأمان سلطة وثقة لتقييد أموال محددة. وتعتمد فعالية مثل هذا الإجراء على نسبة الأصول بدقة، والتنفيذ السريع، وحدود السلطة الشفافة، والتعامل الحذر مع الإيجابيات الكاذبة.
تركز إجراء Aave على احتواء المخاطر على مستوى السوق. فعملية تجميد الأسواق عبر V3 و V4 هي إجراء وقائي أوسع نطاقًا. يعترف هذا النهج بأن المخاطر قد تنتقل عبر قيم الضمانات، وحمامات السيولة، ووضعيات الاقتراض، والأسواق الحساسة للأوراكل، والأصول المترابطة حتى قبل فهم كل مسار تحويل بشكل كامل.
المقارنة مفيدة لكل فريق بروتوكول يصمم خطة استجابة طارئة:
| نهج الاستجابة | الجهة المُبلغ عنها | الإجراء المحدد المبلغ عنه | الهدف الوقائي الرئيسي |
|---|---|---|---|
| تقييد مخصص للأصل | مجلس أمان Arbitrum | جمد 30.5 مليون دولار تشمل 74.6 مليون ARB و8,425 ETH | منع حركة إضافية للأصول المحددة |
| وقاية على مستوى السوق | Aave | جمد الأسواق عبر عمليات النشر V3 و V4 | الحد من العدوى عبر تعرض سوق الإقراض |
| تعليق الخدمة المركزية | Binance | أوقفت عمليات السحب أثناء إعادة تركيب الأمان | إيقاف التحويلات الصادرة الإضافية مع الحفاظ على الإيداعات |
لا يُعتبر أي نهج منها متفوقًا تلقائيًا. يعتمد الإجراء الصحيح على نموذج سلطة النظام ونمط الفشل. لا يمكن لبروتوكول مع عقود غير قابلة للتغيير وبدون ضوابط طوارئ تنفيذ تجميد للسوق. يجب أن تضمن البروتوكولات التي تملك صلاحيات طوارئ واسعة أن تكون هذه الصلاحيات محدودة النطاق، وحوكمة مستقلة، ومفهومة جيدًا قبل وقوع الحادث.
تتطلب ضوابط الطوارئ أيضًا اختبارات روتينية. يجب أن تعرف الفرق الوظائف التي يمكنها وقف التحويلات، تجميد السوق، حظر مسار، إلغاء بيانات اعتماد الخدمة، تدوير الأسرار، أو تعطيل سياسة التوقيع. يجب أن تعرف من يمكنه استدعاء كل تحكم، كيف يُسجّل الإجراء، وكيف يُستعاد التشغيل الطبيعي بأمان.
للمزيد من التحليل حول هندسة الأمان، ضوابط الحوكمة، والمخاطر المستندة للحوادث، يمكن للقراء استكشاف مركز أبحاث Soken.
ما الذي يجب أن تغيره الفرق بعد نمط الهجوم المبلغ عنه هذا؟
يجب على الفرق اعتبار نمط Binance المبلغ عنه حافزًا لاختبار ما إذا كان يمكن لجهاز نقطة نهاية موظف مخترق أو حمولة عمل إنتاجية أن تبدأ بشكل مستقل تدفق عمل يحرك الأصول. الهدف المباشر هو تقليل سلطة أجهزة الكمبيوتر المحمولة، وبيانات اعتماد الحاويات، وحسابات الخدمات الداخلية، والعمليات الآلية بحيث يؤدي الاختراق إلى احتواء بدلًا من تنفيذ سحب غير مقيد.
يجب أن تبدأ المراجعة العملية بأعلى مسارات المعاملات قيمة، وليس بقائمة تدقيق بنية تحتية عامة.
-
خرّط كل مسار سلطة السحب. وثّق من يمكنه بدء، تحرير، الموافقة، التوقيع، البث، الإيقاف، واستئناف عمليات السحب. ضمّن المستخدمين البشر، حسابات الخدمة، الحاويات، أدوات الأتمتة، الحسابات الطارئة، والأنظمة الخارجية.
-
حدد إخفاقات الثقة في مستوى واحد. اختبر ما إذا كان جهاز موظف واحد يمكنه الوصول لإدارة مميزة، أو هل يمكن لرمز خدمة واحد إنشاء موافقات، أو ما إذا كان بإمكان هوية حمولة عمل واحدة الوصول إلى بنية توقيع.
-
فصل إنشاء الطلب عن تفويض السياسة. يجب ألا يكون النظام الذي يقدم طلب السحب النظام الوحيد الذي يقرر ما إذا كان السحب مسموحًا به. يجب أن تتحقق تقييمات السياسة المستقلة من الوجهة، الأصل، المبلغ، التوقيت، سياق المستخدم، وحالة المخاطر.
-
قيد أذونات حاوية الخدمة. طبق مبدأ أقل الامتيازات على هويات الأحمال. يجب أن تحصل الحاوية على الأذونات المطلوبة فقط لمهمتها المحدودة، مع بيانات اعتماد قصيرة العمر ومسارات وصول يمكن تدقيقها.
-
اشترط مجالات موافقة مستقلة. لا ينبغي أن تعتمد قرارات السحب الحرجة على موافقات يتحكم بها نفس بيئة نقطة النهاية، أو مزود الهوية، أو دور المسؤول.
-
تدرّب على العزل بدون إغلاق كامل. وُجد أن Binance حافظت على عمليات الإيداع أثناء إيقاف عمليات السحب. يجب على الفرق تحديد مسبقًا أي الخدمات يمكن أن تبقى نشطة، وأيها يجب إيقافها، وأي الضوابط تحدد استئناف آمن.
-
عرّف التنسيق الخارجي مسبقًا. توضح إجراءات مجلس أمان Arbitrum وتجميد أسواق Aave لماذا يجب إنشاء اتصالات التبادل، السلسلة، الجسر، والبروتوكول قبل الطوارئ. خلال حادث مباشر، غالبًا ما يحدد جودة التنسيق ما إذا كان الاحتواء سريعًا أم متقطعًا.
-
حافظ على الأدلة قبل إعادة البناء. تدوير بيانات الاعتماد وإعادة نشر الخدمات هي إجراءات احتواء ضرورية، لكن يجب أن يحدث الحفاظ على الأدلة بشكل موازٍ. بدون سجلات موثوقة، قد تفقد الفرق المعلومات اللازمة لتمييز اختراق نقطة النهاية عن فشل السياسة أو خرق أوسع لنظام الهوية.
يمكن لمراجعة بنية الأمان المركزة التحقق من هذه الحدود عبر اختبار السيناريوهات: جلسة مسؤول مسروقة، بيئة بناء مخترقة، بيانات اعتماد حاوية مسربة، سياسة سحب معدّلة، أو محاولة التلاعب بقائمة انتظار المعاملات. يجب أن يطرح الاختبار سؤالًا واضحًا عند كل نقطة: ما السيطرة المستقلة التي تمنع الخطوة غير المصرح بها التالية؟
ينبغي التعامل مع النسبة المبلغ عنها لـ TraderTraitor، الموصوفة بأنها بثقة عالية من TRM Labs، بشكل حذر حتى يتم التحقق من التفاصيل. يمكن أن توجه النسبة المراقبة الدفاعية والتنسيق، لكنها لا تحل محل المعالجة المستندة إلى الأدلة. نفس إخفاقات السيطرة خطيرة بغض النظر عن هوية المهاجم.
ابنِ تمرين الاستجابة للسحب التالي حول تسلسل Binance المبلغ عنه: افترض أن جهاز كمبيوتر محمول لـ DevOps تم اختراقه، وتتبع أذونات حاوية الخدمة الممكن الوصول إليها، وتحقق من عدم قدرة أي طلب ناتج على تجاوز سياسة السحب المستقلة وفحوصات التوقيع. يحول هذا التمرين تأثير 6.3 مليار دولار المبلغ عنه إلى اختبار تصميم ملموس، مع إبقاء استجابة الحادث مرساة على الأدلة، حدود الوصول، وضوابط التشغيل القابلة للاسترداد.