استيقظت على اختراق rsETH، وبدأت في البحث على جوجل.

الكثير من الناس يتهمون Kelp بالإهمال.
ثم صادفت البحث الجديد لـ @stacy_muur حول الاستغلال، وحتى الآن هذا هو أكثر مقال تفصيلي على CT.
ملخص سريع لما حدث فعلاً ↓
تم سرقة حوالي 116,500 rsETH (~$292 مليون) من الجسر.
لكن هذا لم يكن:
– استغلال في عملية الإصدار
– ليس خطأ في العقد الذكي
– ليس هجوم إعادة الدخول
هذا مهم.
ما حدث هو رسالة عبور سلسلة زائفة قبلتها إيثريوم على أنها حقيقية.
فكر في الأمر على النحو التالي:
تلقت إيثريوم رسالة تقول
"مرحبًا، أفرج عن الأموال – تم حرقها على السلسلة الأخرى"
إلا أنه لم يتم حرقها أبدًا.
بدت الرسالة شرعية 100% من الناحية الهيكلية، لذا نفذها النظام.
مهم:
– الضمانات rsETH على الشبكة الرئيسية سليمة
– حاملو rsETH الحاليون لا يواجهون خصمًا مباشرًا الآن
وهذا هو التصور الواقعي لمناطق المسؤولية:
@KelpDAO:
▪ إعداد DVN بنسبة 1:1. هذا هو أدنى إعداد لـ LayerZero.
▪ كان هذا الإعداد موجودًا لمدة لا تقل عن 90 يومًا – ليس خطأً مستعجلًا
▪ كانت 11 من 12 طرق واردة لـ Kelp فريدة من نوعها – هذا هو النمط القياسي لديهم
▪ استجابت Kelp وعلقت العقود، مما منع الهجمات الأخرى
@LayerZero_Core:
▪ الـ DVN المطلوب الوحيد هو "LayerZero: DVN" المسمى على Etherscan
▪ تم التحقق من حزمة وإثباتها بواسطة هذا الـ DVN دون حدث مصدر حقيقي
▪ نفس الـ DVN يعمل بشكل طبيعي على مئات الطرق الأخرى
بشكل أساسي، الـ DVN الخاص بـ LayerZero هو المكون الذي تحقق من رسالة. سواء كان ذلك بسبب مفتاح مخترق، أو خطأ برمجي، أو مدخلات غير صحيحة من المصدر، هو السؤال المركزي الذي لم يُجب عليه بعد.