في الآونة الأخيرة، تعرض بروتوكول التشغيل المتداخل عبر السلاسل Poly Network لهجوم هاكر، مما أثار اهتمامًا واسعًا في الصناعة. أظهرت تحليلات فريق الأمان أن هذا الهجوم لم يحدث بسبب تسرب مفتاح keeper، بل قام المهاجم بتعديل عنوان keeper لعقد EthCrossChainData من خلال بيانات تم إعدادها بعناية.
هجوم核心
جوهر الهجوم يكمن في أن دالة verifyHeaderAndExecuteTx لعقد EthCrossChainManager يمكن أن تنفذ معاملات عبر السلاسل من خلال دالة _executeCrossChainTx. نظرًا لأن مالك عقد EthCrossChainData هو عقد EthCrossChainManager، يمكن للأخير استدعاء دالة putCurEpochConPubKeyBytes لتعديل حافظ العقد.
استغل المهاجمون دالة verifyHeaderAndExecuteTx لتمرير بيانات مصممة بعناية، مما يجعل دالة _executeCrossChainTx تنفذ استدعاء دالة putCurEpochConPubKeyBytes في عقد EthCrossChainData، وبالتالي تغيير دور الحافظ إلى العنوان الذي يحدده المهاجم. بعد الانتهاء من هذه الخطوة، يمكن للمهاجم أن ينشئ معاملات لسحب أي مبلغ من الأموال من العقد.
عملية الهجوم
المهاجم أولاً من خلال استدعاء دالة verifyHeaderAndExecuteTx في عقد EthCrossChainManager، قام بتغيير keeper عن طريق استدعاء دالة putCurEpochConPubKeyBytes.
بعد ذلك، قام المهاجم بتنفيذ سلسلة من معاملات الهجوم، وسحب الأموال من العقد.
بعد الانتهاء من الهجوم، تم تعديل keeper مما أدى إلى رفض تنفيذ المعاملات العادية للمستخدمين الآخرين.
هذا نمط الهجوم لم يحدث فقط على شبكة BSC بل ظهرت عمليات مشابهة أيضًا على شبكة إيثريوم.
!
الاستنتاج
كان المفتاح في هذا الهجوم هو أن keeper عقد EthCrossChainData يمكن تعديله بواسطة عقد EthCrossChainManager، بينما يمكن لوظيفة verifyHeaderAndExecuteTx تنفيذ البيانات المدخلة من قبل المستخدم من خلال وظيفة _executeCrossChainTx. استغل المهاجم هذا الثغرة في التصميم، حيث قام بإنشاء بيانات معينة لتعديل عنوان keeper لعقد EthCrossChainData، مما سمح له بتحقيق هدف الهجوم.
تُبرز هذه الحادثة مرة أخرى أهمية أمان بروتوكولات السلاسل المتعددة، كما تُذكّر المطورين بضرورة التحلي بمزيد من الحذر عند تصميم العقود الذكية، خاصة عندما يتعلق الأمر بوظائف تغيير صلاحيات الأدوار الأساسية. في الوقت نفسه، يجب على المستخدمين أيضًا أن يظلوا يقظين عند استخدام خدمات السلاسل المتعددة، ومتابعة التطورات الأمنية ذات الصلة.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تعرضت شبكة بولي لهجوم هاكر وتم استغلال ثغرة في عقد EthCrossChainData
تحليل حادثة هجوم هاكر على شبكة بولي
في الآونة الأخيرة، تعرض بروتوكول التشغيل المتداخل عبر السلاسل Poly Network لهجوم هاكر، مما أثار اهتمامًا واسعًا في الصناعة. أظهرت تحليلات فريق الأمان أن هذا الهجوم لم يحدث بسبب تسرب مفتاح keeper، بل قام المهاجم بتعديل عنوان keeper لعقد EthCrossChainData من خلال بيانات تم إعدادها بعناية.
هجوم核心
جوهر الهجوم يكمن في أن دالة verifyHeaderAndExecuteTx لعقد EthCrossChainManager يمكن أن تنفذ معاملات عبر السلاسل من خلال دالة _executeCrossChainTx. نظرًا لأن مالك عقد EthCrossChainData هو عقد EthCrossChainManager، يمكن للأخير استدعاء دالة putCurEpochConPubKeyBytes لتعديل حافظ العقد.
استغل المهاجمون دالة verifyHeaderAndExecuteTx لتمرير بيانات مصممة بعناية، مما يجعل دالة _executeCrossChainTx تنفذ استدعاء دالة putCurEpochConPubKeyBytes في عقد EthCrossChainData، وبالتالي تغيير دور الحافظ إلى العنوان الذي يحدده المهاجم. بعد الانتهاء من هذه الخطوة، يمكن للمهاجم أن ينشئ معاملات لسحب أي مبلغ من الأموال من العقد.
عملية الهجوم
المهاجم أولاً من خلال استدعاء دالة verifyHeaderAndExecuteTx في عقد EthCrossChainManager، قام بتغيير keeper عن طريق استدعاء دالة putCurEpochConPubKeyBytes.
بعد ذلك، قام المهاجم بتنفيذ سلسلة من معاملات الهجوم، وسحب الأموال من العقد.
بعد الانتهاء من الهجوم، تم تعديل keeper مما أدى إلى رفض تنفيذ المعاملات العادية للمستخدمين الآخرين.
هذا نمط الهجوم لم يحدث فقط على شبكة BSC بل ظهرت عمليات مشابهة أيضًا على شبكة إيثريوم.
!
الاستنتاج
كان المفتاح في هذا الهجوم هو أن keeper عقد EthCrossChainData يمكن تعديله بواسطة عقد EthCrossChainManager، بينما يمكن لوظيفة verifyHeaderAndExecuteTx تنفيذ البيانات المدخلة من قبل المستخدم من خلال وظيفة _executeCrossChainTx. استغل المهاجم هذا الثغرة في التصميم، حيث قام بإنشاء بيانات معينة لتعديل عنوان keeper لعقد EthCrossChainData، مما سمح له بتحقيق هدف الهجوم.
تُبرز هذه الحادثة مرة أخرى أهمية أمان بروتوكولات السلاسل المتعددة، كما تُذكّر المطورين بضرورة التحلي بمزيد من الحذر عند تصميم العقود الذكية، خاصة عندما يتعلق الأمر بوظائف تغيير صلاحيات الأدوار الأساسية. في الوقت نفسه، يجب على المستخدمين أيضًا أن يظلوا يقظين عند استخدام خدمات السلاسل المتعددة، ومتابعة التطورات الأمنية ذات الصلة.