تحليل تقني لسرقة جسر Wormhole: استغلال بقيمة 326 مليون دولار

في 2 فبراير 2022، خسر جسر توكن Wormhole 120,000 وحدة من wETH — بقيمة تقارب 326 مليون دولار في ذلك الوقت — في واحدة من أكبر حوادث استغلال العقود الذكية في تاريخ DeFi. لم يتطلب الهجوم سرقة مفاتيح، هندسة اجتماعية، أو سيطرة على أغلبية شبكة المصادقة Guardian. كان يتطلب شيئًا واحدًا فقط: واجهة برمجة تطبيقات برنامج Solana مهملة فشلت في التحقق من الحساب الذي كانت تقرأ منه.

فهم هذا الاستغلال ضروري لكل فريق يبني على Solana، لكل بروتوكول يعتمد على الرسائل عبر السلاسل، ولكل مدقق يفحص برامج Solana. السبب الأساسي كان خللًا في التحقق من العقد الذكي في برنامج جسر Wormhole الخاص بـ Solana — وليس اختراق للمفاتيح، ولا فشل في شبكة Guardian. لم تُلمس مفاتيح Guardian أبداً. كود الجسر نفسه منح المهاجم صلاحية لم يكن يجب أن يمنحها.

ما هي الثغرة التقنية الأساسية في هجوم Wormhole؟

الثغرة كانت في الأمر verify_signatures في برنامج جسر Wormhole الخاص بـ Solana (bridge.so). هذه الدالة كانت مسؤولة عن التحقق من أن حساب SignatureSet — الذي يحتوي على توقيعات Ed25519 أو Secp256k1 من عقد Guardian — يمثل إجماعًا حقيقياً قبل منح إذن إجراء اعتماد قابل للتحقق (VAA).

الخلل: استخدم verify_signatures الدالة المهجورة solana_program::sysvar::instructions::load_instruction_at للتحقق من أنه قد تم استدعاء تعليمات Secp256k1 للتحقق القبلي سابقًا في نفس المعاملة. النسخة المهجورة لا تتحقق من أن الحساب الممرر إليها هو فعلاً الـ sysvar الخاص بتعليمات Solana (Sysvar1nstructions1111111111111111111111111). بل تقرأ من أي حساب يقع في الفهرس المسمى — بما في ذلك حساب يتحكم فيه المهاجم بالكامل.

بالتالي يمكن للمهاجم تمرير حساب مزيف يحاكي تخطيط تعليمات sysvar، مسبق التعبئة ببيانات توقيع يتحكم بها المهاجم على حمولة يختارها هو. تقرأ الدالة البيانات المزيفة، وتجد أن استدعاء Secp256k1 “موجود” (في سياق مختلف تمامًا)، وتعتبر VAA معتمدة من Guardian، وتُرجع النتيجة ناجحة.

مع وجود VAA تم اعتماده زوراً، قام المهاجم باستدعاء complete_wrapped، التي تثق بموافقة VAA من برنامج الجسر للسماح بصك أصول مغلفة على Solana. النتيجة: صك 120,000 وحدة wETH بدون أي ETH مقابلها مقفل على Ethereum.

تم إصلاح المشكلة — باستبدال load_instruction_at بـ load_instruction_at_checked التي تفرض أن الحساب هو فعلاً تعليمات sysvar — قبل ظهور الاستغلال على مستودع GitHub الخاص بـ Wormhole، لكنه لم يُنشر بعد على الشبكة الرئيسية.

كيف اختلف استغلال Wormhole عن هجمات الجسور الأخرى مثل Ronin؟

هجوم جسر Ronin (مارس 2022، حوالي 625 مليون دولار) يُذكر غالبًا مع Wormhole عند مناقشة إخفاقات أمن الجسور. لكنهما يمثلان نماذج مختلفة جوهريًا للفشل.

Wormhole كان خلل تحقق عقد ذكي في برنامج جسر Solana. شبكة Guardian — وهي تجمع توقيعات عتبية يضم 19 عقدة — لم تُخترق قط. تجاوز المهاجم الشبكة بالكامل عبر استغلال عدم تحقق verify_signatures من الحساب الذي تقرأ منه. مفاتيح Guardian لم تُلمس، الشبكة كانت تعمل، وكان ذلك غير ذي صلة: الكود لم يستشر وحتى لم يطلب إجماع Guardian الحقيقي.

Ronin كان سرقة مفاتيح تشغيلية. Sky Mavis كانت تدير خمسة من أصل تسع عقد تحقق في Ronin. في نوفمبر 2021، وُفّقت Axie DAO مؤقتًا لتفويض سلطة التوقيع إلى Sky Mavis لتحمل ضغط المعاملات. التفويض لم يُلغَ عند انتهائه. مهاجم — يُعتقد لاحقًا أنه مجموعة لازاروس — اخترق أنظمة Sky Mavis الداخلية وحصل على مفتاح التحقق لأربع عقد. باستخدام تفويض Axie DAO النشط، حصل على التوقيع الخامس عبر عقدة RPC المعفية من الغاز الخاصة بـ Sky Mavis. مع خمسة من تسعة توقيعات صحيحة، قدم رسائل سحب شرعية إلى عقد جسر Ronin. لم يُستغل أي خلل في العقد الذكي. الجسر عمل كما صُمم عندما استقبل خمسة توقيعات تحقق أصلية — وهّج عمليات السحب.

خطوة بخطوة: كيف نُفذ استغلال Wormhole

1. انتحال الحساب. أنشأ المهاجم حساب Solana يحاكي البنية المتوقعة في موضع SignatureSet ببيانات تعليمات برنامج جسر Wormhole. هذا الحساب يتضمن توقيعات يتحكم بها المهاجم — توقيعات Ed25519/Secp256k1 صحيحة لكن على حمولة VAA يختارها المهاجم تسمح بصك 120,000 wETH إلى عنوانه على Solana.

2. تجاوز عبر واجهة sysvar المهجورة. قدم المهاجم معاملة تستدعي verify_signatures على برنامج جسر Wormhole الخاص بـ Solana. استدعى البرنامج الدالة load_instruction_at — النسخة المهجورة وغير المختبرة — لتأكيد أن تعليمات Secp256k1 قد نُفذت في نفس المعاملة سابقًا. هذه الدالة تقرأ من أي حساب في الفهرس المسمى دون التحقق من أنه تعليمات sysvar الحقيقية.

3. قبول دليل مزور. تجول verify_signatures عبر التوقيعات الموجودة في الحساب الذي يسيطر عليه المهاجم، وجده مشفرًا بشكل صحيح (لأن المهاجم نفسه وقع عليه على حمولته)، واعتبر VAA معتمدًا من Guardian. شبكة Guardian لم تُستشار أبداً.

4. السماح بالصك. استدعى المهاجم complete_wrapped مع VAA المعتمد الآن. برنامج الجسر، لأنه يثق بحالة موافقة VAA، صك 120,000 wETH على Solana لعنوان المهاجم.

5. استخراج عبر السلاسل. قام المهاجم بربط wETH المصك على Solana مرة أخرى إلى Ethereum عبر التدفق المشروع للجسر عبر السلاسل — لأن wETH كان في محفظة المهاجم على Solana، عالج الجسر السحب كمعاملة عادية. وهبطت الـ 326 مليون دولار من wETH غير المدعوم على Ethereum، حيث حوّلها إلى ETH وعملة مستقرة وخرج بأموال المطالبة. شركة Jump Crypto، الشركة الأم لـ Wormhole، عوضت 120,000 ETH المسروقة من احتياطياتها لتعويض مستخدمي الجسر.

أهم الدروس التقنية لبرامج Solana وجسور عبر السلاسل

1. كل AccountInfo يمرر إلى برنامج Solana يعتبر تحت سيطرة المهاجم حتى يثبت العكس.

هذه هي القاعدة الأساسية لأمان برامج Solana. يجب على البرنامج التحقق من owner وkey و — حيثما ينطبق — executable و is_signer لكل حساب يستقبله. الدالة المهجورة load_instruction_at قبلت أي حساب وضع في الفهرس المسمى. البديل الحديث load_instruction_at_checked يفرض أن الحساب هو تعليمات sysvar الحقيقية قبل قراءته. منهج تدقيق Soken لبرامج Solana يعتبر أي استخدام لواجهات sysvar غير _checked على أنها ثغرة حرجة بغض النظر عن السياق.

2. الفصل في الصلاحيات بين التحقق من التوقيع وصك الأصول.

يجب أن تكون سلطة الصك في الجسر خلف وحدة تحقق تعيد استنتاج الإثبات من حالة معيارية مملوكة للبرنامج — وليس من حسابات مزودة من المتصل. عندما قبل verify_signatures حسابًا يسيطر عليه المهاجم كمصدر للحقيقة، انهار الفصل بين “هل الشبكة وافقت؟” و “هل يمكننا الصك؟” تمامًا. يجب أن تستمد التعليمات الصك الإذن من الحالة التي كتبها البرنامج بنفسه بعد التحقق من مدخلات Guardian الحقيقية.

3. يجب فرض حماية إعادة تشغيل VAA على السلسلة.

حتى لو كان SignatureSet صحيحًا، يجب أن ترفض complete_wrapped VAAs ذات الهاشيات المستخدمة سابقًا. أضاف Wormhole حماية إعادة التشغيل في نسخ لاحقة، لكن غيابها في النسخة المستغلة يعني أن VAA المعتمد زورًا يمكن إعادة استخدامه عدة مرات. كل إجراء جسر يجب أن يُقيّد على خريطة VAA معالج (مثل processed_vaas: mapping[bytes32, bool]) يتم تحديثها بشكل ذري في بداية التنفيذ.

4. استخدام API مهجور هو ثغرة حرجة في التدقيق.

ثغرة Wormhole كانت معروفة كوظيفة مهجورة. حزمة تطوير Solana (SDK) وسمت load_instruction_at كمتهالك وقدمت البديل _checked قبل حدوث الاستغلال. عدم الانتقال من API مهجور ليس فقط مسألة جودة كود — بل هو فجوة أمنية حرجة يبحث عنها المهاجمون بفحص سجلات التغييرات ومقارنة الالتزامات غير المنشورة مع البايتكود المنشور. تدقيقات برامج Solana يجب أن تفحص solana_program::sysvar::instructions::* للنسخ غير _checked وأن تعتبرها خطأً حرِجًا. هذا ممارسة قياسية في تدقيقات Solana بعد 2022 في Ottersec، Halborn، وSoken.

5. الإصلاحات الأمنية غير المنشورة تمثل خرائط هجوم عامة.

كان إصلاح load_instruction_at_checked قد تم دمجه على مستودع Wormhole العام قبل الهجوم. المهاجم الذكي الذي يراقب مستودعات البروتوكول المهددة للالتزامات الأمنية — خاصة التي تستبدل APIs مهجورة بـ equivalents المختبرة — يمكنه إعادة بناء الثغرة من الفرق وحده. يجب أن تتعامل خطوط نشر البرامج الأمنية مع الفجوة بين “الاندماج في الفرع الرئيسي” و”النشر على الشبكة الرئيسية” كنافذة تعرض نشطة. يجب أن تغلق إجراءات النشر الطارئة هذه النافذة في ساعات لا أيام.

6. التوقيعات العتبية لا تعوض عن فشل تحقق الحسابات.

شبكة Guardian لـ Wormhole تتكون من 19 عقدة مستقلة تشغل نظام توقيعات عتبية. كانت قوية. وكانت بلا أهمية لهذا الهجوم. استغل الاستغلال حقيقة أنه يمكن التلاعب بالحساب الذي تقرأ منه دالة verify_signatures لتجاوز كامل طبقة الإجماع. التوقيعات العتبية تحمي من اختراق مفاتيح Guardian؛ لكنها لا تحمي إطلاقًا من خطأ لا يطلب مدخلات Guardian على الإطلاق. الدفاع العمقي يتطلب بالفعل تنفيذ كل طبقة من نموذج الأمان — التحكم المتجاوز ليس تحكمًا على الإطلاق.

ماذا يعني هذا لتدقيقات الجسور وأمان برامج Solana

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

بالنسبة للفرق التي تبني على Solana، دروس التحقق من الحساب عامة: اعتبر كل معلمة تمرر لبرنامجك أنها مدخلة عدائية. تحقق من المالك، المفتاح، المميز، وطول البيانات قبل العمل على أي حساب. استخدم غلاف Account<T> في إطار العمل anchor أو ما يعادله لفرض هذه التحققات على مستوى النوع بدلاً من الاعتماد على التأكيد اليدوي.

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

تقوم Soken بتدقيق كل برنامج Solana للكشف عن استخدام واجهات sysvar المهجورة، غياب تحقق مالك الحساب، وفجوات حماية إعادة تشغيل VAA باعتبارها نقاط حرجة. نمط Wormhole — تجاوز عملية التوقيع العتبية بالتلاعب بالحساب الذي تقرأ منه دالة التحقق — أصبح الآن فئة معروفة من الهجمات في منهجية تدقيق Solana لدينا. إذا كان بروتوكولك يستخدم رسائل عبر السلاسل أو صك الأصول المغلفة، اتصل بنا عبر soken.dev/services-it.html لمناقشة مراجعة أمنية قبل النشر.