المؤلف: flush & kong

الخلفية

في 21 فبراير 2025، واجهت صناعة العملات المشفرة أسوأ أزمة لإدارة الأصول في التاريخ. كانت محفظة التوقيعات المتعددة الموجودة على سلسلة منصة التداول Bybit مستهدفة وتم فقدان ما يقرب من 1.5 مليار دولار من الأصول بهدوء من خلال معاملة "موقعة قانونًا". وأظهر التحليل اللاحق على السلسلة أن المهاجم حصل على أذونات متعددة التوقيع من خلال هجمات هندسية اجتماعية متطورة، وزرع منطقًا ضارًا باستخدام وظيفة delegatecall في العقد الآمن، وتجاوز في النهاية آلية التحقق من التوقيع المتعدد لتحويل الأموال إلى عنوان مجهول.

كشفت هذه الحادثة عن حقيقة قاسية: "التوقيع المتعدد" لا يعني "الأمان المطلق". حتى آلية الأمان مثل محفظة التوقيع المتعدد الآمنة لا تزال معرضة لخطر الاختراق إذا لم يكن هناك تدابير حماية إضافية. هذا ليس الهجوم الأول على محفظة Safe متعددة التوقيع. وفي العام الماضي، تعرضت شركتا WazirX (230 مليون دولار) وRadiant Capital (50 مليون دولار) لهجمات مماثلة. كما تم تحليله في المقالة SlowMist: أساليب القراصنة والأسئلة وراء سرقة ما يقرب من 1.5 مليار دولار من Bybit، أظهر هجوم المحفظة متعددة التوقيع الآمن التشابه الفني التالي:

• الإفراط في الاعتماد على آلية التوقيع: ترك جميع مسؤوليات الأمن لحراسة المفاتيح الخاصة.

• الافتقار إلى الدفاع الديناميكي: الافتقار إلى مسح المخاطر في الوقت الفعلي قبل تنفيذ المعاملة.

• التحكم في الأذونات غير الدقيق: لم يتم إنشاء آلية القائمة البيضاء للعمليات عالية المخاطر مثل delegatecall.

(عملية سرقة Bybit: استخدام Safe v1.1.1)

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

آمنة

آمنة هي محفظة متعددة التوقيعات (Multi-Sig)، تستخدم بشكل أساسي لإدارة التخزين والنقل الآمن للأصول عالية القيمة والعملات الرقمية. باعتبارها البنية الأساسية لإدارة الأصول اللامركزية، فإنها تضمن أمان عمليات الصناديق من خلال آلية التحقق التعاونية متعددة الأطراف لمنع مسؤول واحد أو متسلل من استغلال نقطة فشل واحدة لإجراء عمليات ضارة. تُستخدم على نطاق واسع في سيناريوهات مثل حوكمة DAO، وحفظ أموال الشركات، ومجموعات الصناديق اللامركزية. تم تطوير العقد من قبل فريق Safe (المعروف سابقًا باسم Gnosis Safe) وهو حل إدارة الأصول على السلسلة القياسي الحالي في الصناعة. يستخدم العقد معيار EIP-712 لتنفيذ توقيعات البيانات المنظمة، وبالتالي تحسين أمان بيانات المعاملات وإمكانية التحقق منها.

الغرض الأساسي

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

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

• التوسع المعياري: يعتمد العقد على تصميم معياري. من خلال وراثة ودمج وحدات إدارة متعددة (مثل OwnerManager وModuleManager وGuardManager وFallbackManager وما إلى ذلك)، تكون وظائفه مرنة وسهلة التوسع، مما يوفر دعمًا مخصصًا لسيناريوهات التطبيق المختلفة.

تحليل الوظائف

تتحقق وظيفتا checkContractSignatures و checkNSignatures من بيانات التوقيع الخاصة بالمعاملة أو الرسالة:

• معالجة توقيعات حساب EOA وتوقيعات العقد (EIP-1271) والتجزئات المعتمدة مسبقًا بشكل منفصل؛

• تأكد من ترتيب التوقيعات حسب المالكين وأن كل توقيع يأتي من عنوان صالح لمنع هجمات الإعادة والتلاعب بالتوقيع.

تولد وظيفة getTransactionHash تجزئة معاملة للتحقق من التوقيع ومنع هجمات الإعادة:

• استخدم معيار EIP-712 لإجراء تجزئة منظمة على بيانات المعاملات؛

• استخدم التجميع المضمن لتحسين عمليات الذاكرة وتحسين كفاءة الحوسبة؛

• ادمج قيمة nonce الحالية لضمان تفرد كل معاملة.

تتعامل وظيفة handlePayment مع دفع تعويض الغاز أثناء عملية تنفيذ المعاملة:

• تحسب مبلغ الدفع بناءً على رسوم الغاز المستهلكة الفعلية والرسوم الأساسية؛

• تدعم دفع ETH والرموز الأخرى لضمان تعويض الرسوم بدقة.

onBeforeExecTransaction هي دالة ربط افتراضية داخلية ويتم استدعاؤها قبل تنفيذ دالة execTransaction. تم تصميم هذه الوظيفة للسماح للعقود الفرعية التي ترث العقد الآمن بإجراء معالجة منطقية مخصصة قبل تنفيذ المعاملة. تتضمن مجموعة المعلمات المستلمة:

• to: target address - عنوان العقد أو الحساب الذي سيتم استدعاؤه بواسطة المعاملة

• value: ether value - كمية الأثير المرسلة مع المعاملة

• data: data payload - بيانات الاتصال التي تحتوي على محدد الوظيفة والمعلمات

• operation: process type - يحدد ما إذا كانت CALL أو DELEGATECALL

• safeTxGas: حد غاز المعاملة - كمية الغاز المحجوزة لتنفيذ المعاملة

• baseGas: الغاز الأساسي - غاز مستقل عن تنفيذ المعاملة التكلفة

• سعر الغاز: سعر الغاز - سعر الغاز المستخدم لحساب تعويض رسوم المعاملة

• رمز الغاز: رمز الغاز - عنوان الرمز المستخدم لدفع رسوم المعاملة

• متلقي الاسترداد: متلقي الاسترداد - عنوان استلام تعويض رسوم المعاملة

• التوقيعات: مجموعة التوقيعات - بيانات توقيع المالك على المعاملة

الحماية الآمنة

ميزة أمان مهمة تم تقديمها بواسطة عقد Safe في الإصدار 1.3.0 - آلية الحماية الآمنة. تم تصميم هذه الآلية لتوفير قيود إضافية على مخطط التوقيع المتعدد القياسي n-out-of-m، مما يعزز أمان المعاملات بشكل أكبر. تكمن القيمة الأساسية لـ Safe Guard في قدرتها على إجراء فحوصات أمنية في مراحل مختلفة من تنفيذ المعاملة:

• فحص ما قبل المعاملة (checkTransaction):يمكن لآلية Guard إجراء فحص برمجي على جميع معلمات المعاملة قبل تنفيذها للتأكد من أن المعاملة تتوافق مع قواعد الأمان المحددة مسبقًا.

• التحقق بعد المعاملة (checkAfterExecution):بعد تنفيذ المعاملة، سيقوم Guard بإجراء تحقق أمني إضافي للتحقق مما إذا كانت الحالة النهائية للمحفظة الآمنة بعد تنفيذ المعاملة تلبي التوقعات.

تحليل البنية

في Safe، يتم تنفيذ المعاملات متعددة التوقيع بشكل عام من خلال وظيفة execTransaction. عند تمكين Safe Guard، عندما ينفذ المستخدم معاملة متعددة التوقيعات، سيستدعي عقد Safe وظيفة checkTransaction الخاصة بعقد Guard لإجراء فحص ما قبل المعاملة. بعد اكتمال المعاملة متعددة التوقيعات، سيستدعي عقد Safe وظيفة checkAfterExecution الخاصة بعقد Guard للتحقق من نتيجة تنفيذ المعاملة. التنفيذ المحدد هو كما يلي:

عندما يقوم العقد الآمن بإجراء فحص مسبق لمعاملة متعددة التوقيع من خلال آلية Guard، ستتلقى وظيفة checkTransaction الخاصة به بيانات سياق المعاملة الكاملة، بما في ذلك عنوان العقد المستهدف وطريقة الاتصال وبيانات التنفيذ (مثل delegatecall) ومعلومات توقيع المالك وتكوين Gas ومعلومات الدفع. تتيح هذه الآلية للمطورين تنفيذ استراتيجيات التحكم في المخاطر متعددة الأبعاد، مثل التحكم في القائمة البيضاء للعقود (الحد من العناوين التفاعلية)، وإدارة الأذونات على مستوى الوظيفة (تعطيل محددات الوظائف عالية المخاطر)، وقيود تكرار المعاملات، والقواعد الديناميكية القائمة على تدفقات رأس المال. من خلال تكوين استراتيجية الحرس بشكل صحيح، يمكن منع المهاجمين بشكل فعال من استخدام طبقات غير تعاقدية لشن الهجمات.

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

من الجدير بالذكر أن Safe نفسها توفر فقط وظائف إدارة Guard ووظيفة الاستدعاء. يتم تنفيذ منطق فحص المعاملات المتعددة التوقيع الفعلي بواسطة المستخدم نفسه، ويعتمد أمانه على جودة تنفيذ Guard. على سبيل المثال، يقوم Solv Guardian بتوسيع هذه الفكرة من خلال تكوين Guardian مخصص في كل Vault لتحديد عنوان الهدف المسموح به وأذونات التشغيل، وتحقيق عناصر التحكم في الأذونات الثلاثة الرئيسية لتحديد العقود المسموح بها، وتحديد عمليات الوظيفة المسموح بها، ومتطلبات التحقق من قائمة التحكم في الوصول (ACL). في الوقت نفسه، تم اعتماد آلية حوكمة منفصلة، ​​حيث يكون Vault Guardian مسؤولاً عن التنفيذ بينما يتحكم Governor في سلطة الحوكمة، مما يضمن أنه حتى في حالة وجود مشكلة مع Guardian، يمكن اتخاذ التدابير التصحيحية في الوقت المناسب لحماية أصول المستخدم. يتم تطبيق مفهوم تصميم مماثل أيضًا في SecurityControlModule الخاص بـ Elytro، والذي يعترض العمليات الرئيسية من خلال وظيفة preExecute ويستخدم آلية القائمة البيضاء لضبط العمليات عالية المخاطر مثل تثبيت الوحدة النمطية وإعدادات الخطاف وإدارة المحقق، وبالتالي ضمان إمكانية إضافة العقود الموثوقة فقط إلى النظام، مما يوفر حماية أمنية طويلة الأجل للمحفظة. في سلسلة هجوم حدث Bybit، إذا نشر العقد الآمن آلية Guard مُهيأة بشكل صحيح، فسيتم اعتراض نداء التفويض الخبيث الذي بدأه المهاجم من خلال execTransaction بواسطة استراتيجيات متعددة في مرحلة الفحص المسبق: تحدد وظيفة checkTransaction الخاصة بالحرس أولاً نوع عملية نداء التفويض وتطلق قاعدة التعطيل (مثل تقييد العملية قسراً على المكالمات العادية فقط)، ثم تحلل حقل البيانات للكشف عن عناوين العقد غير التقليدية (0x4622...7242) ومحددات الوظائف عالية المخاطر، وتعيد المعاملة مباشرة من خلال استراتيجيات القائمة البيضاء للعقد والقائمة السوداء للوظائف المحددة مسبقًا، مما يشكل في النهاية نظام دفاع "اعتراض الاستراتيجية → حظر المنطق" لمنع العبث بالتخزين ومسارات نقل الأموال تمامًا.

(عند استخدام إصدار Safe ≥ v1.3.0  عملية التحقق من وحدة Safe Guard https://excalidraw.com/#room=fd1df67dd09b3dab6bd8,Q1jeb1MZW7vwbY4NuxaV5A)

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

الخلاصة والتوقعات

يسلط هجوم Bybit الضوء على أهمية تحديث البنية الأساسية الأمنية في الوقت المناسب. يستخدم Bybit الإصدار v1.1.1 (<1.3.0) من عقد Safe، مما يعني أنه لا يمكنهم استخدام آلية Guard، وهي ميزة أمان رئيسية. إذا قامت Bybit بالترقية إلى الإصدار 1.3.0 أو أعلى من عقد Safe وتنفيذ آلية Guard مناسبة، مثل تحديد عنوان القائمة البيضاء الذي يعد العنوان الوحيد الذي يتلقى الأموال وإجراء التحقق الصارم من قائمة التحكم في الوصول لوظيفة العقد، فقد يكون من الممكن تجنب هذه الخسارة. ورغم أن هذا مجرد فرضية، فإنه يقدم أفكاراً مهمة لإدارة أمن الأصول في المستقبل.

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

• التحقق الآلي: إنشاء آلية آلية للتحقق من المعاملات

• تعديل السياسة الديناميكي: تعديل سياسات الأمان في الوقت الفعلي بناءً على معلومات استخباراتية عن التهديدات

• الدفاع متعدد الطبقات: الجمع بين آليات أمان متعددة لبناء نظام دفاع عميق

• التدقيق المستمر: إجراء عمليات تدقيق أمنية منتظمة على تطبيقات Guard

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