Resolv هجوم القراصنة: كيف أدى تسرب مفتاح واحد إلى صك غير قانوني بقيمة 23 مليون دولار

كتابة: Chainalysis

ترجمة: AididiaoJP، Foresight News

في 22 مارس 2026، أصبح بروتوكول Resolv DeFi أحدث مثال يُظهر مدى سرعة وقوع أزمة في مجال التمويل اللامركزي عندما تفشل الافتراضات الأمنية. خلال دقائق قليلة، قام مهاجم بإنشاء مئات الملايين من عملة USR المستقرة غير المدعومة بضمانات، وسحب حوالي 25 مليون دولار من قيمتها، مما أدى إلى انفصال حاد في سعر USR واضطرار البروتوكول إلى التوقف عن العمل.

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

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

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

ملخص الحدث

بدأ المهاجم بإيداع مبلغ صغير نسبياً (حوالي 100,000 إلى 200,000 دولار من USDC)، واستخدمه للتفاعل مع نظام إصدار USR المستقر لبروتوكول Resolv. عادةً، بعد إيداع USDC، يحصل المستخدم على USR بقيمته المعادلة. لكن في هذا الحدث، تمكن المهاجم من إصدار حوالي 80 مليون عملة USR، متجاوزًا بشكل كبير الحد المسموح به بناءً على إيداعه.

سبب ذلك أن عملية الموافقة على الإصدار تعتمد على خدمة خارجية تستخدم مفتاحًا خاصًا بامتيازات عالية (privileged key) لتفويض كمية الإصدار. ومع ذلك، فإن العقود الذكية ذاتها لم تضع أي حد أعلى لعدد العملات التي يمكن إصدارها — فهي فقط تتحقق من صحة التوقيع.

بعد إصدار USR غير المدعوم بضمانات، قام المهاجم بسرعة بتحويلها إلى نسخة مكدسة wstUSR، ثم استمر في استبدالها بأصول مستقرة أخرى، وأخيرًا سحبها كـ ETH. عند اكتمال الهجوم، كانت أرباح المهاجم حوالي 25 مليون دولار من ETH. ونتيجةً لذلك، تدفقت كميات هائلة من USR غير المدعوم إلى السوق، مما أدى إلى انخفاض سعر العملة بنسبة تقارب 80%.

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

العملية الطبيعية لإصدار رموز Resolv

لفهم أسباب هذا الهجوم، من الضروري التعرف على آلية الإصدار في بروتوكول Resolv.

عندما يرغب المستخدم في إصدار العملة الأصلية USR، فإن التفاعل لا يتم مع آلية على السلسلة بشكل كامل، بل عبر عملية خارجية تتكون من خطوتين:

requestSwap — يودع المستخدم USDC في عقد USR Counter ويطلق طلب الإصدار.

completeSwap — خدمة خارجية تُدار بواسطة مفتاح خاص يُسمى SERVICE_ROLE، تقوم بمراجعة الطلب وتحديد كمية USR النهائية عبر استدعاء عقد رجعي (callback contract).

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

تفصيل خطوات الهجوم

الخطوة الأولى: الحصول على صلاحية الوصول إلى بيئة AWS KMS الخاصة بـ Resolv

نجح المهاجم في اختراق البنية التحتية السحابية لـ Resolv، وحصل على صلاحية الوصول إلى بيئة خدمة إدارة المفاتيح (KMS) التي تستخدمها البروتوكول، والتي تحتوي على مفاتيح التوقيع ذات الامتيازات العالية. بعد السيطرة على بيئة KMS، يمكن للمهاجم استخدام المفتاح الخاص لإصدار أي عمليات إصدار يختارها.

الخطوة الثانية: إصدار عملة USR

بعد الحصول على المفتاح الموقّع، بدأ المهاجم بإرسال طلبين لعملية swap، كل منهما يدعم إيداع USDC بمبالغ صغيرة، بإجمالي حوالي 100,000 إلى 200,000 دولار، موزعة على عدة معاملات. ثم، باستخدام مفتاح SERVICE_ROLE، استدعى وظيفة completeSwap وكتب كمية إصدار مزورة، مما سمح له بإصدار مئات الملايين من USR مقابل مبلغ قليل من USDC.

تم التعرف على معاملتين رئيسيتين على السلسلة:

إصدار 50 مليون USR

إصدار 30 مليون USR

إجمالاً، تم إصدار 80 مليون عملة USR، بقيمة تقريبية تبلغ 25 مليون دولار.

الخطوة الثالثة: التحويل إلى wstUSR لتجنب قيود السيولة

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

الخطوة الرابعة: السحب والتصفية

بناءً على حيازته لـ wstUSR، استمر المهاجم في استبدالها بأصول مستقرة، ثم بـ ETH، واستخدم العديد من برك السيولة على منصات التداول اللامركزية والجسور عبر السلاسل لنقل الأموال، بهدف تعظيم المبالغ المسحوبة وزيادة صعوبة تتبعها.

حتى وقت إعداد هذا التقرير، لا يزال المهاجم يحتفظ بعنوانه بـ:

حوالي 11,400 ETH (بقيمة تقارب 24 مليون دولار)

حوالي 20 مليون wstUSR (بقيمة حوالي 130 ألف دولار وفقًا للسعر بعد الانفصال)

تأثير الحدث على حاملي USR

تسبب هذا الحدث في ضرر مباشر وخطير لمقتني USR.

العملات الجديدة غير المدعومة التي تم إصدارها، والتي بلغت 80 مليون USR، دخلت تدريجيًا في تجمعات السيولة على البورصات اللامركزية. ومع زيادة العرض بشكل كبير، انهارت قيمة USR مقابل الدولار بسرعة. وصلت العملة إلى سعر منخفض بلغ 0.20 دولار، بانخفاض قدره 80%، ثم عادت وارتفعت خلال ساعات قليلة إلى حوالي 0.56 دولار.

بعد الحادث، أصدرت Resolv Labs بيانًا أوقفت فيه جميع وظائف البروتوكول لمنع المزيد من الخسائر، وبدأت التحقيق في الاختراق. مع استمرار محاولة المهاجم إصدار المزيد من USR، فإن اتخاذ إجراءات سريعة لمنع توسع الخسائر أمر ضروري، ويبرز أهمية الاستجابة السريعة لمثل هذه الهجمات.

مفهوم الأمان السليم يجب أن يستند إلى «افتراض وجود ثغرات حتمية»

على الرغم من أن Resolv طبق جميع التدابير الأمنية المعتادة وأجرى حتى 18 تدقيقًا أمنيًا، فإن هذا الهجوم من ناحية جوهره قصة بسيطة: المهاجم حصل على المفتاح، واستخدمه لإصدار أصول بشكل غير قانوني، وبيعها قبل أن يكتشف الطرف الآخر ذلك.

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

وفي ظل سرعة استغلال الثغرات التي غالبًا ما تتم خلال دقائق، وعندما تظهر الخسائر، يصعب اتخاذ إجراءات رد فعل سلبية، فإن آليات المراقبة في الوقت الحقيقي والاستجابة الآلية أصبحت ضرورة لا غنى عنها، وليست مجرد إضافات اختيارية.

تحليل حالات الوقاية عبر Hexagate

الهجوم الذي تعرض له Resolv يوضح بشكل كامل أهمية وجود آليات مراقبة فورية على السلسلة للكشف عن مثل هذه الحالات. لو تم استخدام نظام Hexagate من Chainalysis، لكان بالإمكان الاعتماد على طريقتين محددتين للكشف:

الخطة الأولى: مراقبة عمليات الإصدار غير الطبيعية

عن طريق إعداد نظام مراقبة مثل Hexagate، يمكن مراقبة استدعاءات وظيفة completeSwap، مع التركيز على اكتشاف حالات يكون فيها حجم الإصدار من USR غير متناسب بشكل كبير مع كمية الضمانات المودعة.

مثلاً، إيداع USDC بقيمة 10 آلاف دولار، مع إصدار 50 مليون USR، هو نسبة غير طبيعية تتجاوز أي سلوك طبيعي للمستخدمين. يمكن ضبط قواعد تنبيه عند تجاوز نسبة الإصدار الحد الطبيعي بمقدار 1.5 مرة، ليتم الإبلاغ عنها فورًا.

آليات المراقبة المخصصة في Hexagate يمكن أن تفعّل استجابة تلقائية عند اكتشاف سلوك غير عادي في عمليات الإصدار، مثل إيقاف العقود تلقائيًا قبل أن تتسرب الأموال إلى السوق.

الخطة الثانية: دمج GateSigner مع وظائف مخصصة لمراقبة الأحداث الرئيسية

المهاجم يجب أن ينفذ عمليتي requestSwap و completeSwap، وكل مرحلة منهما تولد أحداثًا على السلسلة. يمكن لـ Hexagate، باستخدام وظيفة GateSigner ومراقبة الأحداث، أن يُضبط ليقوم تلقائيًا بإيقاف العقود عند اكتشاف أحداث إصدار غير طبيعية، قبل أن تصل أي أموال إلى السوق المفتوح، مما يمنع تسرب 80 مليون USR.