لماذا قد تخسر المحفظة المخترقة أموالًا مجددًا بعد السحب الأول؟
يصف التقرير التقني لشركة Blockaid حول حادثة Binance مزيجًا خطيرًا: توقيع غير مصرّح به + تفويض EIP-7702
إليك آلية ذلك

أولًا: السيطرة على مسار التوقيع
بحسب Blockaid، سيطر المهاجم على البنية التحتية للتوقيع لدى Binance
لا يعني ذلك بالضرورة نسخ العبارة الأولية. فالمهاجم الذي يستطيع جعل خدمة التوقيع تُصدر توقيعات صالحة يمكنه أيضًا التصريح بإجراءات ضارة
تتحقق سلسلة الكتل من صحة التوقيع، لا من نية الشخص وراءه

ثم: تغيير طريقة عمل المحفظة
تُصرّح عملية التحويل العادية بمعاملة محددة
يوجّه تفويض EIP-7702 المحفظة إلى شيفرة عقد قابلة للتنفيذ. وتسجّل معاملة من النوع 4 هذا التفويض على السلسلة
بعدها يمكن للشيفرة الضارة التنفيذ ضمن سياق المحفظة ونقل أصولها

لماذا تهم «رشّة قيم nonce»؟
قيمة nonce هي عدّاد معاملات الحساب
يفيد تقرير Blockaid بأن المهاجم قدّم 50 تفويضًا موقّعًا تغطي قيم nonce مختلفة، لأن المحفظة النشطة واصلت معالجة عمليات السحب
لم يكن الأمر تخمينًا للمفتاح الخاص. إذ ظل كل تفويض يتطلب توقيعًا صالحًا

لماذا لم يُنهِ السحب الأول الخطر؟
يظل التفويض قائمًا إلى أن يُستبدل أو يُلغى
إذا بقيت الشيفرة الضارة نشطة، فيمكن للمهاجم استدعاؤها مجددًا لسحب الأموال المودعة حديثًا، من دون الحصول على توقيع آخر من الضحية
لا يؤدي تغيير كلمة المرور أو فصل الاتصال بموقع إلكتروني إلى إزالة تلك الحالة المسجلة على السلسلة
الدرس الأمني
احمِ خدمة التوقيع، وافحص وجهات التفويض، وراقب تغييرات شيفرة المحفظة
إلغاء التفويض وإبطال موافقات الرموز مهمتان منفصلتان. وإذا ظل الوصول إلى التوقيع مخترقًا، فيمكن للمهاجم إصدار تفويض جديد
كان EIP-7702 إحدى الآليات المذكورة في هذه الحادثة، وليس تفسيرًا لكل سلسلة متأثرة
تفاصيل الحادثة: تقرير Blockaid؛ لم يُتحقق منها بشكل مستقل هنا
البروتوكول: مواصفات Ethereum EIP-7702
هل نحمي الرصيد فحسب، أم نحمي أيضًا ما يُصرّح للمحفظة بتنفيذه؟
$BTC $ETH $BNB