تحليل متعمق للمعضلة الآمنة: هل يمكن للحارس إعادة بناء برج العقد في بابل؟

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

كشفت هذه الحادثة عن واقع قاسي: "التوقيع المتعدد" لا يعني "الأمان المطلق"، حتى لو كانت آلية الأمان مثل محفظة Safe متعددة التوقيعات، إذا كانت تفتقر إلى تدابير الحماية الإضافية، فلا تزال هناك مخاطر للاختراق. وهذه ليست الحالة الأولى التي يتم فيها استهداف محفظة Safe متعددة التوقيعات. في العام الماضي، تكبدت شركتان معروفتان خسائر بلغت 230 مليون دولار و50 مليون دولار، وتعرضتا لهجمات مشابهة. تظهر حوادث هجمات محفظة Safe متعددة التوقيعات ما يلي من التماثل التقني:

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

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

آمن

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

الاستخدامات الأساسية

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

تحليل الدالة

execTransaction دالة تنفيذ المعاملات التي تم التحقق منها بواسطة توقيع متعدد:

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

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

• معالجة توقيعات حسابات EOA وتوقيعات العقود (EIP-1271)، وكذلك التجزئة المسبقة الموافقة؛
• تأكد من أن التوقيعات مرتبة حسب ترتيب المالك، وأن كل توقيع يأتي من عنوان صالح، لمنع هجمات إعادة التشغيل والتلاعب بالتوقيعات.

تقوم دالة getTransactionHash بإنشاء تجزئة المعاملة، والتي تُستخدم للتحقق من التوقيع ومنع هجمات إعادة التشغيل:

• استخدام معيار EIP-712 لهيكلة التجزئة للبيانات المعاملات؛
• استخدام التجميع الداخلي لتحسين عمليات الذاكرة وزيادة كفاءة الحساب؛
• دمج قيمة nonce الحالية لضمان فريدة كل معاملة.

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

• حساب مبلغ الدفع بناءً على تكاليف الغاز الفعلية والتكاليف الأساسية؛
• دعم دفع ETH والرموز الأخرى، لضمان تعويض التكاليف بدقة.

onBeforeExecTransaction هو دالة خطاف افتراضي داخلي تُستدعى قبل تنفيذ دالة execTransaction. الغرض من تصميم هذه الدالة هو السماح للعقود الفرعية التي ترث من عقد Safe بإجراء معالجة منطقية مخصصة قبل تنفيذ المعاملة. تشمل مجموعة المعلمات المستلمة:

• إلى：عنوان الهدف - عنوان العقد أو الحساب الذي يجب استدعاؤه في المعاملة
• القيمة: قيمة الإيثيريوم - عدد الإيثيريوم المرسل مع الصفقة
• data：حمولة البيانات - تحتوي على بيانات استدعاء تتضمن محدد دالة والمعلمات
• operation：نوع العملية - تأكد مما إذا كانت CALL أو DELEGateCALL
• safeTxGas: حد الغاز للتداول - كمية الغاز المخصصة لتنفيذ التداول
• baseGas：العمق gas - تكلفة gas المستقلة عن تنفيذ المعاملة
• gasPrice：سعر الغاز - يُستخدم لحساب تعويض رسوم المعاملات بسعر الغاز
• gasToken: عنوان رمز الغاز - رمز يستخدم لدفع رسوم المعاملات
• refundReceiver: المستلم للرد: عنوان استلام تعويض رسوم المعاملات
• signatures：مجموعة التوقيعات - بيانات توقيع المالك على المعاملة

! [الغوص العميق في المعضلة الآمنة: هل يمكن للحارس إعادة بناء برج بابل المضغوط؟] ](https://img-cdn.gateio.im/webp-social/moments-7abedb36995e926e2ebaa369f26de7d0.webp)

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

حماية آمنة

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

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

تحليل الهيكل

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

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

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

! [الغوص العميق في المعضلة الآمنة: هل يمكن للحارس إعادة بناء برج بابل المضغوط؟] ](https://img-cdn.gateio.im/webp-social/moments-e4f0b0daf2f48ba716dc7fdddcfdabec.webp)

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

في سلسلة هجوم حدثت على منصة تداول معينة، إذا تم نشر عقد Safe مع آلية Guard ذات التكوين المعقول، فإن الهجوم الذي يبدأه المهاجم من خلال execTransaction سيُعترض في مرحلة الفحص المسبق بواسطة استراتيجيات متعددة: أولاً، تتعرف دالة checkTransaction الخاصة بـ Guard على نوع العملية deleGatecall وتفعيل قواعد الحظر (مثل فرض تقييد العملية لتكون فقط استدعاء عادي)، ثم تحلل حقل data لاكتشاف عنوان العقد غير العادي ومحدد الوظائف عالي المخاطر، ومن خلال قائمة بيضاء للعقود وقائمة سوداء للوظائف المحددة مسبقًا، يتم التراجع عن المعاملة مباشرة، مما يؤدي في النهاية إلى تشكيل نظام دفاعي "اعتراض الاستراتيجية → حظر المنطق"، مما يمنع تمامًا مسارات التلاعب بالتخزين وتحويل الأموال.

! [الغوص العميق في المعضلة الآمنة: هل يمكن للحارس إعادة بناء برج بابل المضغوط؟] ](https://img-cdn.gateio.im/webp-social/moments-4947f64f2aa4163ee644b6f8e911c6f8.webp)

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

الاستنتاجات والآفاق

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

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

• التحقق الآلي: إنشاء آلية تحقق تداول آلية
• تعديل السياسات الديناميكية: تعديل سياسات الأمان في الوقت الفعلي بناءً على معلومات التهديد
• الدفاع المتعدد الطبقات: بناء نظام دفاعي عميق يجمع بين آليات الأمان المتنوعة
• التدقيق المستمر: إجراء تدقيق على تنفيذ Guard