سرقة الثقة: كشف هجمات الرسائل العمياء في مصادقة Web3

1. المقدمة والنظرة العامة

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

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

2. هجوم الرسائل العمياء

2.1 نموذج الهجوم والثغرة الأمنية

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

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

2.2 الآلية التقنية

الهجوم هو شكل من أشكال هجوم الرجل في المنتصف (MitM) على مستوى طبقة التطبيق، ولكنه يتم تسهيله بسبب عيوب في التصميم في بروتوكول التفاعل بين المحفظة والتطبيق. واجهة برمجة التطبيقات (API) للمحفظة (مثل eth_requestAccounts، personal_sign) لا تفرض أو تعرض بوضوح البيانات الوصفية السياقية حول النطاق الطالب لجميع أنواع الرسائل، مما يخلق "بقعة عمياء" للمستخدم.

3. الكشف والتخفيف

3.1 أداة Web3AuthChecker

طور المؤلفون Web3AuthChecker، وهي أداة تحليل ديناميكي تتفاعل تلقائيًا مع واجهات برمجة التطبيقات (APIs) المرتبطة بالمصادقة لتطبيق Web3. تتحقق من وجود الثغرة من خلال محاولة محاكاة ناقل هجوم الرسائل العمياء - اعتراض وإعادة توجيه طلبات التوقيع - وتتحقق مما إذا كان يمكن اختراق إدارة الجلسة الخاصة بالتطبيق بواسطة توقيع تم الحصول عليه من مصدر مختلف.

3.2 Web3AuthGuard لميتاماسك

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

4. التقييم والنتائج

4.1 الإعداد التجريبي

قيمت الدراسة 29 تطبيقًا شهيرًا من تطبيقات Web3 عبر فئات تشمل منصات التمويل اللامركزي (مثل Uniswap، Aave)، وأسواق الرموز غير القابلة للاستبدال (مثل OpenSea)، وألعاب Web3. تم نشر Web3AuthChecker لاختبار نقاط نهاية المصادقة الخاصة بها تلقائيًا.

4.2 النتائج والإحصائيات الرئيسية

كانت النتائج مقلقة: 22 من أصل 29 (75.8%) من التطبيقات كانت عرضة لهجمات الرسائل العمياء. يشير هذا الانتشار العالي إلى أن الثغرة منهجية وليست حالة هامشية. أظهر التقييم اللاحق لـ Web3AuthGuard أنه يمكن أن يؤدي إلى تشغيل تنبيهات بنجاح في 80% من تدفقات المصادقة المعرضة للثغرة التي تم اختبارها، مما يثبت جدوى حماية المستخدم في الوقت الفعلي.

وصف الرسم البياني (المتخيل): سيظهر مخطط شريطي "التطبيقات المعرضة للثغرة (22)" أطول بكثير من "التطبيقات الآمنة (7)". سيظهر مخطط ثانٍ الشريط الخاص بـ "التنبيهات الناجحة" لـ Web3AuthGuard يغطي 80% من شريط "تدفقات المصادقة المعرضة للثغرة التي تم اختبارها".

5. الغوص التقني العميق

5.1 الأساس الرياضي

تعتمد مصادقة Web3 على التوقيعات الرقمية باستخدام تشفير المنحنى الإهليلجي، عادةً منحنى secp256k1 المستخدم من قبل إيثيريوم. التحقق الأساسي للتوقيع $(r, s)$ على الرسالة $m$ للمفتاح العام $Q$ (المشتق من العنوان) هو:

$ \text{Verify}(m, (r, s), Q) = \text{true} \quad \text{if} \quad s^{-1} \cdot (eG + rQ)_x \equiv r \ (\text{mod}\ n) $

حيث $e$ هو تجزئة الرسالة $m$، و $G$ هي نقطة المولد، و $n$ هو ترتيب المنحنى. الهجوم لا يكسر هذا التشفير. بدلاً من ذلك، يكسر افتراض البروتوكول بأن $m$ مرتبط بأصل/سياق محدد. فشل الأمن هو $ \text{Context}(m) \neq \text{PerceivedContext}_{user} $.

5.2 مثال على إطار التحليل

دراسة حالة: تحليل تسجيل دخول لوحة تحكم DeFi.

1. الخطوة 1 - الاستطلاع: استخدام Web3AuthChecker لاستدعاء نقطة نهاية واجهة برمجة التطبيقات (API) لتسجيل الدخول للوحة التحليل والتقاط رسالة التحدي $C_d$.
2. الخطوة 2 - محاكاة إعادة التوجيه: تضمين $C_d$ في طلب توقيع تم إنشاؤه بواسطة موقع ضار وهمي $M$.
3. الخطوة 3 - إرسال التوقيع: إرسال التوقيع $\sigma$، الذي تم إنشاؤه عن طريق توقيع $C_d$ في سياق $M$، مرة أخرى إلى نقطة نهاية التحقق الأصلية للوحة التحكم.
4. الخطوة 4 - تأكيد الثغرة: إذا قبلت لوحة التحكم $\sigma$ وأنشأت جلسة، يتم تأكيد هجوم الرسائل العمياء. العيب هو أن لوحة التحكم تتحقق فقط من $\text{Verify}(C_d, \sigma, Q)$، وليس من $\text{Origin}(\sigma) == \text{Dashboard}$.

6. منظور المحلل

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

التدفق المنطقي: منطق البحث لا تشوبه شائبة. ابدأ بفرضية (يمكن إعادة توجيه رسائل المصادقة بشكل ضار)، وبناء أداة (Web3AuthChecker) للاختبار على نطاق واسع، واكتشاف انتشار مذهل (75.8%)، ثم هندسة إجراء مضاد عملي (Web3AuthGuard) لإثبات إمكانية التخفيف. تعيين معرفات CVE يضفي الطابع الرسمي على التهديد، وينقله من مفهوم أكاديمي إلى ثغرة يجب تصحيحها.

نقاط القوة والضعف: تكمن القوة في ناقل الهجوم المدمر في بساطته، والذي تم تجاهله سابقًا، وتأثيره الهائل على أرض الواقع. دفاع النموذج الأولي عملي. العيب، كما هو الحال في الكثير من أبحاث أمن الأنظمة، هو أن Web3AuthGuard هو مجرد لصقة مؤقتة. يضيف فحصًا حيث يجب أن يفرض البروتوكول نفسه الأمان. يتطلب الإصلاح طويل الأمد من مزودي المحافظ (مثل ميتاماسك) وهيئات المعايير (مثل EIP-712) إلزام ربط السياق النطاقي تشفيريًا بالرسالة القابلة للتوقيع. الاعتماد على المستخدمين للانتباه إلى التحذيرات ثبت فشله، كما يتضح من عقود من أبحاث التصيد الاحتيالي.

رؤى قابلة للتنفيذ: للمطورين: تدقيق تدفق المصادقة الخاص بك على الفور. لا تتحقق فقط من التوقيع؛ تحقق من أن أصل التوقيع يطابق نطاقك من خلال ربط الجلسة. لبناة المحافظ: هذا إنذار عاجل. نفذ توقيع البيانات المنظمة EIP-712 مع فصل النطاق الإلزامي واجعله الافتراضي لجميع طلبات المصادقة. اعرض طلبات personal_sign غير الموثوقة والنص العادي بواجهة مستخدم تحمل علامات تحذيرية واضحة. لهيئات المعايير: سرع مسارات البروتوكولات التي تجعل هجمات إعادة التوجيه مستحيلة تشفيريًا، وليس مجرد التحذير منها بصريًا. لقد انتهى وقت الاقتراحات المهذبة؛ نظام DeFi بقيمة 52 مليار دولار يتطلب بدائيات أمنية قوية.

7. التطبيقات المستقبلية والاتجاهات

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

1. حلول على مستوى البروتوكول: اعتماد وإنفاذ واسع النطاق لـ EIP-712 وخلفائه، مما يسمح بكتابة الرسائل وهيكلتها بمعلمات نطاق قابلة للتحقق، مما يجعلها غير قابلة لإعادة التوجيه.
2. تكامل محفظة الأجهزة: تمديد التحقق السياقي إلى شاشات محفظة الأجهزة، التي تعرض حاليًا أيضًا بيانات رسائل محدودة.
3. التحقق الرسمي لتدفقات المصادقة: تطبيق الطرق الرسمية، المشابهة لتلك المستخدمة للعقود الذكية (مثلًا في إطار KEVM)، للتحقق من خصائص الأمان لبروتوكول المصادقة خارج السلسلة نفسه.
4. كاشفات التعلم الآلي: البناء على أدوات مثل Web3AuthChecker لإنشاء أنظمة مراقبة مستمرة لمتاجر التطبيقات اللامركزية (dApp) أو مدققي الأمن الذين يرفعون علمًا تلقائيًا لعمليات تنفيذ المصادقة المعرضة للثغرة.
5. تقارب الهوية اللامركزية (DID): يؤكد هذا العمل الحاجة إلى معايير مصادقة DID أكثر قوة (مثل بيانات اعتماد W3C القابلة للتحقق) التي يتم تصميمها مع وضع نواقل الهجوم هذه في الاعتبار منذ البداية.

8. المراجع

1. Yan, K., Zhang, X., & Diao, W. (2024). Stealing Trust: Unraveling Blind Message Attacks in Web3 Authentication. Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security (CCS’24).
2. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
3. MetaMask. https://metamask.io
4. EIP-712: Ethereum Typed Structured Data Hashing and Signing. https://eips.ethereum.org/EIPS/eip-712
5. Atzei, N., Bartoletti, M., & Cimoli, T. (2017). A survey of attacks on Ethereum smart contracts (SoK). Principles of Security and Trust.
6. Zhuang, Y., et al. (2020). Tools and benchmarks for automated log parsing. IEEE International Conference on Software Engineering (ICSE). (Example of rigorous tool evaluation methodology).
7. DeFi Llama. Total Value Locked Statistics. https://defillama.com