GMX تعرضت لاختراق هاكر، مما أدى إلى خسائر تزيد عن 40 مليون دولار. استغل المهاجم ثغرة قابلة لإعادة الدخول، وأقام المراكز القصيرة في ظل تفعيل ميزة الرافعة المالية لتنفيذ الهجوم.
جوهر المشكلة يكمن في الاستخدام الخاطئ لدالة executeDecreaseOrder. يجب أن يكون المعامل الأول لهذه الدالة هو حساب خارجي (EOA)، لكن المهاجم مرر عنوان عقد ذكي. هذا سمح للمهاجم بإعادة الدخول إلى النظام أثناء عملية الاسترداد، والتلاعب بالحالة الداخلية، مما أدى إلى استرداد أصول تفوق بكثير القيمة الفعلية لـ GLP التي يمتلكها.
في GMX، GLP هو رمز موفر السيولة، يمثل حصة من أصول الخزانة (مثل USDC و ETH و WBTC). عادةً، عند استرداد المستخدم لـ GLP، يحسب النظام كمية الأصول التي يجب إرجاعها بناءً على نسبة GLP التي يمتلكها المستخدم وإجمالي الأصول المدارة الحالية (AUM). يتضمن حساب AUM القيمة الإجمالية لجميع أحواض الرموز، والأرباح والخسائر غير المحققة من المراكز القصيرة العالمية، والمبالغ المحجوزة، والخصومات المحددة مسبقًا.
ومع ذلك، عند تمكين ميزة الرافعة المالية، ظهرت ثغرة في النظام. قام المهاجمون بفتح مراكز قصيرة كبيرة من WBTC قبل استرداد GLP. نظرًا لأن فتح المركز القصير زاد من الحجم الإجمالي للمراكز القصيرة، افترض النظام أن المركز القصير في حالة خسارة بينما لم يتغير السعر بعد. تم احتساب هذه الخسارة غير المحققة بشكل خاطئ ك"أصول" في الخزينة، مما أدى إلى ارتفاع غير مبرر في AUM. على الرغم من أن الخزينة لم تحصل فعليًا على قيمة إضافية، إلا أن حساب الاسترداد كان يعتمد على هذا الرقم المبالغ فيه في AUM، مما جعل المهاجمين يحصلون على أصول تفوق بكثير ما يستحقونه.
كشفت هذه الهجمة عن عيوب خطيرة في آلية الرفع وتصميم حماية إعادة الدخول في GMX. تكمن المشكلة الأساسية في الثقة المفرطة في منطق استرداد الأصول بالنسبة للأموال المدارة، حيث لم يتم إجراء تدقيق أمني كافٍ لمكوناتها (مثل الخسائر غير المحققة). في الوقت نفسه، تفتقر الوظائف الرئيسية إلى تحقق إلزامي من هوية المتصل (EOA مقابل العقد).
هذه الحادثة تذكر المطورين مرة أخرى بأنه عند القيام بعمليات حساسة تتعلق بالأموال، يجب التأكد من أن حالة النظام لا يمكن التلاعب بها. خاصة عند إدخال منطق مالي معقد (مثل الرفع المالي والمشتقات)، يجب توخي الحذر بشكل أكبر من المخاطر النظامية الناتجة عن إعادة الدخول وتلوث الحالة. يجب على فريق التطوير إعادة تقييم تصميم عقودهم، وتعزيز تدابير الأمان، والنظر في إدخال آليات تحقق هوية وفحص حالة أكثر صرامة لمنع حدوث هجمات مشابهة مرة أخرى.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تعرض GMX لهجوم هاكر، ثغرة إعادة الدخول تسببت في خسائر قدرها 4000万美元
GMX تعرضت لاختراق هاكر، مما أدى إلى خسائر تزيد عن 40 مليون دولار. استغل المهاجم ثغرة قابلة لإعادة الدخول، وأقام المراكز القصيرة في ظل تفعيل ميزة الرافعة المالية لتنفيذ الهجوم.
جوهر المشكلة يكمن في الاستخدام الخاطئ لدالة executeDecreaseOrder. يجب أن يكون المعامل الأول لهذه الدالة هو حساب خارجي (EOA)، لكن المهاجم مرر عنوان عقد ذكي. هذا سمح للمهاجم بإعادة الدخول إلى النظام أثناء عملية الاسترداد، والتلاعب بالحالة الداخلية، مما أدى إلى استرداد أصول تفوق بكثير القيمة الفعلية لـ GLP التي يمتلكها.
في GMX، GLP هو رمز موفر السيولة، يمثل حصة من أصول الخزانة (مثل USDC و ETH و WBTC). عادةً، عند استرداد المستخدم لـ GLP، يحسب النظام كمية الأصول التي يجب إرجاعها بناءً على نسبة GLP التي يمتلكها المستخدم وإجمالي الأصول المدارة الحالية (AUM). يتضمن حساب AUM القيمة الإجمالية لجميع أحواض الرموز، والأرباح والخسائر غير المحققة من المراكز القصيرة العالمية، والمبالغ المحجوزة، والخصومات المحددة مسبقًا.
ومع ذلك، عند تمكين ميزة الرافعة المالية، ظهرت ثغرة في النظام. قام المهاجمون بفتح مراكز قصيرة كبيرة من WBTC قبل استرداد GLP. نظرًا لأن فتح المركز القصير زاد من الحجم الإجمالي للمراكز القصيرة، افترض النظام أن المركز القصير في حالة خسارة بينما لم يتغير السعر بعد. تم احتساب هذه الخسارة غير المحققة بشكل خاطئ ك"أصول" في الخزينة، مما أدى إلى ارتفاع غير مبرر في AUM. على الرغم من أن الخزينة لم تحصل فعليًا على قيمة إضافية، إلا أن حساب الاسترداد كان يعتمد على هذا الرقم المبالغ فيه في AUM، مما جعل المهاجمين يحصلون على أصول تفوق بكثير ما يستحقونه.
كشفت هذه الهجمة عن عيوب خطيرة في آلية الرفع وتصميم حماية إعادة الدخول في GMX. تكمن المشكلة الأساسية في الثقة المفرطة في منطق استرداد الأصول بالنسبة للأموال المدارة، حيث لم يتم إجراء تدقيق أمني كافٍ لمكوناتها (مثل الخسائر غير المحققة). في الوقت نفسه، تفتقر الوظائف الرئيسية إلى تحقق إلزامي من هوية المتصل (EOA مقابل العقد).
هذه الحادثة تذكر المطورين مرة أخرى بأنه عند القيام بعمليات حساسة تتعلق بالأموال، يجب التأكد من أن حالة النظام لا يمكن التلاعب بها. خاصة عند إدخال منطق مالي معقد (مثل الرفع المالي والمشتقات)، يجب توخي الحذر بشكل أكبر من المخاطر النظامية الناتجة عن إعادة الدخول وتلوث الحالة. يجب على فريق التطوير إعادة تقييم تصميم عقودهم، وتعزيز تدابير الأمان، والنظر في إدخال آليات تحقق هوية وفحص حالة أكثر صرامة لمنع حدوث هجمات مشابهة مرة أخرى.