الخلفية

تم إنشاء Blast بواسطة مؤسس Blur Pacman (Tieshun Roquerre، The تم إطلاق شبكة Ethereum Layer2 بواسطة Tieshun، الشبكة الرئيسية في 29 فبراير. حاليًا، تم التعهد بحوالي 19,500 ETH و640,000 stETH على شبكة Blast الرئيسية.

المشروع المهاجم Munchables هو مشروع عالي الجودة فاز في مسابقة Bigbang التي نظمتها Blast.

سيصدر مسؤول Blast نقاطًا عادية للمستخدمين الذين يتعهدون بـ ETH على شبكة Blast الرئيسية:

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

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

نظرة عامة على الحادثة

بعد أقل من شهر من إطلاق شبكة Blast الرئيسية، وقع هجوم على SSS في 21 مارس 2024. هجوم الرمز المميز (Super Sushi Samurai)، يوجد خطأ في منطق النقل في عقد الرمز المميز، مما يسمح للمهاجم بزيادة رصيد رمز SSS للحساب المحدد من لا شيء. في النهاية، خسر المشروع أكثر من 1310 إيثريوم (حوالي 4.6 مليون دولار).

بعد أقل من أسبوع من هجوم SSS Token، وقع هجوم أكبر آخر على Blast. وقد اجتاح المهاجم مشروع Munchables. وتم الاستيلاء على 17413.96 ETH، إجمالي ما يقرب من 62.5 مليون دولار أمريكي.

بعد نصف ساعة من حدوث معاملة الهجوم، تمت سرقة 73.49 WETH في عقد المشروع أيضًا بواسطة متسلل في عنوان آخر.

في الوقت الحالي، لا يزال هناك 7276 WETH، و7758267 USDB، و4 ETH مخزنة في عنوان عقد المشروع، والتي قد تقع في أيدي المتسللين في أي وقت. وتمكن المتسللون من الوصول إلى جميع الأموال في المشروع بأكمله، مما ترك ما مجموعه حوالي 97 مليون دولار في خطر.

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

دعونا نلقي نظرة فاحصة على كيفية قيام "متسلل من بلد معين" بإتمام هجوم بقيمة 100 مليون دولار تقريبًا.

استعادة مباشرة

• الضحايا يتحدثون علنًا

[UTC+0] 21:37، 26 مارس 2024 (بعد 5 دقائق من الهجوم)، نشرت Munchables رسميًا على X (Twitter) تفيد بأنها تتعرض للهجوم.

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

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

• المشهد الأول

< /ul>

[UTC+0] في الساعة 21:32 يوم 26 مارس 2024، وقع هجوم يتضمن 17413.96 إيثريوم.

يمكننا رؤية معاملة الهجوم هذه من خلال Blastscan: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95



العقد التالف (0x29..1F ) هو عقد الوكيل الذي يخزن الأموال المرهونة للمستخدم، يمكننا أن نرى أن المهاجم استدعى وظيفة إلغاء القفل لعقد التعهد، واجتاز جميع عمليات فحص الأذونات، ونقل جميع ETH في العقد إلى عنوان المهاجم 1. (0x6E..c5).



يبدو أن المهاجم استدعى وظيفة فتح مشابهة لسلوك السحب وأخذ معظم ETH من العقد التالف (0x29..1F).

هل نسي فريق المشروع قفل القبو؟

فتح القفلفي العقد التالف (0x29..1F) له فحصان مرتبطان، فلنلقِ نظرة عليهما واحدًا تلو الآخر.

أولاً، وجدنا أنه أثناء عملية التحقق من الأذونات، تم استدعاء الطريقة isRegistered للعقد (0x16..A0) لعرض الرسالة الحالية .sender، أي أيضًا ما إذا كان قد تم تسجيل عنوان المتسلل 1 (0x6E..c5):





الإجابة هي: تم اجتياز عملية التحقق.



يتضمن ذلك العقد (0x16..A0) وأحدث عقد منطقي مطابق له (0xe7..f1)

[UTC+0]2024 الساعة 08 :39 في 24 مارس 2019 (قبل يومين من الهجوم)، تمت ترقية العقد المنطقي المطابق للعقد (0x16..A0).



معاملة ترقية العقد المنطقي:

https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6

تم تحديث العقد المنطقي إلى 0xe7..f1.

يمكن رؤية عنوان العقد المنطقي الأصلي هنا، وهو 0x9e..CD.

https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003



في هذا الوقت، نشتبه في أن المتسلل يقوم بتحديث عقد التنفيذ المنطقي لعقد الوكيل ، والذي سيكون 0x9e.. يصبح القرص المضغوط 0xe7..f1 ضارًا، مما يؤدي إلى إكمال تجاوز أذونات التحقق.

هل هذا هو الحال بالفعل؟

في Web3.0، لا تحتاج أبدًا إلى التخمين أو الاستماع إلى الآخرين. ما عليك سوى إتقان التكنولوجيا للحصول على الإجابة بنفسك.

بمقارنة العقدين (ليست عقود مفتوحة المصدر)، هناك بعض الاختلافات الواضحة بين عقد 0x9e..CD الأصلي و0xe7..f1 المحدث:

يتم تنفيذ جزء وظيفة التهيئة من 0xe7..f1 على النحو التالي:



جزء وظيفة التهيئة من 0x9e..يتم تنفيذ القرص المضغوط على النحو التالي:



كما ترون، المهاجم في العقد المنطقي الأصلي (0x9e..CD)، تم تعيين عنوان المهاجم (0x6e..c5) للتسجيل، كما تم أيضًا تعيين عنوانين مهاجمين آخرين 0xc5..0d و0xbf..87 مسجلة، ويتم ضبط الحقل 0 على وقت الكتلة أثناء التهيئة، وسيتم شرح استخدام الحقل 0 لاحقًا.

في الواقع، على عكس ما توقعناه، فإن العقد المنطقي الحقيقي مع الباب الخلفي كان موجودًا في البداية، وتم تحديثه لاحقًا، وهو أمر طبيعي!

انتظر، ظهر هذا التحديث الساعة 08:39 يوم 24 مارس 2024 [UTC+0] (قبل يومين من الهجوم)، أي قبل هذه الحادثة، أصبح العقد المنطقي عقدًا بدون باب خلفي، فلماذا لا يزال بإمكان المهاجم إكمال الهجوم لاحقًا؟

وهذا بسبب استدعاء المفوض، لذا فإن تحديث تخزين الحالة الفعلي موجود في العقد (0x16..A0)، مما يؤدي أيضًا إلى العقد المنطقي حتى بعد ذلك. يتم تحديث العقد المنطقي 0xe7..f1 بدون باب خلفي، لن تتم استعادة الفتحة التي تم تغييرها في العقد (0x16..A0).

دعونا نتحقق:



كما ترون، فإن الفتحة المقابلة في العقد (0x16....A0) لها قيمة عددية.

يسمح هذا للمهاجم باجتياز التحقق من الطريقة المسجلة:



قام المهاجم لاحقًا باستبدال عقد الباب الخلفي بعقد عادي لخداع الآخرين. وفي الواقع، كان الباب الخلفي نباتًا بالفعل.

بالإضافة إلى ذلك، تتضمن عملية إلغاء القفل أيضًا التحقق الثاني:

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



يحتاج المهاجم إلى التأكد من أن وقت الحظر عند استدعاء إلغاء القفل أكبر من وقت انتهاء صلاحية القفل المطلوب (الحقل 3).

يتضمن هذا الجزء من التحقق العقد التالف (0x29..1F) والعقد المنطقي المقابل 0xf5..cd.

في المعاملة الساعة 11:54 يوم 21 مارس 2024 [UTC+0] (قبل 5 أيام من الهجوم)،

< p style= "محاذاة النص: يسار;">https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170



يمكننا أن نرى أن العقد المنطقي الأصلي للعقد التالف (0x29..1F) هو 0x91..11، وفقط بعد أربع دقائق، على

https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f

< تمت ترقية img src="https://img.jinse.cn/7200163_image3.png">

إلى 0xf5..cd.

قمنا أيضًا بمقارنة العقدين، ويمكننا أن نجد أن المهاجم قام أيضًا بخدع في وظيفة التهيئة كما كان من قبل،

التنفيذ الجزئي لوظيفة التهيئة لـ 0xf5..cd:



التنفيذ الجزئي لوظيفة التهيئة لـ 0x91..11:



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

حتى الآن، نحن نفهم هذه المعاملة التي تتضمن 17413 ETH وكيف قام المهاجم بذلك، ولكن هل يوجد هذا القدر من المعلومات وراء هذه الحادثة؟

في تحليلنا أعلاه، رأينا بالفعل أن المتسلل قام ببناء 3 عناوين في العقد:

0x6e..c5 (عنوان المهاجم 1)

0xc5..0d (عنوان المهاجم 2)

0xbf..87 (عنوان المهاجم 3)

واحدة فقط من معاملات الهجوم التي وجدناها أعلاه ترى 0x6e.. c5، ماذا فعل العنوانان الآخران؟ وما هي الأسرار المخفية في العنوان (0) و_dodoApproveAddress و_uniswapV3Factorty؟

• المشهد الثاني

< /ul>

دعونا نلقي نظرة أولاً على عنوان المهاجم 3 (0xbf..87)، الذي سرق 73.49 WETH بنفس الطريقة:

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

وهاجم عنوان مصدر الغاز (0x97..de) ، مع توفير رسوم المناولة لكل من 0xc5..0d (عنوان المهاجم 2) و0xbf..87 (عنوان المهاجم 3).



مصدر 0.1 ETH الذي يهاجم عنوان مصدر الغاز (0x97..de) يأتي من owlto.finance (جسر عبر السلسلة).

0xc5..0d (عنوان المهاجم 2) لم ينفذ أي هجوم بعد تلقي رسوم المناولة، لكنه في الواقع تحمل خطة خفية. نواصل القراءة.

في الواقع، وفقًا لمعاملة الإنقاذ الرسمية، اتضح أن هناك أكثر من 73.49 ويث على عنوان العقد التالف (0x29..1F). حتى انتهى الهجوم، ولن يكون هناك أكثر من 73.49 وي لا يزال هناك 7276.5 ويث و7758267 دولار أمريكي.

صفقة الإنقاذ:

https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb

p> p>



في الأصل خطط المهاجم لسرقة هذه الأصول. يمكنك أن ترى أن العنوان 0xc5..0d (عنوان المهاجم 2) تم استخدامه في الأصل لسرقة USDB.



عنوان _dodoApprove هنا هو 0x0000000000000000000000000000000000000003



<ص style="text-align: left;">هو عنوان usdb



0xbf..87 (عنوان المهاجم 3) يُستخدم هذا العنوان لسرقة الأموال:



_uniswapV3Factory هنا هو 0x00000000000000000000000000000000000 004< p style="text-align:center">

للويث العنوان



و 0x6e..c5 (عنوان المهاجم 1) مسؤول عن سرقة العنوان (0)، وهو الأصل الأصلي ETH.

من خلال تعيين field0، يمكن للمهاجم سرقة الأصول المقابلة من خلال المنطق التالي:

< img src="https://img.jinse.cn/7200174_image3.png">



سؤال

• < h2 style="text-align: left;">لماذا لم يسرق المهاجم جميع الأصول؟

من الناحية النظرية، يمكنه سرقة جميع الأصول، أي ما تبقى من WETH وUSDB.

0xbf..87 (عنوان المهاجم 3) سرق فقط 73.49 WETH، 0xbf..87 (عنوان المهاجم 3) يمكنه بالفعل سرقة كل 7350 WETH التي تم أخذها بعيدًا. يمكنك أيضًا استخدام 0xc5..0d (عنوان المهاجم 2) لإزالة كل 7758267 USDB. لماذا توقف بعد أخذ القليل من WETH فقط غير معروف لنا. قد يتطلب الأمر محققًا معروفًا للتعمق في التحقيق. .

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233



• لماذا ألم ينقل المهاجم 17413ETH إلى شبكة Ethereum الرئيسية؟

كما نعلم جميعًا، من الممكن لشبكة Blast الرئيسية اعتراض هذه ETH من خلال طريقة مركزية و دعها تبقى بشكل دائم هنا، لن تكون هناك خسائر كبيرة للمستخدمين، ولكن بمجرد دخول هذه ETH إلى شبكة Ethereum الرئيسية، لن تكون هناك طريقة لاعتراضها.

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

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

في الواقع، قام المهاجم بتنفيذ سلسلة متقاطعة في المرة الأولى (خلال دقيقتين من الهجوم):

https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f



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



أما بالنسبة لسبب إمكانية وجود 3 ETH فقط في المرة الواحدة، فالسبب هو حد السيولة للجسر عبر السلسلة، من Blast إلى ETH:



يدعم جسر آخر عبر السلسلة يدعم Blast أقل من ذلك:< /p >



بعد هذه المعاملة عبر السلسلة، لم يواصل المهاجم عمليات أخرى عبر السلسلة. السبب غير معروف لنا. يبدو أن "المتسلل من بلد معين" لم يقم بالاستعدادات الكافية لسحب الأموال من Blast .

تطور الأحداث بعد الهجوم

حسب المجتمع بناءً على التعليقات، وجد المستخدم Nearisbuilding مزيدًا من المعلومات حول هوية المهاجم ووجد طرقًا لمطالبة المهاجم بإعادة الأموال.

https://twitter.com/Nearisbuilding/status/1772812190673756548





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