لا يقتصر على المفاتيح الخاصة: من المحافظ وL2 إلى سلسلة التوريد، كيف نحمي حدود أمان Web3؟

شهد عالم التشفير في شهر يونيو المنصرم سلسلة من الحوادث الأمنية امتدت عبر مراحل متعددة.

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

عندما يتوسع خطر الأمن في Web3 من مدخل واحد ليشمل مسار التفاعل الكامل على السلسلة، يضطر كل مستخدم إلى إعادة التفكير في سؤال واحد: هل أصولي المشفرة لا تزال آمنة؟

أولاً: أهمية تنفيذ التوقيع الأساسي في المحفظة بخلاف المفاتيح الخاصة

الحادثة التي وقعت في محفظة SecondFi التابعة لمنصة Cardano البيئية في يونيو هي المثال الأوضح.

SecondFi هي الاسم الجديد لمحفظة Yoroi في نظام Cardano. من 21 إلى 23 يونيو، قام المهاجم بتحويل حوالي 16 مليون ADA من عناوين بعض مستخدمي SecondFi، والتي شملت حوالي 374 محفظة، بقيمة تقدر بحوالي 2.4 مليون دولار وفقًا لأسعار وقت الحادثة. وأعلنت SecondFi لاحقًا أنها تمكنت من حماية حوالي 129 مليون ADA إضافية كانت معرضة للخطر عبر إجراءات طارئة.

الأكثر خصوصية في هذه الحادثة هو أن المستخدمين المتأثرين لم يسلموا عبارات الاسترداد (mnemonic) بنشاط للمهاجم، بل كانت المشكلة في تنفيذ التوقيع الأساسي للمحفظة. وفقًا لتحليل شركة الأمن BlockSec، كان الخطأ هو اشتقاق nonce التوقيع بشكل خاطئ من رسائل المعاملات العامة، مع إغفال البادئة السرية (nonce prefix) التي تتطلبها التطبيقات المعيارية.

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

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

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

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

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

بالنسبة للمستخدمين العاديين، تقابل هذه الحوادث عدة مبادئ أمان أكثر واقعية.

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

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

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

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

ثانيًا: الطبقة الثانية (L2) ليست فقط "إيثريوم أرخص"، بل سلسلة معقدة من الثقة

بالإضافة إلى المحافظ، سلطت حوادث يونيو الضوء على المخاطر التي تهدد أنظمة الطبقة الثانية المتزايدة التعقيد.

في 14 و18 يونيو، تعرضت نشرات قديمة من Rollup ترتبط بـ Aztec لهجمات، مما أسفر عن خسائر إجمالية تقدر بحوالي 4.35 مليون دولار.

من المهم التوضيح أن الهجمات استهدفت النشرات القديمة مثل Aztec Connect التي هي في حالة إرث (legacy)، ولا تعادل هجومًا على الشبكة الرئيسية الحالية لـ Aztec Network نفسها. لكن المشكلات التي كشفتها الحادثتان تحمل دروسًا تحذيرية لمجال ZK Rollup بأكمله.

في إحدى الحوادث، استغل المهاجم عدم الاتساق بين عدد المعاملات وبيانات المعالجة الفعلية، مما سمح للنظام بتسجيل إيداع داخل الدليل (proof) مع تجاوز عملية خصم الرصيد المقابلة على L1.

أما الحادثة الأخرى فكانت بسبب نقص في القيود (constraints) في دائرة إثباتات المعرفة الصفرية (ZK circuit). وثق النظام دليلاً صحيحًا شكليًا، لكنه لم يضمن أن شجرة الحالة الخاصة (private state tree) التي استخدمها الدليل مطابقة تمامًا لجذر الحالة العامة (public state root) المستخدم فعليًا للتسوية على إيثريوم. لذلك تمكن المهاجم من إنشاء دليل حول شجرة حالة مزيفة واستخراج الأصول من العقود على L1.

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

أما الحادثة الأمنية التي تلت ذلك في Taiko فكشفت عن نوع آخر من مخاطر سلسلة الثقة في L2.

في 22 يونيو، تم استغلال عملية التحقق من الدليل المستندة إلى SGX في Taiko، مما تسبب في خسائر تقدر بحوالي 1.7 مليون دولار. وفقًا لتحليل BlockSec، استخدم المهاجم مفتاح توقيع خاص ببيئة enclave من SGX كان قد تم نشره سابقًا في مستودع عام على GitHub، مع استغلال الثغرة المتمثلة في عدم رفض عقد التحقق على السلسلة لوضع تصحيح (Debug mode) في Enclave، مما سمح بتسجيل مُثبت ضار كمثال قانوني.

ثم زور المهاجم دليلاً لحالة L2، مما جعل العقد على إيثريوم يقبل حالة L2 غير موجودة، واستخرج الأصول في النهاية من الأموال المجسورة (bridged funds). في النهاية، كان السبب هو أن المفتاح المستخدم لتوقيع بيئة التنفيذ الموثوقة (TEE) كان عامًا، ولم تتحقق قواعد التحقق عن بُعد (remote attestation) بشكل كامل من خصائص بيئة التشغيل، مما جعل دليلاً "معتمدًا" يفقد معناه الموثوق به الأصلي.

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

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

لأنه بالنسبة للمستخدم، ما إذا كانت السلسلة آمنة لا يعتمد فقط على ما إذا كان القراصنة يمكنهم تزوير الأصول، بل يعتمد أيضًا على ما إذا كانت الكتل تستمر في الإنتاج، وما إذا كانت الجسور عبر السلاسل (cross-chain bridges) تعمل بشكل طبيعي، وما إذا كانت العقد يمكن أن تتعافى بسرعة، وما إذا كان لدى المستخدمين مسار خروج قابل للتطبيق عند حدوث خلل في النظام.

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

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

ثالثًا: عندما لا يتم اختراق العقد الذكي، قد تنقل خدمات الطرف الثالث الهجوم إلى المستخدم

إذا كانت مشكلات المحفظة وL2 لا تزال تحدث في مكونات تقنية أساسية نسبيًا، فإن حادثة Polymarket تظهر أن الواجهة الأمامية (front-end) الأقرب إلى المستخدم يمكن أن تصبح أيضًا مدخلاً للأموال.

في 25 يونيو، أفادت Polymarket بأن أحد موردي الطرف الثالث الذي تستخدمه تعرض للاختراق، مما سمح للمهاجم بحقن نصوص خبيثة (scripts) في واجهة Polymarket الأمامية التي يصل إليها بعض المستخدمين.

وفقًا لإحصاءات شركات الأمن والمحللين على السلسلة، تسبب الحادث في خسائر أصول المستخدمين تقدر بحوالي 3 ملايين دولار، شملت حوالي 11 محفظة. تم بعد ذلك تحويل الأموال المسروقة من Polygon عبر السلسلة إلى Ethereum، واستبدالها بحوالي 1,893 ETH. لاحقًا أعلنت Polymarket أنها أزالت التبعية المتأثرة وستقوم برد كامل المبالغ للمستخدمين المتأثرين.

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

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

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

استخدام محفظة تفاعل مستقلة لـ DApps: حاول عدم توصيل محفظة الادخار طويلة الأجل مباشرة بمواقع DeFi وNFT والأسواق التنبؤية والإنزال الجوي. قم بتخزين الأموال المعدة للاستخدام الحديث فقط في محفظة التفاعل اليومي، بحيث يكون التأثير محدودًا حتى في حال حدوث مشكلة في الواجهة أو التصريح.

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

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

من منظور منتجات المحافظ، هذا يعني أن الدور الذي تلعبه المحفظة يتغير.

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

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

في الختام

في الماضي، كان يقال: من يملك المفتاح الخاص، يملك الأصول على السلسلة.

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

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

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

مع أطيب التمنيات للجميع.