Invezz

هكذا استنزف المهاجمون $3.2M من محافظ Safe على Ethereum و Base

هكذا استنزف المهاجمون $3.2M من محافظ Safe على Ethereum و Base
Rony Roy
الكاتب
Rony Roy
25 مايو 2026, 19:37 م

بتقنية

Invezz
شراء الفائزين في أمن DeFi

اشترِ أسماء بنية تحتية أمنية في DeFi المرتبطة بالمراقبة/حواجز الحماية (مثل مزودي الحماية على السلسلة على غرار Blockaid عبر وسطاء علنيين مثل منصات الأمن السيبراني/إدارة مخاطر التشفير؛ وإذا اضطررت لاستخدام وسطاء سيولة، ففضل الشركات ذات تعرض لأدوات الأمن على السلسلة). أثر ثانوي: بعد هذا الحادث، سيدفع مستخدمو المحافظ والمتكاملون مبالغ أكبر مقابل التحقق من الوحدات/الـguards، والتنبيهات، وفحوصات مخاطر الأذونات الآلية—مما سيعجل باعتماد طبقات الأمان وزيادة الاستعداد للدفع مقابل منتجات شبيهة بـ "Safe Shield". الخطر الرئيسي: تراجع الاعتماد إذا اعتُبر الحادث معزولًا وعاد المستخدمون لاستخدام وحدات "اضبط وانس" رغم التحذيرات.

المخاطر الرئيسية: لا يزيد مستخدمو المحافظ والمتكاملون الإنفاق على التحقق من الوحدات/حواجز الحماية بعد تكرار الحوادث.

بيع التعرض لوحدات Safe

بيع التعرض لرموز منظومة Gnosis Safe (مثل SAFE) وتجنب الانخراط في وحدات/تكاملات Safe الجديدة. تُظهر هذه الأخبار أن وحدة طرف ثالث (SquidRouterModule) يمكنها تجاوز التحقق من المفوضين وتشغيل عمليات تبديل عشوائية من محافظ Safe دون الموافقات متعددة التوقيع الاعتيادية — ما يعني أن المحافظ الذكية "المفوضة" لا تزال عرضة لفشل وحدة واحدة يؤدي إلى استنزاف كامل. الخطر الرئيسي: تطبيق تصحيح/معيار تحقق سريع وموثوق يمنع انتحال المفوضين الخبيثين ويستعيد الثقة والطلب على وحدات Safe.

المخاطر الرئيسية: حل فعلي يمنع الوحدات الخبيثة من انتحال المفوضين المعتمدين وتنفيذ عمليات تبديل عشوائية.

  • استنزف المهاجمون $3.2 million من 86 محفظة Safe على Ethereum و Base.
  • ربط المحللون الاستغلال باستدعاءات مفوض مزورة ووحدة Safe ضعيفة.
  • تمت مبادلة الأموال المسروقة عبر مجمعات Uniswap V3 إلى نحو 3.07 million DAI.

أدت ثغرة مرتبطة بوحدة طرف ثالث لمحفظة Safe إلى سرقة نحو $3.2 million عبر Ethereum و Base بعد أن استغل المهاجمون أذونات التنفيذ المفوضة لاستنزاف عشرات الحسابات الذكية في غضون ساعتين تقريباً.

قالت شركة أمن البلوكشين Blockaid إن الاستغلال استهدف عقداً تم تحديده باسم SquidRouterModule، مما أثر على ما لا يقل عن 86 محفظة Gnosis Safe، قبل أن تُحوّل الأصول المسروقة إلى Dai عبر مجمعات سيولة Uniswap V3 التي تتحكم فيها جهة الهجوم.

أظهرت بيانات شاركتها الشركة أن المهاجم دمج العائدات لاحقاً في محفظة تحوي نحو 3.07 million DAI.

حددت سجلات السلسلة المرتبطة التي نشرها Blockaid عنوان المستغل كـ 0x9bdc730183821b6bb2b51be30b77c964fa645b91

أظهرت بيانات Etherscan التي استشهدت بها Lookonchain أن العنوان تم تمويله عبر Tornado Cash وسجل 52 معاملة في 25 مايو.

وتتبعت التحقيقات أيضاً معاملة استنزاف نموذجية نُفذت عند 06:25 بتوقيت UTC، حيث تم توجيه الأصول المسروقة، بما في ذلك USDC وENA وUSDT، عبر مجمعات سيولة Uniswap V3 قبل تحويلها.

كيف نُفذ الاستغلال؟

أشارت النتائج الأولية من Blockaid إلى أن الاستغلال نشأ من خلل داخل دالة executeSameChainActions() في الوحدة الطرف ثالث، وليس من البنية الأساسية الأساسية لـ Safe. 

وفقاً للشركة، نشر المهاجم عقود استغلال مبنية على Foundry استغلت مسار تنفيذ DelegateBundler في الوحدة لتنكر كمنفذين مُصرّح لهم مرتبطين بمحافظ الضحايا.

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

قالت Blockaid إن الاستغلال أتاح للمهاجم استبدال أصول شرعية برمز عديم القيمة أنشأه المهاجم يُعرف باسم "u"، قبل أن تُسحب السيولة وتُحوّل العائدات إلى DAI.

يُشتبه في انتحال هوية المفوضين في استغلال الوحدة

أشار تحليل فني إضافي شاركه مؤسس SlowMist Cos إلى أن المشكلة لم ترتبط بمفاتيح خاصة مخترقة. 

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

ووفقاً لـ Cos، تمكن المهاجمون من تزوير رسائل وتجاوز فحوصات التحقق الخاصة بالوحدة، مما أتاح عمليات استرداد ونقل غير مصرح بها من محافظ Safe المستهدفة. 

وأشار الباحث أيضاً إلى نفس محفظة الدمج التي حدّدتها Blockaid، حيث تم تسوية الأموال المسروقة على ما ورد.

Attacker’s wallet holding DAI.

محفظة المهاجم التي احتوت على DAI. المصدر: Etherscan.

يعتمد الاستغلال أساساً على طريقة عمل وحدات Safe داخل محافظ العقود الذكية. 

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

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

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

المحافظ المتأثرة غير مرتبطة بـ Safe

قال لاحقاً رئيس Safe Labs التنفيذي Rahul Rumalla إن الحسابات المخترقة «لا يبدو أنها تعمل على منتج Safe Wallet الرسمي»، مضيفاً أن المحققين لا يزالون لا يعرفون أين أُنشئت هذه المحافظ وأُديرت في الأصل.

وذكر Rumalla أن المحافظ المتأثرة نُشرت على الأرجح من خلال تكاملات خارجية بدلاً من واجهة Safe الرسمية.

وأضاف Rumalla أيضاً أن Safe Shield، نظام التحذير المدمج في الشركة والمدعوم من Blockaid، قد حدّد الوحدة بالفعل على أنها خبيثة قبل وقوع الحادث.

وبحسبه، ينبه نظام الحماية المستخدمين عندما تطلب وحدات أو حراس غير مُتحقق منهم أذونات خطرة.

Squid تنفي التورط

في الوقت نفسه، نفت Squid أن تكون بنيتها التوجيهية أو عقودها الأساسية قد تعرّضت لاختراق. 

في بيان نُشر على X، قالت الفرقة إن العقد المستغل لم يكن له سوى اسم SquidRouterModule ولم يكن له صلة بهندسة راوتر الإنتاج لدى Squid.

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

أضاف الهجوم إلى قائمة متنامية من حوادث أمن DeFi المبلغ عنها في 2026. 

كما أوردت Invezz سابقاً، تعرض Echo Protocol الأسبوع الماضي لاستغلال على Monad بعد أن سكّ المهاجمون ما يقرب من $76.7 million من رموز eBTC غير المصرح بها عبر ما ربطه الباحثون لاحقاً باختراق مفتاح المسؤول. 

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