خلفية
Blast عبارة عن شبكة Ethereum Layer 2 أطلقها Pacman (Tieshun Roquerre، المعروف أيضًا باسم Tieshun)، مؤسس Blur. أطلقت الشبكة الرئيسية في 29 فبراير. حاليًا، تم التعهد بحوالي 19,500 ETH و640,000 stETH على شبكة Blast الرئيسية.
مشروع Munchables الذي تمت مهاجمته هو مشروع عالي الجودة فاز في مسابقة Bigbang التي نظمتها Blast.
سيصدر مسؤولو Blast نقاطًا عادية للمستخدمين الذين يتعهدون بـ ETH على شبكة Blast الرئيسية:
من أجل تشجيع المستخدمين على المشاركة في مشاريع DeFi على نظام Blast البيئي، سيختار مسؤولو Blast مشاريع عالية الجودة للتوصية ويشجعون المستخدمين على التعهد بـ ETH مرة ثانية في DeFi للحصول على زيادة أسرع في النقاط والنقاط الذهبية، لذلك هناك فرصة كبيرة تعهد عدد قليل من المستخدمين بتقديم ETH على شبكة Blast الرئيسية لمشروع DeFi الذي تم إنشاؤه حديثًا.
لم يتم بعد فحص مدى نضج وأمن مشاريع DeFi هذه، وما إذا كانت هذه العقود لها اعتبارات أمنية كافية لحماية عشرات الملايين أو حتى مئات الملايين من الدولارات للمستخدمين.
نظرة عامة على الحدث
بعد أقل من شهر من اتصال شبكة Blast الرئيسية بالإنترنت، وقع هجوم على SSS Token (Super Sushi Samurai) في 21 مارس 2024. كان هناك خطأ في منطق النقل في عقد Token، مما سمح للمهاجم بزيادة رمز SSS الخاص بالشبكة. بسبب حساب محدد من فراغ، فقد المشروع في النهاية أكثر من 1,310 إيثريوم (حوالي 4.6 مليون دولار).
بعد أقل من أسبوع من هجوم SSS Token، وقع هجوم أكبر آخر على Blast، حيث اجتاح المهاجمون مشروع Munchables بمبلغ 17413.96 ETH، أي ما مجموعه 62.5 مليون دولار أمريكي تقريبًا.
بعد نصف ساعة من حدوث معاملة الهجوم، تمت سرقة 73.49 WETH في عقد المشروع أيضًا بواسطة متسلل من عنوان آخر.
في الوقت الحالي، لا يزال هناك 7276 WETH، و7758267 USDB، و4 ETH مخزنة في عنوان العقد الخاص بطرف المشروع، والتي ستقع في أيدي المتسللين في أي وقت. ويتمتع المتسلل بسلطة الاستيلاء على جميع أموال المشروع المشروع بأكمله والذي تبلغ قيمته الإجمالية حوالي 97 مليون دولار أمريكي معرض للمخاطر.
مباشرة بعد الحادث، أشار المحقق الشهير zachXBT التابع لشركة X (Twitter) إلى أن السبب الجذري لهذا الهجوم هو توظيف قراصنة من بلد معين.
دعونا نلقي نظرة فاحصة على كيفية قيام “هاكر من دولة معينة” بإتمام هجوم بقيمة 100 مليون دولار تقريبًا.
الترميم في الموقع
الضحايا يتحدثون علناً
[UTC+ 0] في الساعة 21:37 يوم 26 مارس 2024 (بعد 5 دقائق من الهجوم)، نشرت شركة Munchables رسميًا على موقع X (تويتر) تفيد بأنها تتعرض للهجوم.
وفقًا للتحقيق الذي أجراه المحقق زاك، جاء المهاجم للقيام ببعض أعمال تطوير اللعبة. لقد كان قاسيًا جدًا وبدا حقًا مثل المتسلل الصيني. قمنا بطرده في غضون شهر. كما حاول إقناعنا بتوظيف أحد موظفيه الأصدقاء، والذي ربما كان أيضًا هاكرًا.
نظرًا لأن هذا الهجوم تسبب في خسائر فادحة للمستخدمين في المجتمع، فقد أطلقنا على الفور تحقيقًا على السلسلة، دعونا نلقي نظرة متعمقة على تفاصيل الهجوم لهذا “المتسلل من بلد معين”.
المشهد الاول
[UTC+ 0] في الساعة 21:32 يوم 26 مارس 2024، وقع هجوم يشمل 17413.96 إيثريوم.
من خلال Blastscan يمكننا رؤية معاملة الهجوم هذه:
العقد التالف (0x 29…1 F) هو عقد وكيل يخزن الأموال المرهونة للمستخدم. يمكننا أن نرى أن المهاجم استدعى وظيفة إلغاء القفل لعقد التعهد، واجتاز جميع عمليات التحقق من الأذونات، وقام بتحويلها بعيدًا. ينتقل العقد إلى عنوان المهاجم 1 (0x6 E…c 5).
يبدو أن المهاجم استدعى وظيفة إلغاء القفل بسلوك يشبه السحب وأخذ معظم ETH من العقد المخترق (0x 29…1 F).
هل نسي فريق المشروع قفل القبو؟
هناك فحصان مرتبطان بالفتح في العقد التالف (0x 29…1 F)، فلننظر إليهما واحدًا تلو الآخر.
أولاً، وجدنا أنه أثناء عملية التحقق من الإذن، تم استدعاء الطريقة isRegistered للعقد (0x 16…A 0) للتحقق مما إذا كان msg.sender الحالي، أي عنوان المتسلل 1 (0x 6 E…c) 5) مسجل بالفعل:
الجواب هو: اجتاز التحقق.
يتضمن ذلك العقد (0x 16…A 0) وأحدث عقد منطقي مطابق له (0x e 7…f 1)
[UTC+ 0] في الساعة 08:39 يوم 24 مارس 2024 (قبل يومين من الهجوم)، تمت ترقية العقد المنطقي المقابل للعقد (0x16…A 0).
معاملة ترقية العقد المنطقي:
يتم تحديث العقد المنطقي إلى 0x e 7…f 1 .
يمكن رؤية عنوان العقد المنطقي الأصلي هنا، وهو 0x 9 e…CD.
في هذا الوقت، نشتبه في أن المتسلل قام بتحديث عقد التنفيذ المنطقي لعقد الوكيل، والذي سيكون 0x 9 e… القرص المضغوط يصبح ضارًا 0x e 7…f 1 ، استكمال تجاوز أذونات التحقق.
هل هو حقا؟
في Web3.0، لن تحتاج أبدًا إلى التخمين أو الاستماع إلى الآخرين، ما عليك سوى إتقان التكنولوجيا للحصول على الإجابة بنفسك.
من خلال مقارنة العقدين (وليس العقود مفتوحة المصدر)، هناك بعض الاختلافات الواضحة بين عقد 0x 9 e…CD الأصلي وعقد 0x e 7…f 1 المحدث:
يتم تنفيذ جزء وظيفة التهيئة من 0x e 7…f 1 على النحو التالي:
يتم تنفيذ جزء وظيفة التهيئة من 0x 9 e…CD على النحو التالي:
يمكن ملاحظة أن المهاجم قام بتعيين عنوان المهاجم (0x 6 e…c 5) كتسجيل في العقد المنطقي الأصلي (0x 9 e…CD)، وهناك أيضًا عنوانان آخران للمهاجم 0x c 5 …0 تم أيضًا تسجيل d,0x bf…87، ويتم ضبط الحقل الخاص بهم 0 على وقت الكتلة أثناء التهيئة، وسيتم شرح استخدام الحقل 0 لاحقًا.
في الواقع، على عكس ما توقعناه، فإن العقد المنطقي الحقيقي مع الباب الخلفي كان موجودًا منذ البداية، وكانت التحديثات اللاحقة طبيعية!
انتظر، ظهر هذا التحديث في تمام الساعة 08:39 يوم 24 مارس 2024 [UTC+0] (قبل يومين من الهجوم). أي قبل هذا الحادث، كان العقد المنطقي قد أصبح عقدًا بدون أبواب خلفية. لماذا؟ لا يزال بإمكان المهاجم إكمال الأمر الهجوم؟
هذا بسبب مندوب الاتصال، وبالتالي فإن تحديث تخزين الحالة الفعلي موجود في العقد (0x 16…A 0)، مما يؤدي إلى حقيقة أنه حتى لو تم تحديث العقد المنطقي لاحقًا إلى العقد المنطقي بدون باب خلفي 0x e 7… f 1 ، لن تتم استعادة الفترة التي تم تغييرها في العقد (0x 16…A 0).
دعونا التحقق من ذلك:
كما ترون، فإن الفتحة المقابلة في العقد (0x 16…A 0) لها قيمة عددية.
يسمح هذا للمهاجم باجتياز فحص طريقة isRegistered:
قام المهاجم لاحقًا بتغيير عقد الباب الخلفي إلى عقد عادي لإخفاء حقيقة أن الباب الخلفي قد تم زرعه بالفعل.
بالإضافة إلى ذلك، تتضمن عملية إلغاء القفل أيضًا عملية تحقق ثانية:
فيما يتعلق بفحص وقت القفل، يهدف هذا الجزء إلى التأكد من عدم نقل الأصول المقفلة قبل انتهاء الصلاحية.
يحتاج المهاجم إلى التأكد من أن وقت الحظر عند استدعاء إلغاء القفل أكبر من وقت انتهاء صلاحية القفل المطلوب (الحقل 3).
يتضمن هذا الجزء من التحقق العقد التالف (0x 29…1 F) والعقد المنطقي المقابل 0x f 5…cd.
في معاملة تمت الساعة 11:54 يوم 21 مارس 2024 [UTC+ 0] (قبل 5 أيام من الهجوم)،
يمكننا أن نرى أن العقد المنطقي الأصلي للعقد التالف (0x29…1 F) كان 0x91…11، وبعد أربع دقائق فقط، في
تمت الترقية إلى 0x f 5…cd.
قمنا أيضًا بمقارنة العقدين ويمكننا أن نجد أن المهاجم قام أيضًا بحيل في وظيفة التهيئة كما كان من قبل.
التنفيذ الجزئي لوظيفة التهيئة لـ 0x f 5…cd:
التنفيذ الجزئي لوظيفة التهيئة لـ 0x 91…11:
يمكن ملاحظة أنه من الواضح أنه تم استخدام نفس الطريقة مرة أخرى للتلاعب بكمية ETH ووقت الفتح، ثم استبدالها بالعقد العادي لخداع الآخرين، وعندما كان فريق المشروع والباحثون الأمنيون يقومون بتصحيح الأخطاء، تم اكتشاف كل شيء العقود المنطقية التي نراها طبيعية، ولأن العقود كلها عقود غير مفتوحة المصدر، فمن الصعب رؤية جوهر المشكلة بوضوح.
حتى الآن، نحن نفهم هذه المعاملة التي تتضمن 17413 ETH وكيف قام المهاجم بذلك، ولكن هل يوجد هذا القدر من المعلومات وراء هذا الحادث؟
في تحليلنا أعلاه، رأينا بالفعل أن المتسلل قام ببناء 3 عناوين في العقد:
0x 6 e…c 5 (عنوان المهاجم 1)
0x ج 5…0 د (عنوان المهاجم 2)
0x bf…87 (عنوان المهاجم 3)
ومع ذلك، لم نر سوى 0x 6 e…c 5 في معاملة الهجوم التي وجدناها أعلاه، فماذا فعل العنوانان الآخران؟ وما هي الأسرار المخفية في العنوان (0)، _dodoApproveAddress، _uniswapV3Factorty؟
المشهد الثاني
دعونا أولاً نلقي نظرة على عنوان المهاجم 3 (0x bf…87)، الذي سرق 73.49 WETH بنفس الطريقة:
ومهاجمة عنوان مصدر الغاز (0x 97…de)، وتوفير رسوم المناولة لكل من 0x c 5…0 d (عنوان المهاجم 2) و0x bf…87 (عنوان المهاجم 3).
مصدر 0.1 ETH الذي يهاجم عنوان مصدر الغاز (0x 97…de) يأتي من owlto.finance (جسر عبر السلسلة).
0x c 5…0 d (عنوان المهاجم 2) لم ينفذ أي هجوم بعد حصوله على رسوم المناولة، لكنه في الواقع كان يحمل خطة مخفية، فلنواصل النظر إليها.
في الواقع، وفقًا لمعاملة الإنقاذ الرسمية، لم يكن العنوان الأصلي للعقد التالف (0x 29…1 F) 73.49 WETH فقط، بل كان لا يزال هناك 7276.5 WETH و7758267 USDB حتى نهاية الهجوم.
صفقة الإنقاذ:
لقد خطط المهاجم في الأصل لسرقة هذه الأصول، ويمكنك أن ترى أن العنوان 0x c 5…0 d (عنوان المهاجم 2) تم استخدامه في الأصل لسرقة USDB.
_dodoApproveAddress هنا هو 0x0000000000000000430000000000000000000000000000003
هو عنوان usb
0x bf…87 (عنوان المهاجم 3) يُستخدم هذا العنوان لسرقة ما يلي:
مصنع _uniswap V3 هنا هو 0x000000000000000043000000000000000000000000000004
هو عنوان ويث
و0x 6 e…c 5 (عنوان المهاجم 1) مسؤول عن سرقة العنوان (0)، وهو الأصل الأصلي ETH.
من خلال تعيين الحقل 0، يمكن للمهاجم سرقة الأصول المقابلة من خلال المنطق التالي:
سؤال
لماذا لم يسرق المهاجم جميع الأصول؟
من الناحية النظرية، يمكنه سرقة جميع الأصول، أي ما تبقى من WETH وUSDB.
0x bf…87 (عنوان المهاجم 3) سرق فقط 73.49 WETH.0x bf…87 (عنوان المهاجم 3) يمكنه في الواقع إزالة 7350 WETH بالكامل، أو يمكنك استخدام 0x c 5…0 d (عنوان المهاجم 2) الذي سرقه "تخلص من كل 7758267 USDB. لماذا توقف بعد أخذ القليل من WETH؟ لا نعرف. قد يتطلب الأمر محققًا معروفًا لإجراء تحقيق داخلي متعمق.
لماذا لم ينقل المهاجم 17413 ETH إلى شبكة Ethereum الرئيسية؟
كما نعلم جميعًا، من الممكن لشبكة Blast الرئيسية اعتراض هذه ETH من خلال طريقة مركزية والسماح لها بالبقاء هنا بشكل دائم دون التسبب في خسائر كبيرة للمستخدمين، ومع ذلك، بمجرد دخول هذه ETH إلى شبكة Ethereum الرئيسية، لا توجد طريقة لاعتراضها. هو - هي.
قمنا بتقييم جسور بلاست الحالية المتقاطعة، لا يوجد حد لعدد الجسور الرسمية المتقاطعة، لكن الأمر يتطلب 14 يومًا للخروج، وهو ما يكفي لمسؤولي بلاست لإعداد خطة اعتراض.
يمكن إضافة الجسر عبر السلسلة التابع لجهة خارجية في الوقت الفعلي تقريبًا، تمامًا مثل مصدر رسوم المهاجم، ويمكنه إكمال السلسلة المتقاطعة بسرعة. لماذا لم يقم المهاجم بربط السلسلة المتقاطعة على الفور؟
في الواقع، قام المهاجم بتنفيذ سلسلة متقاطعة في اللحظة الأولى (خلال دقيقتين من الهجوم):
علاوة على ذلك، استغرق وصول الأموال إلى شبكة إيثريوم الرئيسية 20 ثانية. من الناحية النظرية، يمكن للمهاجم الاستمرار في التقاطع ونقل كمية كبيرة من الإيثريوم عبر السلاسل قبل أن يتمكن الجسر عبر السلاسل من التدخل يدويًا.
أما بالنسبة لسبب إمكانية وجود 3 ETH فقط في المرة الواحدة، فالسبب هو حد السيولة للجسر عبر السلسلة، من Blast إلى ETH:
جسر آخر عبر السلسلة يدعم Blast يدعم أقل من ذلك:
بعد هذه المعاملة عبر السلسلة، لم يواصل المهاجم عمليات أخرى عبر السلسلة، والسبب غير معروف لنا، ويبدو أن “المتسلل من بلد معين” لم يقم بالاستعدادات الكافية لسحب الأموال من Blast.
تطور الأحداث بعد الهجوم
واستنادًا إلى تعليقات مستخدم المجتمع Nearisbuilding، وجد المزيد من المعلومات حول هوية المهاجم ووجد طرقًا لمطالبة المهاجم بإعادة الأموال.
في النهاية، ومع اهتمام وجهود مجتمع التشفير، قام “الهاكر من دولة معينة”، ربما لأنه كان خائفًا من كشف هويته، بتقديم المفاتيح الخاصة لعناوين المهاجمين الثلاثة المذكورة أعلاه إلى طرف المشروع وأعاد جميعها. الأموال. أجرى طرف المشروع أيضًا معاملة إنقاذ. تحويل جميع الأموال من العقد التالف إلى العقد متعدد التوقيع لحفظها.
