BlockSec: تحليل آلية هجوم GMX

الكلمات: BlockSec

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

تكمن جذور المشكلة في الاستخدام الخاطئ لدالة executeDecreaseOrder. كان من المفترض أن يكون المعامل الأول لتلك الدالة هو حساب خارجي (EOA)، لكن المهاجم أدخل عنوان عقد ذكي. وهذا سمح للمهاجم بإعادة الدخول إلى النظام أثناء عملية الاسترداد، مما أدى إلى التلاعب بالحالة الداخلية، وفي النهاية كانت الأصول المستردة تفوق بكثير القيمة الفعلية لـ GLP التي يمتلكها.

آلية استرداد GLP العادية

في GMX، GLP هو رمز مزود السيولة، يمثل حصة من أصول الخزانة (مثل USDC و ETH و WBTC). عندما يقوم المستخدم باستدعاء unstakeAndRedeemGlp، يستخدم النظام الصيغة التالية لحساب كمية الأصول التي يجب إرجاعها:

redeem_amount = (user_GLP / الإجمالي_GLP_supply) * AUM

يتم حساب AUM (إجمالي الأصول المدارة) بالطريقة التالية:

AUM = القيمة الإجمالية لجميع مجمعات الرموز + الخسائر غير المحققة العامة من المراكز القصيرة - الأرباح غير المحققة العامة من المراكز القصيرة - المبلغ المحجوز - الخصم المسبق (aumDeduction)

تضمن هذه الآلية أن يحصل حاملو GLP على حصة من الأصول الفعلية في الخزانة بشكل نسبي.

مشكلة بعد فتح الرافعة

عند تفعيل enableLeverage، يمكن للمستخدم فتح مراكز رافعة (طويلة أو قصيرة). قبل استرداد GLP، فتح المهاجم مركزًا قصيرًا كبيرًا على WBTC.

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

عملية الهجوم

الهجمات التجارية

كتابة في النهاية

كشفت هذه الهجمة عن عيوب خطيرة في آلية الرفع المالي وتصميم حماية إعادة الدخول في GMX. تكمن المشكلة الأساسية في الثقة المفرطة في منطق استرداد الأصول بالنسبة للأموال المدارة، حيث لم يتم إجراء فحوصات أمان كافية على مكوناتها (مثل الخسائر غير المحققة). في الوقت نفسه، تفتقر الفرضيات حول هوية المستدعي (EOA مقابل العقد) في الوظائف الرئيسية إلى التحقق الإلزامي. تذكّر هذه الحادثة المطورين مرة أخرى بأنه عند التعامل مع العمليات الحساسة المالية، يجب التأكد من عدم إمكانية التلاعب بحالة النظام، وخاصة عند إدخال منطق مالي معقد (مثل الرفع المالي والمشتقات)، يجب توخي الحذر الشديد من المخاطر النظامية الناجمة عن إعادة الدخول وتلوث الحالة.